サービスメッシュ―マイクロサービスを観測するには

　マイクロサービスはここまでに見たような多くの利点を持つが、モノリスでは表面化しなかった課題も見えてくる。数百の単位で機能を分けることで課題となるのが、クラウドネイティブの定義4点目にもあった「可観測性」だ。Netflixの適用事例では、2014年の時点で500を超えるマイクロサービスが数珠つなぎになっていたといい、手動によるサービスの状態管理は現実的に不可能である。

　そこで用いられるアーキテクチャがサービスメッシュだ。通常のマイクロサービスは直接アプリケーション同士がデータを受け渡すが、サービスメッシュを適用すると、各サービスは必ずプロキシを通してつながるようになる（スライドP.22）。これにより各リクエストは管理されるようになり、マイクロサービス間の通信はプロキシによりモニタリングされ、観測可能な状態となる。アーキテクチャ上分離することで、サーキットブレーカー^[2]やリトライ制御などの制御機構や、暗号化などのセキュリティ対応もプロキシに任せることができ、開発者が業務ロジックにのみ集中することができるというのも利点だ。加えて、個別のトラフィックを別の環境に流すような、いわゆるカナリアリリース^[3]やブルーグリーンデプロイメント^[4]の制御も、プロキシを通すことで容易になる。

Dockerコンテナと、従来のVMとの違い

　これまで見てきたマイクロサービスやサービスメッシュを実践する環境は、従来のVMを適用することでも可能だが、一般にコンテナ型仮想化と呼ばれる手法がよく用いられる。その理由として、VMと異なりOSごとではなく機能単位での仮想化が可能となるため、起動・停止が高速でオーバーヘッドが少ないという利点が挙げられた。また、イメージのビルドを一度行えばどこでも動く「Build Once, Run Anywhere」という特長も流行の要因として大きいという。VMでもVMイメージは作れたが、それに比べイメージ化が非常に容易であるとされ、具体例をもとにした説明がなされた。

　イメージの作り方はいたってシンプルで、命令をすることによりレイヤーが重なっていく構造になっている。スライドP.36のように5つの命令を順に行えば、そのままレイヤーとなる。そして、作成したイメージは一度ビルドすれば他の環境でも動くことが保証される。