サービスメッシュ

なぜサービスメッシュが要るのか

マイクロサービス（/architecture/microservices/）にすると、1つの処理が 多数のサービス間ネットワーク呼び出し に分解されます。すると、それまでプロセス内の関数呼び出しでは考えなくてよかった問題が一気に表面化します。

• 呼び出し先が一時的に落ちている → 再試行・タイムアウト が要る
• どのサービスが遅いのか分からない → 通信の可視化 が要る
• サービス間の通信を盗聴・なりすましされたくない → 暗号化・認証 が要る
• 新バージョンに少しだけ流したい → トラフィックの重み付け が要る

これらを 各サービスのコードに個別実装 すると、言語ごとにライブラリを書き、全チームで足並みを揃える羽目になります。サービスメッシュは、この共通の通信機能をアプリの外側に切り出す 仕組みです。

サイドカー方式：通信を横取りする

サービスメッシュの典型は サイドカープロキシ 方式です。各サービスの すぐ隣（同じ Pod 内など）に小さなプロキシを置き、そのサービスの 入る通信・出る通信をすべてプロキシ経由 にします。

[サービスA] ⇄ [プロキシA]  ⇄⇄  [プロキシB] ⇄ [サービスB]
            ↑ ここで再試行・暗号化・計測・ルーティングを実施

アプリ自身は「相手を普通に呼ぶ」だけ。実際の再試行・暗号化・計測・経路選択は 隣のプロキシが代行 します。アプリのコードに手を入れずに通信の振る舞いを変えられるのが最大の利点です。

データプレーンとコントロールプレーン

サービスメッシュは2つの層に分かれます。役割の分離を押さえると全体像が掴めます。

層	構成要素	役割
データプレーン	各サービス隣のサイドカープロキシ群	実際の通信を仲介・暗号化・計測・ルーティング
コントロールプレーン	中央の管理コンポーネント	方針（ルール）を全プロキシへ配布・証明書を管理

運用者は コントロールプレーンにポリシーを宣言 するだけ（例：「サービス A→B は3回まで再試行」）。コントロールプレーンがそれを 全プロキシに配って 実行させます。個々のサーバに入って設定する必要はありません。

主な機能

サービスメッシュが肩代わりする機能は、大きく3つの領域に整理できます。

• 信頼性（Resilience）：再試行、タイムアウト、サーキットブレーカー、レート制限。一時障害を吸収し、連鎖的なダウンを防ぐ。
• セキュリティ：サービス間通信の mTLS（相互TLS） による自動暗号化と相手認証。「誰が誰を呼べるか」のアクセス制御も。
• 可観測性（Observability）：全通信がプロキシを通るため、成功率・レイテンシ・通信量 などの指標や分散トレースを横断的に取得できる（/devops/observability/）。

加えて トラフィック制御 が強力です。重み付けルーティングで「新バージョンへ5%だけ流す」カナリアや、ヘッダに応じた振り分け、障害注入によるテスト（/devops/chaos-engineering/）が、アプリを変えずに実現できます（/devops/deployment-strategies/）。

Istio と Linkerd

代表的な実装が Istio と Linkerd（ともに CNCF プロジェクト）です。性格が異なります。

観点	Istio	Linkerd
位置づけ	高機能・多機能	軽量・シンプル重視
学習コスト	高い（設定項目が豊富）	低め（最小構成で動かしやすい）
適する場面	複雑な要件・細かい制御が必要	まず軽く始めたい・運用負荷を抑えたい

「とにかく細かく制御したい」なら Istio、「最小の複雑さで信頼性と mTLS が欲しい」なら Linkerd、というのが大まかな選び分けです。なお、サイドカーを各 Pod に置く方式に代わり、ノード単位で処理する サイドカーレス な構成も登場しており、レイテンシやリソース効率の改善が図られています。

導入の判断：複雑さという代償

サービスメッシュは万能薬ではありません。導入そのものが複雑さとオーバーヘッドを増やします。

• レイテンシ：全通信がプロキシを2回通るため、わずかに遅延が増える。
• リソース：サイドカーの数だけ CPU / メモリを消費する。
• 運用：コントロールプレーン自体が新たな運用対象になり、障害点にもなり得る。

まとめ

• サービスメッシュは サービス間通信の共通機能 をアプリ外の サイドカー層 に集約する仕組み。
• データプレーン（プロキシ群） が通信を仲介し、コントロールプレーン が方針を配る。
• 再試行・mTLS暗号化・可観測性・トラフィック制御 をコード変更なしで底上げできる。
• 代償は 複雑さ・遅延・リソース。規模と悩みが揃ってから入れるのが賢い。Istio / Linkerd が定番。