サービスメッシュ

概要

サービスメッシュは、マイクロサービス同士の通信の制御・保護・観測を、アプリケーションのコードから切り離して専用のインフラ層に任せる仕組みです。「メッシュ（網）」の名の通り、サービスが増えるほど網の目のように張り巡らされる通信経路すべてを、一枚の層としてまとめて面倒をみます。代表的な実装に Istio、Linkerd、AWS App Mesh などがあります。

仕組みの中核はサイドカーパターンです。各サービスの隣に Envoy などの軽量プロキシを並走させ、サービスの送受信をすべてそこに通します。アプリからは相変わらず「隣のサービスを呼んでいるだけ」に見えますが、実際の通信はリトライ・タイムアウト・暗号化・計測を施されたうえで届く — アプリのコードを一切変えずに、通信の品質を底上げできるのがサービスメッシュの本質です。

なぜ生まれたか

モノリスでは関数呼び出しだった処理の連携が、マイクロサービスではネットワーク越しの呼び出しになります。ネットワークは失敗するものなので、各サービスにはリトライ、タイムアウト、サーキットブレーカー、mTLS による相互認証、分散トレーシングのためのヘッダ伝播……と、本来のビジネスロジックとは無関係な「通信の作法」を大量に実装する必要が生まれました。

これを共通ライブラリで配ろうとすると、Netflix の Hystrix や Ribbon がそうだったように、言語ごとの再実装と全サービス一斉アップデートという泥沼にはまります。Go のサービスには Java のライブラリは使えず、リトライ戦略を1つ変えるだけで数十チームの再デプロイが必要になる。この苦しみへの回答が「通信の作法をアプリの外に出し、プロキシに任せる」というサービスメッシュでした。2016年に Linkerd がこの概念を提唱し、2017年の Istio 登場で一気に広まりました。

詳細

二層構造 — データプレーンとコントロールプレーン

サービスメッシュは2つの層でできています。データプレーンは各 Pod に同居するサイドカープロキシ（Envoy が事実上の標準）の集合で、実際のリクエストはすべてここを流れます。コントロールプレーン（Istio では istiod）は管理者が書いた設定 —「このサービスへのリクエストは3回までリトライ」「v2 へ10%だけ流す」など — を解釈し、全プロキシに配信する司令塔です。リクエスト自体はコントロールプレーンを通らないため、司令塔が一時的に落ちても通信は流れ続けます。

アプリを変えずに手に入るもの

この構造から得られる機能は4系統に整理できます。第一にトラフィック制御。リトライ・タイムアウト・サーキットブレーカーに加え、リクエストの重み付けルーティングによりカナリアリリース（新バージョンへ数%だけ流して様子を見る）を設定変更だけで実現できます。第二にセキュリティ。コントロールプレーンが各プロキシに証明書を自動発行・自動更新し、サービス間の全通信を mTLS で相互認証・暗号化します。これは「内側のネットワークも信用しない」ゼロトラストを実践する足場になります。第三に可観測性。全通信がプロキシを通るため、リクエスト数・エラー率・レイテンシといったメトリクスや分散トレーシングのデータが全サービス分、均質に自動で手に入ります。第四にヘルスチェックと連動したロードバランサ的な宛先選択も、プロキシがきめ細かく行います。

代償と採用判断

万能に見えますが、代償は小さくありません。全リクエストがプロキシを2回（送信側と受信側）経由するためレイテンシが上乗せされ、Pod ごとのプロキシがメモリと CPU を消費します。そして最大のコストは運用の複雑さです。障害調査では「アプリの問題かメッシュの問題か」という切り分けの層が1つ増え、メッシュ自体のバージョンアップも無停止で行う必要があります。

このため採用判断は規模に依存します。サービスが数個〜十数個で単一言語なら、APIゲートウェイで入口を整え、内部はリトライライブラリで済ませるほうが総コストは低いことが多いでしょう。サービスメッシュが真価を発揮するのは、多言語のサービスが数十個以上あり、mTLS の全面適用や均質な可観測性が組織的な要件になったときです。なお近年は、サイドカーを Pod ごとに置かず、ノード単位のプロキシや eBPF でメッシュ機能を提供する「サイドカーレス」の潮流（Istio Ambient Mesh、Cilium Mesh など）も進んでおり、オーバーヘッド問題への回答として注目されています。