Cloud Service Mesh

解決する課題

マイクロサービスが増えると、サービス間の通信そのものが運用課題になります。誰が誰を呼んでいるのか、通信は暗号化されているか、失敗時にどうリトライするか、特定バージョンへ徐々にトラフィックを流せるか、といった関心事です。これらをアプリ本体のコードに作り込むと、言語ごとに実装がばらつき、運用が分散します。Cloud Service Mesh はこの通信制御をインフラ層に切り出します。

• サービス間の通信を暗号化（mTLS） し、相互に認証したい（アプリ改修なしで）
• どのサービスが何を呼んでいるか、通信のメトリクス・トレース・トポロジを可視化したい
• 新バージョンへ段階的にトラフィックを流す（カナリア／ブルーグリーン）を仕組みとして持ちたい
• タイムアウト・リトライ・サーキットブレーカーなどの回復性ロジックを共通化したい
• 言語ごとにライブラリを書かず、通信ポリシーを一元管理したい

AWS でいえば App Mesh に相当します。オープンソースの Istio をベースにしており、Istio の設定やエコシステムの考え方をそのまま活かせるのが特徴です。

主要概念と用語

• サービスメッシュ: サービス間通信を専用のインフラ層で扱う考え方。アプリは通常どおり通信し、メッシュが暗号化・ルーティング・観測を引き受ける
• データプレーン: 実際にトラフィックを処理する層。サイドカープロキシ（Envoy）やプロキシレスのクライアントがここに当たる
• コントロールプレーン: プロキシへ設定を配布し、メッシュ全体を制御する層。Cloud Service Mesh ではマネージド版を Google が運用する
• サイドカープロキシ: 各 Pod に注入される Envoy プロキシ。アプリの全通信がこのプロキシを経由し、暗号化やルーティングが適用される
• プロキシレス gRPC: サイドカーを使わず、gRPC ライブラリ自体がメッシュの設定を受け取って通信する方式。オーバーヘッドを抑えられる
• mTLS（相互 TLS）: 双方が証明書で相手を認証しつつ通信を暗号化する仕組み。メッシュが証明書の発行・更新を自動化する
• トラフィック管理: 重み付けルーティング・リトライ・タイムアウト・フォールトインジェクションなど、通信の振る舞いを宣言的に定義する設定
• Istio API: VirtualService や DestinationRule などのリソースで挙動を定義する、Istio 由来の設定モデル
• マネージドコントロールプレーン: コントロールプレーンの構築・更新・スケールを Google が担う運用モード

仕様・制限・クォータ

• 動作環境は主に GKE で、サイドカー自動注入とマネージドコントロールプレーンを使う構成が中心。Compute Engine 上のワークロードやプロキシレス gRPC もサポート対象になる
• メッシュへの参加方式は サイドカー型 と プロキシレス gRPC の二系統があり、ワークロード特性で選ぶ
• 設定モデルは Istio 互換 だが、マネージド構成では使えるバージョンや一部機能に制約があり、対応バージョンはリリースで更新される
• サイドカー方式では各 Pod に Envoy が追加されるため、わずかな CPU／メモリと遅延のオーバーヘッドが発生する
• メッシュに参加させるエンドポイント数や設定リソース数などに上限・クォータがあり、構成によって変動する

具体的な上限値・対応バージョン・課金単位はリリースで変わるため、設計時は公式ドキュメントで最新値を確認してください。

内部の仕組み

Cloud Service Mesh は データプレーン と コントロールプレーン の二層で成り立ちます。コントロールプレーンが各プロキシへ「どこへどう通信するか」「どの証明書で暗号化するか」といった設定を配布し、データプレーンがその設定どおりに実際の通信を処理します。マネージド構成では、このコントロールプレーンの運用を Google が引き受けます。

サイドカー方式では、各 Pod に Envoy プロキシ が自動注入され、アプリの送受信トラフィックがすべてこのプロキシを経由します。アプリのコードはプロキシの存在を意識せず通常どおり通信しますが、暗号化・ルーティング・メトリクス収集はプロキシ側で適用されます。これにより、アプリを改修せずに mTLS や段階的リリースを実現できます。

