Envoy 概論 — sidecar 化のメリット・デメリットと他製品比較

このドキュメントでは、Step 04 で触った Envoy について、その立ち位置・基本概念・配置パターン・他製品との比較をまとめます。

Step 04 の README は「動かすための最小設定」だけに絞ってあるので、こちらは「なぜ Envoy なのか」「sidecar にすると何が嬉しくて何が痛いのか」「世の中にどういう選択肢があるのか」を扱います。

1. Envoy とは

Envoy は、Lyft が 2016 年に OSS 公開し、現在は CNCF の Graduated プロジェクト になっている L4/L7 プロキシ です。

ひとことで言うなら、「ネットワーク I/O の責任をアプリから剥がして、独立したプロセスに集約するための高機能プロキシ」です。

「Istio が Envoy を使っている」と紹介されることが多いですが、Envoy は Istio に依存していません。素の Envoy 単体でリバースプロキシ、API ゲートウェイ、egress プロキシとして使えます。

2. なぜ生まれたか — 「ライブラリでやればいいじゃん」では足りなかった話

Envoy 以前、レイテンシ制御 / リトライ / サーキットブレーカ / mTLS / メトリクス収集といった「ネットワーク横串」の機能は、各言語のライブラリ (Hystrix, Finagle, gRPC interceptors など) で実装されていました。

これがマイクロサービス化の進行とともに痛くなった:

1. 多言語問題: Go, Python, Java, Ruby, Node, Rust… 全部に同じ品質の HTTP/2 + mTLS + retry + circuit breaker を実装するのは現実的でない。
2. アップグレード問題: 新しい暗号スイートを使いたいたびに、全社の全アプリを再リリースする必要があった。
3. 観測性の品質ばらつき: 各ライブラリが好き勝手なメトリクス命名・タグをしていた。
4. TLS 終端の重複実装: アプリごとに crypto/tls を組み立てていた (まさに Step 03 の状態)。

Envoy の発想は 「外出し」 です。アプリは平文 HTTP / TCP を喋って、Envoy が その横で TLS / リトライ / メトリクス / トレースをやる。アプリは言語非依存に薄くなる。

3. アーキテクチャの基本概念

Step 04 で扱ったものを再整理して、L7 (HTTP) の概念も含めて並べます。

    flowchart TD
    L["listener (:9445)"]
    L --> FC["filter chain"]
    FC -->|TCP の場合| TP["tcp_proxy filter"]
    FC -->|HTTP の場合| HCM["http_connection_manager"]
    HCM --> RC["route_config"]
    TP --> CL["cluster"]
    RC --> CL
    CL --> EP["endpoint(s)\n上流の host:port 群"]
    EP --> TS["transport_socket\nTLS 設定はここに付く"]
    TS --> US["上流サーバー"]
  

コアな単語

“Listener filter” と “filter chain” の違い (Envoy の罠その 1)

• listener filter: 接続が filter chain にディスパッチされる前 に走る (例: tls_inspector が SNI を読んで filter chain を選ぶ)。
• filter chain: 実際の処理本体。

最初は混同しやすいですが、「listener filter は前さばき、filter chain は本処理」と覚えればよいです。

4. xDS — 動的設定のしくみ

Step 04 では static_resources だけを使いました。本番運用では xDS API で外部の control plane (Istiod, Consul, 自作) から設定を流し込みます。

xDS は本質的には gRPC streaming で設定 protobuf を流すだけ の仕組みなので、自作の control plane も書こうと思えば書けます。Istio の Istiod は Kubernetes の Service / Endpoint / Pod を見て、それを Envoy 設定に変換して xDS で配るだけのコンポーネントです。

5. 配置パターン

Envoy はどこに置くかで全然違うものになります。

(a) Edge proxy / API gateway

[インターネット] ──HTTPS── [Envoy (edge)] ──HTTP── [サービス群]

「外から内」の入口 に立てる古典的なリバースプロキシ用法。TLS 終端、認証、レート制限、WAF 機能などをここに集約する。AWS ALB / nginx の代替。

(b) Sidecar (Step 04 でやった形)

Pod {                                          Pod {
  [App] ──localhost── [Envoy] ─────mTLS─────────> [Envoy] ──localhost── [App]
}                                              }

各アプリと同じネットワーク名前空間に Envoy を 1 個ずつ立てる。アプリは平文 localhost で Envoy と喋り、Envoy 同士が外で mTLS する。Istio / Linkerd / Consul の標準形。

(c) Internal / mesh-wide gateway

サービス間通信の中継地点として中央に立てる。マルチクラスタを橋渡ししたり、外部システムへの egress を 1 箇所に集めて監査する目的で使う。

