サービスメッシュ

サービスメッシュとは

サービスメッシュは、マイクロサービス間の通信を透過的に管理するインフラ層である。各サービスにサイドカープロキシを配置し、トラフィック制御、mTLS 認証、オブザーバビリティをアプリケーションコードの変更なしで実現する。Istio と Linkerd が代表例で、AWS の App Mesh も同じ役割を担ってきた。ただし App Mesh は 2026 年時点で新規の受付を終了し、2026 年 9 月 30 日でサポートが終了する。この日を過ぎるとコンソールも既存のリソースも参照できなくなり、AWS が案内する移行先は Amazon ECS Service Connect であるため、これから新しく組む構成には含めない。

なぜ必要か

マイクロサービスが増えると、リトライ、サーキットブレーカー、mTLS、メトリクス収集といった通信制御のコードを各サービスに個別実装する必要が生じる。サービスメッシュはこれらをサイドカープロキシに委譲し、アプリケーションコードを変更せずに通信制御を一元管理する。

❌ サービスメッシュなし:
  各サービスにリトライ、サーキットブレーカー、
  mTLS、メトリクス収集のコードを実装

✅ サービスメッシュあり:
  サイドカープロキシが透過的に処理
  アプリケーションはビジネスロジックに集中

アーキテクチャ

サービスメッシュはデータプレーンとコントロールプレーンの 2 層で構成される。データプレーンは各サービスに寄り添うプロキシで、アプリのコンテナが出す通信を iptables などの経路書き換えで一度受け取り、宛先の選択・再試行・暗号化を済ませてから相手のプロキシへ渡す。使うプロキシは実装ごとに異なり、Istio と App Mesh は Envoy を配るが、Linkerd はサービスメッシュ専用に書かれた軽量プロキシ (Rust 製の linkerd2-proxy) を配る。コントロールプレーンはルーティングルールやポリシーを保持し、各プロキシへ設定と、相互認証に使う証明書を配布する。アプリの再ビルドが要らないのはこの経路書き換えが効いているからで、逆に言えばプロキシが起動していない間の通信は素通しか失敗になる。

サービス A → [Envoy Proxy] → [Envoy Proxy] → サービス B
              (サイドカー)     (サイドカー)
                    ↑               ↑
              コントロールプレーン (Istio など)

コンポーネント	役割
データプレーン	各サービスに寄り添うプロキシ (Istio は Envoy、Linkerd は linkerd2-proxy) がトラフィックを処理
コントロールプレーン	ルーティングルール、ポリシーを管理

サイドカーを Pod ごとに注入しない方式もある。Istio は 2024 年 11 月の v1.24 で ambient モードを正式版とし、ノードごとに 1 つ置く ztunnel が同じノードの Pod の通信をまとめて受けて mTLS と接続単位の認可を担い、ヘッダーによる振り分けやリトライといった HTTP レベルの制御が要る名前空間だけ waypoint プロキシを別に立てる。Pod にコンテナを足さないため既存のワークロードを再起動せずにメッシュへ入れられる一方、HTTP レベルの制御を使う経路では waypoint を経由する分ホップが増える。2026 年 8 月時点でサイドカー方式も引き続き選べるため、Pod ごとの安定した分離やサイドカー前提の機能が必要なら従来方式を選ぶ判断も残る。

サービスメッシュの機能

サービスメッシュはカナリアデプロイや A/B テストのトラフィック制御、mTLS によるサービス間の暗号化・認証、自動リトライやサーキットブレーカーによる耐障害性、メトリクス・トレース・ログの自動収集によるオブザーバビリティ、サービスごとのレート制限を提供する。

サーバーレスでのサービスメッシュ

Lambda ベースのアーキテクチャでは、従来のサイドカー型サービスメッシュは不要。代わりに:

機能	サーバーレスでの代替
トラフィック制御	API Gateway のステージ、Lambda エイリアス
認証	IAM、Cognito
リトライ	Step Functions、SQS
オブザーバビリティ	X-Ray、CloudWatch

いつサービスメッシュを使うか

導入の分かれ目は、通信制御をアプリから追い出す価値がサイドカーの運用コストを上回るかどうかにある。

場面	判断	理由
ECS/EKS 上で多数のサービスが相互に呼び合う	導入する	リトライやサーキットブレーカーを各サービスに書き足さずサイドカーへ寄せられ、通信制御の変更をアプリの再デプロイと切り離せる
サービス間通信を mTLS で相互認証したい	導入する	証明書の配布と更新をコントロールプレーンが引き受けるため、各サービスに TLS の実装とローテーション処理を持たせずに済む
Lambda 中心のサーバーレス構成	導入しない	常駐するサイドカーを置けず、トラフィック制御は API Gateway のステージと Lambda エイリアス、リトライは SQS や Step Functions が同じ役割を担う
サービスが 5 個未満で呼び出し経路も単純	導入しない	増えるのはサイドカー分のリソースとコントロールプレーンの運用で、得られる制御は HTTP クライアント側のリトライ設定で足りる

つまずきやすい点

導入直後に増えるのは機能ではなく調べる場所である。1 回の呼び出しが呼び出し側のプロキシと受け側のプロキシを通るため、遅延が伸びたときにアプリとプロキシのどちらで詰まったのかを切り分ける必要があり、プロキシ側のメトリクスを最初から見られる状態にしていないと原因究明が長引く。リトライも同様で、アプリ側の HTTP クライアントとプロキシの両方に設定が残っていると再試行が掛け算になり、下流の障害時に負荷を増幅させる。通信制御をプロキシへ寄せると決めたら、アプリ側の同種の設定は外しておく。

mTLS と サーキットブレーカー、オブザーバビリティ を合わせて押さえると、プロキシが引き受けている処理の中身を一通り追える。