プロキシレス gRPC 方式では、サイドカーを挟まず、gRPC クライアント自身がメッシュの設定を受け取って通信先を解決します。サイドカーぶんのリソースと遅延を避けられる一方、対象は gRPC を使うワークロードに限られます。

mTLS の証明書は、メッシュが自動で発行・配布・ローテーションします。利用者が証明書を手作業で配って回る必要がなく、暗号化と相互認証を運用負荷の低い形で常時有効にできます。

設計パターン / ベストプラクティス

• 通信は原則 mTLS を STRICT（厳格）モードにし、メッシュ内を暗号化・相互認証で固める。段階導入時は許容モードから始めて切り替える
• 新バージョンは 重み付けルーティングで少量から流し、メトリクスを見ながら比率を上げる（カナリア）
• タイムアウト・リトライ・サーキットブレーカーをメッシュ側で定義し、回復性ロジックをアプリから切り離す
• 障害テストにはフォールトインジェクション（意図的な遅延・エラー注入）を使い、回復性を事前に検証する
• サイドカーのオーバーヘッドを避けたい高スループットな gRPC サービスでは プロキシレス gRPC を検討する
• 認可はサービス単位のアクセスポリシーで最小化し、許可された呼び出しだけを通す
• メッシュ参加は段階的に進め、まず観測（可視化）から導入して挙動を把握してから制御を強める

運用・監視

• Cloud Monitoring / Cloud Logging / Cloud Trace と統合され、サービス間のレイテンシ・エラー率・リクエスト量といったゴールデンシグナルを自動収集できる
• メッシュのダッシュボードでサービストポロジ（どのサービスがどこを呼んでいるか）を可視化し、依存関係とボトルネックを把握する
• SLO を定義し、エラーバジェットの消費状況を監視して、リリースや変更の判断材料にする
• マネージドコントロールプレーンでは更新を Google が担うが、データプレーン（サイドカー）の更新はノードやワークロードの再起動を伴うため計画的に行う
• 通信異常時は、まずメトリクスとトレースで問題のサービス間リンクを特定し、リトライ／タイムアウト設定やプロキシのログを確認する

コスト

費用は「メッシュ機能そのものの利用」と「サイドカープロキシが消費するコンピューティング」の二側面で考えます。メッシュの課金体系はエディションや構成で変わるため、定性的に押さえておきます。

サイドカー方式では Pod 数が増えるほど Envoy のぶんのリソースが積み上がります。トレースのサンプリング率やサイドカーのリソース要求を見直すことが、そのままコスト最適化につながります。

セキュリティ

• メッシュ内通信を mTLS で暗号化・相互認証し、証明書の発行・ローテーションはメッシュに任せる（手作業の鍵配布を排除）
• STRICT モードで平文通信を排除し、暗号化されていない呼び出しを拒否する
• 認可ポリシーでサービス単位のアクセスを最小化し、許可した呼び出し元だけを通してラテラルムーブメントを抑える
• ワークロードの ID は Workload Identity Federation for GKE と組み合わせ、サービスごとの強い同一性を担保する
• Ingress / Egress の境界を明確にし、外部との通信経路をゲートウェイに集約して統制する

関連サービス・比較

Cloud Service Mesh は GKE の上でサービス間通信を担う層であり、外部からの入口を担う Cloud Load Balancing（および Gateway / Ingress）とは役割が異なります。前者は東西方向（サービス間）、後者は南北方向（外部からの流入）の通信を主に扱います。両者を組み合わせて全体の通信経路を構成します。

ハンズオン / CLI例

# GKE クラスターにフリート（fleet）を有効化して登録
gcloud container fleet memberships register demo-membership \
  --gke-cluster=asia-northeast1/demo-cluster \
  --enable-workload-identity

# マネージドな Cloud Service Mesh を有効化
gcloud container fleet mesh enable

# 対象クラスターでマネージドコントロールプレーンを使う設定
gcloud container fleet mesh update \
  --management automatic \
  --memberships demo-membership

# サイドカー自動注入を有効化したい名前空間にラベルを付与
kubectl label namespace default istio.io/rev=asm-managed --overwrite

# 注入を反映するため対象ワークロードを再起動
kubectl rollout restart deployment -n default