Envoy は『現代マイクロサービスインフラの中核』
Envoy は CNCF の L7 プロキシで、Istio/Linkerd 等の Service Mesh の中核となっています。本記事では編集部の視点で、実務での使い方を公開情報をもとに整理します。Service Mesh 実践 もご参考に。
Envoy の特徴
(1) C++ 実装：超高性能。(2) HTTP/2/3 ネイティブ。(3) gRPC 一級サポート。(4) xDS API：動的設定。(5) 豊富な filter：拡張容易。
主要なユースケース
(1) L7 Load Balancer：API Gateway として。(2) Service Mesh の data plane。(3) Edge Proxy：CDN前段。(4) Ingress Controller。(5) Observability hub：traces/metrics。API Gateway 実践 もご参考に。
xDS API
(1) 動的な設定更新：再起動不要。(2) LDS/RDS/CDS/EDS：4階層。(3) gRPC ストリーミング。(4) Istio Pilotが xDS サーバー。(5) Custom xDS：独自実装可能。
フィルタチェーン
(1) リスナー → ネットワークフィルタ。(2) HTTP Connection Manager。(3) HTTP フィルタ：認証/レート制限等。(4) ルーター。(5) クラスタ → エンドポイント。
主要な HTTP フィルタ
(1) JWT 認証。(2) OAuth2 統合。(3) ratelimit：Redis ベース。(4) compressor：gzip/brotli。(5) WASM filter：独自ロジック。WebAssembly 実践 もご参考に。
運用上の注意点
(1) 設定が複雑：学習コスト高。(2) メモリ使用量：適切なサイジング。(3) 監視必須：admin API/stats。(4) SIGUSR1 でログ rotate。(5) hot restart：ダウンタイム最小化。Observability 実践 もご参考に。
Istio との関係
(1) Istio の data planeとして動作。(2) Pilot → Envoy 設定配布。(3) Mixer は廃止(現在は Telemetry V2)。(4) Sidecar 注入。(5) Ambient Mesh：サイドカーレス選択肢。
失敗しがちなパターン
(1) 設定ミス：YAML 複雑。(2) メモリ枯渇：接続数過多。(3) 監視欠如。(4) 過剰な filter：レイテンシ増。(5) xDS 配布遅延。対策は、(1)Schema validation、(2)limit 設定、(3)stats endpoint 監視、(4)必要 filter のみ、(5)Pilot HA、です。