これらは 同じ Envoy バイナリ で、設定だけが違います。

6. Sidecar 化のメリット

「アプリの隣に Envoy を立てる」 (Step 04 の構図) で何が嬉しいか:

Step 03 のクライアントで tls.Config を組み立てていた責任が、Step 04 では 「YAML を書く運用チームの責任」 にシフトしました。これがメリットの本質です。

7. Sidecar 化のデメリット / 罠

タダではありません。

特に 「リソースオーバーヘッド × Pod 数」 は規模が大きいほど痛くなります。これが後述の “sidecarless” の動機です。

8. 他のプロキシとの比較

L4/L7 プロキシは Envoy だけではありません。本チュートリアルが扱っているのは TCP (L4) レイヤの mTLS なので、各製品が L4 mTLS をどこまでサポートしているかも観点に入れて比較します。

ざっくりした使い分け:

• エッジで TLS 終端だけしたい → nginx / Traefik / Caddy で十分なことが多い。
• ゲートウェイで API 認証 / レート制限 / トランスフォームをやりたい → Envoy ベースのゲートウェイ (Gloo, Emissary, Contour, Envoy Gateway) または Kong。
• マイクロサービス間で mTLS / retry / observability を統一したい → Envoy sidecar (= Istio / Consul) または Linkerd。
• 任意の TCP プロトコル (Postgres / Redis / 独自バイナリ) に mTLS を被せたい → Envoy tcp_proxy か HAProxy mode tcp。HTTP 前提のプロキシ (Caddy / Traefik / ALB) は外す。
• HFT / 数 µs のレイテンシが死活問題 → どれも避ける (アプリ内蔵 or DPDK/eBPF 直書き)。

9. Service mesh 製品の比較

「Envoy を sidecar として運用するための制御層 (control plane)」 を提供するのが service mesh です。代表的なもの:

選ぶときの軸:

1. 規模: 数十 Pod なら Linkerd の運用負荷の低さが効く。数千 Pod を超えるなら Istio の機能性と Cilium の効率性が候補。
2. 既存スタック: 既に Consul や HashiCorp を使っているなら Consul Connect。AWS にロックインしているなら App Mesh の代替を検討 (上述の通り EOL)。
3. 言語/プロトコル: gRPC や HTTP/3 を多用するなら Envoy ベースが安心。

10. “Sidecarless” の流れ

Sidecar の 「Pod 数 × Envoy のコスト」 を減らす方向の動きが 2023〜2025 年で主流になりつつあります。

(a) Istio Ambient mode

Istio が公式に出したアーキテクチャ。

Node ┌──────────────────────────────┐
     │ ztunnel (per-node, Rust)      │  ← L4 mTLS だけここでやる
     │                               │
     │ waypoint (per-namespace/SA)   │  ← L7 が要るときだけ Envoy をここに置く
     └──────────────────────────────┘

• L4 + mTLS はノードあたり 1 個の ztunnel (Rust) で全 Pod 分を肩代わり。
• L7 (RBAC, JWT, トラフィックスプリット) が要るときだけ、必要に応じて Envoy ベースの “waypoint” を立てる。

メモリ消費が劇的に減る代わりに、設定の境界がノード単位 に変わるので運用感が違う。

(b) Cilium Service Mesh

eBPF (カーネル空間のフック) でパケットを直接いじる発想。

• L4 mTLS や identity ベース認可は eBPF で完結 (sidecar 不要)。
• L7 が要るときだけ Envoy を使う (per-node)。
• Linux カーネル機能に依存するので、CNI ごとリプレースする決断になる。

(c) gRPC / proxyless mesh

gRPC のクライアントライブラリが xDS を直接喋り、Envoy なしでサービスディスカバリ・LB・mTLS を行うモード。

• 言語が gRPC + xDS 対応に縛られる (Go, Java, C++ など)。
• 多言語を諦めるならアプリのリソース消費は最小。

sidecar はもう不要か?

「用途次第で混在する」が現状の答えです。

• L7 の細かい制御 (header rewrite, JWT 検証, WASM フィルタ) が必要 → sidecar / waypoint で Envoy
• L4 の mTLS と identity だけで十分 → ztunnel / eBPF
• 単一プロトコル (gRPC) で多言語対応が不要 → proxyless

11. 使い分けのまとめ

「sidecar 化したほうがいいか」のざっくり判断:

関連

• Step 04 — Egress sidecar で mTLS を肩代わり (Envoy / HAProxy) : 本ドキュメントの内容を最小構成で動かす実習。Envoy 版を本編に、同じことを HAProxy で書いた版を末尾の対応表で示している。
• Envoy 公式ドキュメント
• xDS REST and gRPC protocol
• Istio Ambient Mesh