読者です 読者をやめる 読者になる 読者になる

おさかな日誌

魚類がプログラミング

(要約記事) Varnish と Microservices: Zipnish の紹介

元記事: Varnish and Microservices: Introducing zipnish

Amedia が Microservices パターンを適用した時の事例を元に Zipnish というソフトウェアの紹介記事

元記事には無い前提情報

Microservices アーキテクチャを apply する時に Varnish を活用する手法があるようだ。

今まではそれぞれのサービス間はそれぞれ通信するので、接続先のサービスを探す "Service Discovery" の問題を解決しなければいけなかった。具体的には、各サービスのインスタンス情報の格納のために Service Direcotry (元記事では Service Catalog と呼んでいる)の運用、サービスのインスタンス情報の更新(health check も含む)など。

(画像は Microservices 2.0 から引用)

f:id:aladhi:20160127163302p:plain

Varnish を中央に設置して、サービス間の通信は全て中央の Varnish を通り、Serivce Discovery やキャッシングは Varnish に任せる手法。

f:id:aladhi:20160127163312p:plain

参考リンク: Microservices 2.0

(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 で書かれたものに置き換える予定。