(要約記事) Varnish と Microservices: Zipnish の紹介
元記事: Varnish and Microservices: Introducing zipnish
[update] スライドへのリンクが変わっていたので更新: https://www.slideshare.net/Varnish_software/microservices-20-61197134
Amedia が Microservices パターンを適用した時の事例を元に Zipnish というソフトウェアの紹介記事
元記事には無い前提情報
Microservices アーキテクチャを apply する時に Varnish を活用する手法があるようだ。
今まではそれぞれのサービス間はそれぞれ通信するので、接続先のサービスを探す "Service Discovery" の問題を解決しなければいけなかった。具体的には、各サービスのインスタンス情報の格納のために Service Direcotry (元記事では Service Catalog と呼んでいる)の運用、サービスのインスタンス情報の更新(health check も含む)など。
(画像は http://www.slideshare.net/Varnish_software/microservices-20-55572848 から引用)
Varnish を中央に設置して、サービス間の通信は全て中央の Varnish を通り、Serivce Discovery やキャッシングは Varnish に任せる手法。
参考リンク: http://www.slideshare.net/Varnish_software/microservices-20-55572848
(Microservices Varnish の手法の)良かったこと
- Service Discovery の問題を Varnish で解決できる
- サービスの接続先の管理や取得を Varnish がやるので他の仕組みを用意しなくて良い。
- Service Direcotry を用意しなくて良い (Zookeeper や etcd を使った仕組み)。
- それぞれのサービスをステートレスにしたことで中央で一括でキャッシュできた。
- 中央で一括してキャッシングしてるので cache invalidation が簡単。それぞれのサービスがキャッシュレイヤーを持っている場合だと、キャッシュが散らばってるしレイヤーも複数あったりするので cache invalidation が難しい。
(2) については「どうやってステートレスにするんだ」という疑問があってよくわからない....
Zipnish の紹介
- Zipkin が解決しようとしている Microservices の monitoring 問題がある。例えば、依存サービスのモニタリング、どのサービスに問題があるのか、どのリクエストが遅いのか、などを可視化したい。
- Zipkin は JVM 前提で使いづらい。heavy。
- Microservices Varnish の手法では中央の Varnish を必ず通るのでそこで Zipkin がするようなロギングを行うアイディア
- Varnish Cache 4.0 から導入された logging API を使うっぽい(?)
- 今はビュー周りは Zipkin を再利用している。Python で書かれたものに置き換える予定。
