サービスメッシュ

サービスメッシュとは

サービスメッシュは、マイクロサービス間の通信を透過的に管理するインフラ層である。各サービスにサイドカープロキシを配置し、トラフィック制御、mTLS 認証、オブザーバビリティをアプリケーションコードの変更なしで実現する。Istio、Linkerd、AWS App Mesh が代表例。

なぜ必要か

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

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

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

アーキテクチャ

サービスメッシュはデータプレーンとコントロールプレーンの 2 層で構成される。データプレーンは各サービスに配置されたサイドカープロキシ (Envoy) で、実際のトラフィックを仲介する。コントロールプレーン (Istio や App Mesh) はルーティングルールやポリシーを管理し、各プロキシに設定を配布する。

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

コンポーネント	役割
データプレーン	サイドカープロキシ (Envoy) がトラフィックを処理
コントロールプレーン	ルーティングルール、ポリシーを管理

サービスメッシュの機能

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

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

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

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

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

いつサービスメッシュを使うかの判断基準を以下にまとめる。

ケース	推奨
ECS/EKS で多数のマイクロサービス	✅ App Mesh
Lambda ベースのサーバーレス	❌ 不要
サービス間の mTLS が必須	✅
サービス数が 5 未満	❌ 過剰

実務での活用方法は関連書籍にも詳しい。