サービスメッシュ

サービス間通信を管理するインフラ層

サービスメッシュは、マイクロサービス間の通信を制御・観測する専用のインフラ層。サイドカープロキシパターンで、アプリケーションコードを変更せずに通信機能を追加。

サイドカーパターン

従来のマイクロサービス

Service A
ビジネスロジック
通信ロジック
リトライ/CB
認証/認可
通信機能がアプリに埋め込まれる

サービスメッシュ

Service A
ビジネスロジック
Proxy
通信
mTLS
Retry
通信機能をサイドカーに分離

サービスメッシュアーキテクチャ

Control Plane
設定管理
証明書発行
サービスディスカバリ
ポリシー配布
↓ 設定・証明書 ↓
Data Plane
App
Proxy
App
Proxy
App
Proxy
Proxy同士が通信（mTLS暗号化）

主な機能

トラフィック管理

  • • ロードバランシング（Round Robin, Least Conn）
  • • リトライ、タイムアウト
  • • Circuit Breaker
  • • カナリアリリース、A/Bテスト

セキュリティ

  • • mTLS（相互TLS認証）
  • • 自動証明書ローテーション
  • • サービス間認可ポリシー
  • • トラフィック暗号化

可観測性

  • • 分散トレーシング自動生成
  • • メトリクス収集（RED metrics）
  • • アクセスログ
  • • サービス依存関係の可視化

信頼性

  • • ヘルスチェック
  • • フェイルオーバー
  • • レート制限
  • • Fault Injection（テスト用）

mTLS（相互TLS認証）

Service A
証明書A
← 証明書交換 →
🔒 暗号化通信
← 相互認証 →
Service B
証明書B
通常のTLS

サーバーのみ認証（クライアント→サーバー）

mTLS

双方が認証（クライアント⇔サーバー）

トラフィック制御

カナリアリリース

Traffic
100%
→
Mesh Proxy
Weight Based
90%→
v1.0 (stable)
10%→
v1.1 (canary)
ユースケース: 新バージョンを少数ユーザーにテスト → 問題なければ徐々に増加

主な実装

Istio

  • • Proxy: Envoy
  • • 特徴: 機能が豊富、業界標準
  • • 複雑性: 高（学習コスト大）
  • • リソース: やや重い
  • • 採用例: Google, eBay, Salesforce

Linkerd

  • • Proxy: linkerd2-proxy (Rust製)
  • • 特徴: 軽量、シンプル、CNCF graduated
  • • 複雑性: 低（すぐ始められる）
  • • リソース: 非常に軽量
  • • 採用例: Microsoft, HP, Nordstrom

Consul Connect

  • • Proxy: Envoy or built-in
  • • 特徴: HashiCorp製、マルチプラットフォーム
  • • 複雑性: 中程度
  • • リソース: 中程度
  • • 採用例: AWS上でConsul利用者向け

AWS App Mesh

  • • Proxy: Envoy
  • • 特徴: AWSマネージド、ECS/EKS統合
  • • 複雑性: 低（AWSユーザー向け）
  • • リソース: マネージド
  • • 採用例: AWSネイティブアプリ

Envoy Proxy

多くのサービスメッシュで使われるデータプレーンプロキシ。 Lyft開発、CNCF graduated。C++製で高性能。

主な機能

L4/L7 Proxy

TCP, HTTP/1.1, HTTP/2, gRPC

Service Discovery

DNS, EDS, 動的設定

Load Balancing

Round Robin, Least Request, Ring Hash

Observability

Stats, Tracing, Logging

Resilience

Retry, Timeout, Circuit Breaker

Security

TLS termination, mTLS

サービスメッシュを導入すべきか

導入を検討すべき場合

  • • サービス数が多い（10以上）
  • • 複数チームがサービスを開発
  • • セキュリティ要件が厳しい（mTLS必須）
  • • 高度なトラフィック制御が必要
  • • 統一的な可観測性が必要

導入を見送るべき場合

  • • サービス数が少ない（5未満）
  • • 運用能力・学習リソースが不足
  • • レイテンシ要件が非常に厳しい
  • • 既存のインフラで十分
  • • Kubernetesを使っていない

段階的導入: 全サービスに一度に導入せず、 重要なサービスから段階的に適用し、運用ノウハウを蓄積する。

SRE/インフラ観点

リソースオーバーヘッド

  • • 各Podにサイドカーが追加（CPU/メモリ消費）
  • • Istio: ~100MB/proxy、Linkerd: ~10-20MB/proxy
  • • Control Planeもリソースが必要

レイテンシ影響

  • • プロキシ経由で+1-5ms程度の遅延
  • • 内部通信が多いとチェーンで増加
  • • Linkerdの方がIstioより低レイテンシ

監視項目

  • • サイドカーのCPU/メモリ使用量
  • • プロキシのリクエスト成功率/レイテンシ
  • • 証明書の有効期限
  • • Control Planeの健全性