サービスメッシュとは？Control PlaneとData Planeの違いと選び方

サービスメッシュとは？Control Plane と Data Plane の抽象度を理解する

サービスメッシュは、マイクロサービス間の通信を インフラ層で統一的に管理 する仕組みです。
本セクションでは、制御系（Control Plane）とデータ転送系（Data Plane）の役割分担と、抽象度の違いが設計・運用に与えるインパクトを整理します。

Control Plane と Data Plane の役割分担

Control Plane は「何をすべきか」という意志決定ロジックを集中管理し、設定変更をリアルタイムで Data Plane に配信します。
Data Plane は実際のリクエスト/レスポンスを処理し、ネットワークレベル・アプリケーションレベルの機能を提供します。

• Control Plane の主な責務
• サービスディスカバリとルーティングポリシーの生成
• セキュリティ（認証・認可）やテレメトリ収集の設定管理

• 設定変更を各サイドカーへ安全にプッシュ

• Data Plane の主な責務

• L7 フィルタリング、ロードバランシング、TLS 終端化などをリアルタイムで実行
• 各サービスインスタンスにサイドカー（例：Envoy）としてデプロイされ、トラフィックの入口・出口になる
• 計測情報やログを Control Plane に送信

この分離により 運用者はポリシーだけを書けば自動的に適用 でき、開発者はコード修正なしで通信品質やセキュリティを向上させられます。

抽象度の違いが設計・運用に与えるインパクト

抽象度が高いほど 宣言的設定 が可能になり、学習コストとヒューマンエラーが低減します。一方、抽象度が低いと細かなチューニングがしやすくなります。

• 高抽象度（例：Istio の CRD）
• YAML にポリシーを書くだけで全サイドカーに反映できる。Kubernetes の CI/CD パイプラインと同様のフローでデプロイ可能【1】。

• デフォルトでベストプラクティスが組み込まれているため、初心者でも安全に運用できる。

• 低抽象度（例：Envoy のリスナー/フィルタ設定）

• JSON/YAML で細かいマッチ条件やカスタムフィルタを記述でき、レガシーシステムや独自プロトコルに対応しやすい。
• 手動管理が増える分、設定ミスや証明書ローテーションの手間が発生する可能性がある。

設計時は 「拡張性が必要か」 と 「運用のシンプルさを優先するか」 を基準に、どちらの抽象度を採用すべきか判断します。

Envoy が担う Data Plane の特徴

Envoy は軽量な L7 プロキシとしてデータプレーン機能の中核を担います。ここでは 2024‑2026 年にリリースされた主要機能を中心に解説します。

L7 フィルタリングとプロトコル解析

Envoy は HTTP/1、HTTP/2、gRPC に加えて MongoDB、Redis、Kafka といったデータベース・メッセージングプロトコルの解析もサポートしています【2】。
フィルタチェーンによりリクエストとレスポンスを段階的に加工でき、柔軟なトラフィック制御が実現します。

• ヘッダー操作：header_to_add / header_to_remove でリクエスト/レスポンスのメタ情報を書き換え
• 認可チェック：外部認可サーバ（OPA、Authz）と連携する ext_authz フィルタを組み込める
• レートリミット：local_rate_limit と global_rate_limit の二層構造でサービス単位・全体単位の制御が可能

アウトライヤーディテクション機能

Envoy 1.27 以降、アウトライヤー検知（Outlier Detection） が標準フィールドとして提供されます。異常なレイテンシやエラー率を自動で測定し、閾値超過時にリトライや回路遮断（circuit breaking）を実行します【3】。

• outlier_detection フィールドで 失敗率・最大連続失敗数・ベースEjection時間 を宣言的に設定
• 設定は Envoy の Admin API でも動的に更新でき、サービス稼働中のチューニングが容易

この機能により障害拡散リスクを低減し、セルフヒーリングを実現します。

Istio が提供する Control Plane と Kubernetes 連携

Istio は Envoy をデータプレーンとして利用しつつ、Kubernetes との深い統合を実現したコントロールプレーンです。以下では主要コンポーネントの変遷と現在の CRD 抽象化について整理します。

Pilot・Mixer・Citadel の変遷と現状

ポイント：現在の Istio は 単一バイナリ（istiod） が Pilot、Telemetry、Security を包括し、運用負荷が大幅に削減されています。

カスタムリソース (CRD) による抽象化

Istio の宣言的設定はすべて Kubernetes Custom Resource Definition (CRD) で表現されます。代表的な CRD とその役割は以下の通りです。

• VirtualService：トラフィックルーティング、フェイルオーバー、A/B テストを宣言
• Gateway：クラスター境界（Ingress/Egress）の L7 設定を集中管理
• DestinationRule：ロードバランシング・アウトライヤーディテクションのポリシーレベル設定
• Sidecar：特定ネームスペース／サービスに対してサイドカー範囲を限定

