サービスメッシュ

サービスメッシュさーびすめっしゅ

マイクロサービスサイドカープロキシIstioEnvoy可観測性トラフィック管理

サービスメッシュについて教えて

簡単に言うとこんな感じ！

たくさんの小さなプログラム（マイクロサービス）がお互いに通信するとき、その通信を一括で管理・監視してくれる「専任の交通整理係」だよ！各プログラムの横にこっそり専属スタッフを置いて、通信の安全・速度・記録をぜんぶ代わりにやってくれるイメージなんだ！

サービスメッシュとは

サービスメッシュとは、マイクロサービスアーキテクチャ（システムを多数の小さな独立したサービスに分割する設計手法）において、サービス間の通信を一元的に管理するためのインフラストラクチャレイヤー（基盤層）のことです。各サービスが直接通信を管理する代わりに、サービスメッシュがその通信のルーティング・セキュリティ・監視をすべて引き受けます。

システムが数十〜数百のマイクロサービスで構成されるようになると、「どのサービスがどのサービスと通信しているか」「通信が失敗したときにどうリトライするか」「通信を暗号化しているか」といった課題が一気に複雑になります。サービスメッシュはこの複雑さをアプリケーションコードから切り離し、インフラ側で一括管理することで、開発者がビジネスロジックに集中できるようにします。

実務的には、Istio（イスティオ）やLinkerd（リンカード）などのOSSが代表的な実装として使われており、クラウドネイティブな大規模システムを運用する企業で採用が広がっています。

サービスメッシュの仕組み

サービスメッシュは大きく「データプレーン」と「コントロールプレーン」の2層構造で成り立っています。

コンポーネント	役割	例
データプレーン	実際の通信を処理するプロキシ群	Envoy, Linkerd-proxy
コントロールプレーン	プロキシ全体を設定・管理する司令塔	Istiod, Linkerd Control Plane

サイドカーパターンとは

データプレーンの核心がサイドカープロキシです。各サービスのコンテナの”隣”に、軽量なプロキシコンテナを自動的に注入（インジェクト）し、すべての通信をそのプロキシ経由でやり取りさせます。バイクのサイドカー（横に付いた補助席）のように、本体に手を加えず機能を追加するイメージです。

┌─────────────────────────────────────────┐
│ Pod（サービスAの実行単位）               │
│  ┌──────────────┐  ┌────────────────┐  │
│  │  サービスA   │  │ サイドカー      │  │
│  │  （本体）    │◄─►│ プロキシ       │  │
│  └──────────────┘  │ (Envoy等)      │  │
│                     └────────────────┘  │
└─────────────────────────────────────────┘
                         ▲
                         │ 設定・ポリシー配信
                         ▼
              ┌──────────────────────┐
              │  コントロールプレーン  │
              │   (Istiod 等)        │
              └──────────────────────┘

サービスメッシュが提供する主な機能

機能カテゴリ	具体的な内容
トラフィック管理	カナリアリリース（新バージョンへ少しずつ流量を移す）、リトライ、タイムアウト
セキュリティ	mTLS（相互TLS認証）による通信の自動暗号化、認可ポリシー
可観測性	通信のメトリクス・ログ・分散トレーシングの自動収集
サービスディスカバリ	サービスの場所を動的に発見し、ルーティングを自動調整

歴史と背景

2010年代前半：Netflixが大規模マイクロサービス移行を進め、サービス間通信の複雑さが業界共通の課題として認識される
2016年：Lyft（米配車サービス）がEnvoyプロキシをOSSとして公開。高性能なL7プロキシの基盤が整う
2017年：Google・IBM・Lyfが共同でIstioをOSSとして発表。サービスメッシュという概念が広く知られるようになる
2018年：BuoyantがLinkerd 2.0を公開。よりシンプルな設計で採用しやすい選択肢が増える
2018年：CNCFがEnvoyを卒業プロジェクト（成熟プロジェクト）として認定
2020年以降：Kubernetes（コンテナ管理基盤）の普及とともにサービスメッシュの採用が加速。クラウド3社（AWS App Mesh、Google Cloud Service Mesh、Azure Service Mesh）がマネージドサービスを提供開始
2022年：次世代アーキテクチャとしてsidecar-lessモデル（Istio Ambient Meshなど）が登場し、プロキシの挿入コストを削減する方向へ進化

代表的な実装の比較

主要なサービスメッシュ実装を比較してみましょう。

製品	開発元	特徴	難易度
Istio	Google / IBM	機能が豊富、大規模向け	高め
Linkerd	Buoyant	軽量・シンプル、学習コスト低	低〜中
Consul Connect	HashiCorp	マルチクラウド対応が強み	中
AWS App Mesh	AWS	AWSサービスとの連携が容易	低（AWSに限定）
Kuma	Kong	マルチクラスター対応	中

サービスメッシュとAPIゲートウェイの違い

混同しやすいAPIゲートウェイとの違いを整理します。

規格・RFC番号	内容
RFC 8446	TLS 1.3（mTLSの基盤となるトランスポート層セキュリティ）
RFC 7540	HTTP/2（Envoy等がサービス間通信に使用するプロトコル）
RFC 9114	HTTP/3（次世代サービス間通信プロトコルとして採用が進む）