Service Mesh は『マイクロサービスの神経網』
マイクロサービス間通信の信頼性・観測性・セキュリティを統一的に扱う Service Mesh は、大規模 k8s 運用の主要選択肢です。本記事では編集部の視点で、選び方と運用を公開情報をもとに整理します。マイクロサービス設計 もご参考に。
Service Mesh が解く課題
(1) サービス間 mTLS：自動暗号化。(2) トラフィック制御：カナリア/A-Bテスト。(3) リトライ/タイムアウト：標準化。(4) 観測性：トレース/メトリクス/ログ自動収集。(5) 認可ポリシー：サービス間呼出の制御。
主要プロダクトの特徴
(1) Istio：機能豊富・複雑・サイドカー型(Envoy)。(2) Linkerd：シンプル・軽量・サイドカー型(Rust)。(3) Cilium：eBPF ベース・サイドカーなし。(4) AWS App Mesh / GCP Anthos：マネージド。(5) Consul Connect：HashiCorp 製。判断軸：シンプル重視→Linkerd、機能重視→Istio、性能重視→Cilium。
サイドカーアーキテクチャ
(1) Pod ごとにプロキシを注入。(2) 透過的に通信を仲介。(3) リソース増：1 Pod に+メモリ50〜100MB。(4) レイテンシ追加：1〜数ms。(5) Ambient Mesh (Istio v1.18+)：サイドカーレス化の動き。
導入の判断基準
(1) サービス数：20以下なら不要なケースも。(2) マルチクラスタ運用なら効果大。(3) セキュリティ要件：mTLS 必須なら導入価値高。(4) 運用負荷：専任 SRE が必要。(5) 段階導入：観測性だけから始める選択肢も。k8s 本番運用 もご参考に。
運用上の注意点
(1) バージョンアップ：複雑で慎重に。(2) デバッグの難しさ：障害の切り分けが困難。(3) パフォーマンス影響：本番で計測必須。(4) セキュリティ更新：定期的に。(5) 学習コスト：チーム全員に必要。分散トレーシング も合わせて。
失敗しがちなパターン
(1) 導入してから運用負荷で疲弊。(2) 機能を全部使おうとして混乱。(3) サービス数少ないのに導入。(4) Istio の Sidecar を全 Pod に：リソース無駄。(5) バージョンを上げず脆弱性放置。対策は、(1)段階導入、(2)機能を絞る、(3)スケール検討後、(4)対象 namespace に限定、(5)定期更新、です。