Envoyとは？クラウドネイティブ時代の高機能データプレーン型L7プロキシを徹底解説
エバープレイ編集部Envoy とは — 概要
Envoy（エンボイ）は、モダンなクラウドネイティブ環境向けに設計されたオープンソースの高機能プロキシ（プロキシサーバ）です。主に「サービス間の通信を扱うデータプレーン」として使われ、L4（TCP）/L7（HTTP/HTTP2/gRPC）両レイヤーでのルーティング、負荷分散、TLS ターミネーション、可観測性（メトリクス／トレース／ログ）、フェイルオーバーや回復（リトライ／サーキットブレイカー）といった機能を備えます。もともとは Lyft により開発・オープンソース化され（2016年公開）、その後 Cloud Native Computing Foundation（CNCF）で広く採用されるプロジェクトとなりました。
歴史的背景と位置づけ
マイクロサービス化が進む中で、個々のサービスが多数のサービスと対話するため、プロキシに求められる要件は単純な L4/L7 転送を超えて増大しました。Envoy はこうした要件（動的構成、分散トレーシング対応、サービスメッシュのデータプレーンとしての利用など）を念頭に設計され、軽量なサイドカーとして各サービスにアタッチして使われるパターンを普及させました。結果的に Istio などのサービスメッシュや、Ambassador/Contour/Gloo のようなコントロールプレーン/APIゲートウェイ実装のデータプレーンとして広く採用されています。
基本アーキテクチャ
Envoy の設計は「データプレーン（Envoy 本体）」と「コントロールプレーン（動的設定を配布する仕組み）」という分離を基本にしています。静的なブートストラップ構成も可能ですが、現実的にはコントロールプレーン経由で動的にルーティング／クラスタ情報を受け取り運用することが多いです。
- xDS API（Discovery Service） — Envoy が実行時に設定を受け取るための一連の gRPC/REST API（LDS: Listener、RDS: Route、CDS: Cluster、EDS: Endpoint など）。動的構成と差分更新を可能にします。
- Bootstrap — 起動時に最低限の設定を読み込み、コントロールプレーンのエンドポイントや証明書取得の仕組み（SDS）などを定義します。
- フィルタチェーン — リクエスト処理はリスナー → ネットワークフィルタ（TCP）/HTTPフィルタ として段階的に処理されます。拡張ポイントとしてフィルタが重要です。
主な機能（詳細）
Envoy が提供する主な機能は多岐に渡ります。以下は代表的なものです。
- プロトコル対応 — HTTP/1.1、HTTP/2、gRPC、TCP、WebSocket をネイティブにサポート。ALPN によるプロトコル判定も可能。
- 高度なルーティング — パス、ヘッダ、メソッド、重み付け、ヘルスベース／ロケーショナルルーティング、サブセットルーティング（バージョンやカナリア用）など。
- 負荷分散アルゴリズム — ラウンドロビン、最小接続、ヘルスベース、ローカリティアウェア、Maglev など（実装により利用可能）。
- 回復機能 — リトライ、タイムアウト、サーキットブレイカー、アウトライヤー検出（異常インスタンスの隔離）など。
- セキュリティ — TLS 終端／発信、SNI、ALPN、mTLS（相互 TLS）によるサービス間認証、SDS（Secret Discovery Service）での証明書ローテーション。
- 可観測性 — Prometheus 互換のメトリクス、アクセスログ（JSON など）、分散トレーシング（Zipkin/Jaeger/OpenTelemetry）、統計情報。
- 動的設定 — xDS を介したランタイムでの設定差分適用、ホットリスタートや逐次適用によりダウンタイムを最小化。
- 拡張性 — Lua スクリプト、WASM（proxy-wasm）によるカスタムフィルタ、外部認可（ext_authz）連携など。
- リクエストミラーリング／シャドウイング — 本番トラフィックを別バックエンドに複製してテストする機能。
フィルタと拡張モデル
Envoy の処理パイプラインは複数のフィルタを通すことで機能を追加します。フィルタは HTTP フィルタ、ネットワーク（TCP）フィルタ、アクセスログフィルタ等に分類され、ユーザーは内蔵フィルタを組み合わせるか独自実装を追加できます。
- Lua フィルタ — 軽量なスクリプトでヘッダー操作や簡単なロジック実装が可能。
- WASM（proxy-wasm） — WebAssembly ベースで高速かつ言語に依存しない拡張を可能にし、動的にロードして実行できます。これにより安全かつ高性能なカスタム処理が実現できます。
- 外部認可（ext_authz） — 認可判断を外部サービス（例：OPA、自前の認可サービス）に委譲できます。
セキュリティ面（mTLS と証明書管理）
Envoy はサービス間通信の保護に重点を置いています。mTLS による相互認証、SNI/ALPN による TLS ハンドリング、そして SDS（Secret Discovery Service）を通じた証明書・鍵・ルート CA の動的配布とローテーションをサポートします。これにより、運用中の証明書更新や短期のキー発行が容易になり、ゼロトラストなセキュリティモデルに自然に組み込めます。
可観測性とトレーシング
Envoy はマイクロサービスのトラフィックに関する豊富な観測ポイントを提供します。
- Prometheus 互換メトリクス（ヒストグラムやカウンタなど）
- アクセスログ（フォーマットは JSON を含め柔軟に設定可能）
- 分散トレースとの連携（Zipkin、Jaeger、OpenTelemetry など） — リクエストごとのトレースヘッダの伝搬とスパン生成をサポート
- リアルタイムの統計情報やダイレクトな管理 API（/stats, /clusters など）
デプロイパターンと代表的ユースケース
Envoy は利用シーンに応じて様々に配置されます。代表的なパターンとその用途は次の通りです。
- サイドカー（サービスメッシュのデータプレーン） — 各サービスの Pod/VM にサイドカーとして同居させ、サービス間通信を全て Envoy に通す。Istio や Consul Connect、Kuma、AWS App Mesh のようなコントロールプレーンと組み合わせるケースが一般的。
- エッジ/Ingress プロキシ — 外部からのトラフィックを受ける API Gateway / Ingress Controller として利用（Ambassador/Contour/Gloo などと共に使われる）。
- Egress や データプレーンの集中ルーティング — 外部サービスへの出口制御、TLS 透過やトラフィックポリシーの適用。
- プロキシチェイン／中継 — ネットワーク境界でのプロキシやサービス間の中継として。
他のプロキシとの比較（nginx / HAProxy / Traefik 等）
用途により最適なプロキシは異なります。Envoy の強みと留意点は以下の通りです。
- 強み
- サービスメッシュや動的構成との親和性が高く、xDS によるランタイム制御が可能。
- gRPC/HTTP2 のネイティブサポートや分散トレーシング、細かな L7 制御が充実。
- WASM 等での高機能な拡張が可能。
- 留意点
- Envoy は機能豊富だが、その分学習コスト・運用コスト（コントロールプレーンの導入、リソース消費）が増える。
- 単純な静的リバースプロキシや低レイヤーの高速転送のみが目的なら、nginx や HAProxy の方が設定や運用が単純で効率的な場合がある。
運用上の注意点とベストプラクティス
Envoy を本番導入する際のポイントは次の通りです。
- コントロールプレーンの設計 — xDS を使う場合、どのコンポーネントが設定を生成するか（Istio、Consul、自前のコントロールプレーン）を明確にする。
- リソース管理 — サイドカーを多数配置するとメモリ/CPU の総消費が増えるため、リソース割当やレイテンシ影響を評価する。
- 証明書管理 — SDS による自動ローテーションや SPIFFE/SPIRE 等との連携でスムーズに運用する。
- 監視とアラート — メトリクス、アクセスログ、トレースを組み合わせて SLA の監視と障害切り分けに備える。
- 段階的導入 — ミラーリングやカナリア配信を活用して徐々にルールを適用・評価する。
誰が使っているか（採用事例）
Envoy は Lyft のほか、多くのクラウドプロバイダや企業で採用されています。サービスメッシュ（Istio）、AWS App Mesh などのデータプレーン、API Gateway 製品（Ambassador / Emissary、Contour、Gloo）などで広く利用されており、クラウドネイティブの標準的コンポーネントの一つになっています。
まとめ
Envoy は「クラウドネイティブ時代の汎用 L7（＋L4）プロキシ」として、動的構成、観測性、セキュリティ、拡張性に優れた設計を持ちます。マイクロサービス間通信の制御やサービスメッシュのデータプレーン、エッジの API Gateway として特に力を発揮します。一方でその多機能性ゆえの運用の複雑さやリソース消費というトレードオフがあるため、導入時はユースケースを明確にし、コントロールプレーンや監視基盤を含めた設計を行うことが重要です。
参考文献
- Envoy Proxy 公式サイト / ドキュメント
- Envoy GitHub リポジトリ
- CNCF — Envoy プロジェクトページ
- Lyft Engineering — Envoy に関する紹介記事（オリジン）
- Envoy ドキュメント — アーキテクチャ概要
- Envoy ドキュメント — xDS API（Discovery Service）
投稿者プロフィール