これらは Kubernetes の標準ツール（kubectl、helm） で操作でき、CI/CD パイプラインに組み込みやすくなっています【5】。

Envoy と Istio の主要機能比較

Control Plane と Data Plane の抽象度差を踏まえて、代表的な機能ごとに両者の実装・運用上の違いをまとめます。情報は 2026 年時点の最新リリース（Envoy 1.28 系、Istio 1.20 系）に基づきます。

トラフィック管理（ルーティング・リトライ）

結論：Envoy は粒度の細かい制御が得意。Istio は宣言的に全体を俯瞰しやすく、運用負荷が低減します。

セキュリティと mTLS の実装差

• Envoy
• tls_context に証明書・鍵を手動で設定。ローテーションは外部スクリプト（例：cert‑manager）や CI パイプラインが必要【6】。

• mTLS はオプションであり、各サイドカーごとに有効化する必要がある。

• Istio

• istiod が自動的に SPIFFE‑based 証明書を発行・更新し、全サイドカー間で mTLS を強制。証明書の有効期限は 90 日でローテーションも自動化【7】。
• ポリシーベースの例外設定（PeerAuthentication）も CRD で管理可能。

結論：頻繁な証明書更新やポリシーベースの例外が必要な環境では、Istio の自動化が大きなメリットです。

観測性：メトリクス・トレースの提供方法

結論：単体デプロイでは Envoy でも観測は可能だが、マルチクラスタやマルチテナント環境では Istio の集中管理が運用コスト削減に寄与します。

アウトライヤーディテクションのアプローチ

• Envoy：outlier_detection フィールドでレイテンシ・エラーレート閾値を直接設定。即時適用され、個別サイドカー単位のチューニングが可能【3】。
• Istio：同機能は DestinationRule.outlierDetection に抽象化。ポリシー単位で複数サービスへ一括適用でき、Kiali から設定状態を確認可能。

結論：機能自体は等価だが、Istio は 宣言的管理 + 可視化 が標準装備されている点が差別化要因です。

運用・導入コストとユースケース別選定指針

サービスメッシュの採用可否は 設定複雑さ、組織のスキルセット、規模感 に依存します。以下では主要なコスト要因と典型的なユースケースを整理し、選択指針を示します。

設定の複雑さと学習曲線

• Envoy
• フィルタ・リスナー設定は YAML が長くなる傾向があり、個別調整に時間がかかる。

• Kubernetes 知識だけで完結しないケースが多く、独自の Admin API スクリプトや CI ツールが必要になることがある。

• Istio

• CRD ベースの宣言的設定は Kubernetes の経験があれば比較的早く習得できる。
• ただし istiod の内部構造（Pilot、Telemetry、Security）を概観する学習コストは残る。

指針：K8s に慣れたチームは Istio が低障壁。独自プロトコルや細かなチューニングが必須の場合は Envoy の直接設定が有利。

CLI/GUI ツールと OSS エコシステム成熟度

指針：運用自動化・可視化を重視するなら Istio のエコシステムが圧倒的に有利。

大規模マルチクラスタ向け vs シンプル構成向き

• 大規模・マルチクラスタ
• Istio の MeshGateway と ServiceEntry により、異なるクラスター間でもポリシーと証明書を一元管理でき、スケール時の運用負荷が低減。

• istiod が各クラスターでフェデレーションモード（Istio‑Remote）として動作し、制御平面を集約可能。

• シンプル構成（単一クラスタ・数十サービス程度）

• Envoy のサイドカーだけでも十分。導入手順が短く、リソース消費も最小化できる。
• テレメトリやセキュリティは外部ツール（例：Linkerd‑compatible Telemetry）で補完可能。

結論：組織の成長ステージに合わせて選択すべきです。初期は Envoy、拡張時に Istio へ段階的移行するパターンも一般的です。

最終的な選定指針

参考文献

1. Istio Documentation – “Getting Started with Istio”. https://istio.io/latest/docs/setup/getting-started/
2. Envoy Proxy – “Supported Protocols”. https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters#supported-protocols
3. Envoy Release Notes 1.27.0 – “Outlier detection improvements”. https://github.com/envoyproxy/envoy/releases/tag/v1.27.0
4. Istio Blog (2020) – “Mixer is deprecated”. https://istio.io/latest/blog/2020/mixer-deprecation/
5. Istio API Reference – “Custom Resource Definitions”. https://istio.io/latest/docs/reference/config/
6. cert‑manager – “Integrating with Envoy for TLS”. https://cert-manager.io/docs/usage/envoy/
7. Istio Security – “Automatic mTLS”. https://istio.io/latest/docs/concepts/security/#automatic-mtls
8. Envoy Stats – “Prometheus stats endpoint”. https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/statistics#prometheus-statsd |
9. CNCF Landscape – “Service Mesh Projects”. https://landscape.cncf.io/category=service-mesh

本稿は 2026 年 5 月時点の公式ドキュメントと主要ブログ記事を基に作成しています。