Envoy の設定モデルは、どこにデプロイしても変わりませんが、どこにデプロイするかによって、解決する問題が変わります。このガイドでは、一般的なデプロイのパターンと、Envoy の 1 つの特性、つまりアプリケーションごとに 1 つ実行できるほど軽量であることが、その中で最も興味深いパターンを可能にしている理由を説明します。

エッジプロキシ：ネットワークの玄関口

エッジにデプロイされた Envoy は、外部の世界と内部サービスの間に位置し、外部クライアントからの ingress トラフィックを受け付け、逆方向では、自分たちのサービスが外へ送る egress トラフィックを処理します。これは古典的な API ゲートウェイやロードバランサーの位置づけです。1 つの（または少数の冗長な）Envoy インスタンスが、どちらの方向であれ、ネットワーク境界を越えるすべてのものについて、TLS の終端、ルーティング、レート制限を行います。

フロントプロキシ：共有される内部ロードバランサー

より単純な内部パターンです。すべての内部サービスがリクエストを送る先の、単一の Envoy（または小さな Envoy のクラスター）が、それを適切なバックエンドに分散します。これは従来の内部ロードバランサーのように見えますし、機能的にもそのとおりですが、専用のロードバランサーアプライアンスの代わりに、Envoy のルーティングとヘルスチェックで実装されている点が異なります。

サイドカー：サービスインスタンスごとに 1 つの Envoy

これが、Envoy を他のほとんどのプロキシと区別するパターンです。多くのサービスのトラフィックを処理する共有インスタンスの代わりに、Envoy インスタンスが、各サービスの各インスタンスの隣で実行されます。Kubernetes の用語では、同じ Pod 内の 2 番目のコンテナです。各サービスのインバウンドとアウトバウンドのトラフィックは、共有されたものではなく、そのサービス専用のプロキシインスタンスを通って流れます。

この近さから、2 つのことが直接導かれます。

• アプリケーションがネットワークを意識する必要がなくなる。 リトライ、タイムアウト、TLS、ロードバランシングのロジックが、アプリケーションコードから、すぐ隣にあるプロキシに移ります。これは、Envoy の設計が実現しようとした関心事の分離そのものです。
• トラブルシューティングが速くなる。 Envoy がネットワークのどこか別の場所にある共有コンポーネントである場合、問題はアプリ、プロキシ、両者の間のネットワークパスのいずれにもあり得ます。Envoy が、それが担当する 1 つのアプリケーションインスタンスのすぐ隣で動作していれば、その曖昧さはほとんどなくなります。サイドカーがアプリへの接続は正常だと報告しているのにリクエストが失敗するなら、探すべき範囲は大幅に狭くなっています。

インスタンスごとに 1 つの Envoy を動かすことは、Envoy が意図的に軽量だからこそ成り立ちます。インスタンスごとのフットプリントが重いプロキシは、この密度でデプロイすると、アプリケーションを実行するコストを実質的に 2 倍にしてしまうでしょう。

サービスメッシュ：協調するサイドカー

サービスメッシュは、サイドカーパターンをアプリケーション全体に一貫して適用したものです。すべてのサービスインスタンスが独自の Envoy を持ち、それらすべてのプロキシが、個別に管理される独立したインスタンスとしてではなく、1 つの協調するシステムとして設定され、監視されます。ここで Envoy のトラフィック管理機能、リトライ、サーキットブレーキング、相互 TLS、きめ細かなルーティングが、個々のサービスのコードで実装する必要なく、メッシュ内のすべてのサービスに一様に適用されます。

何百もの個別の Envoy インスタンスを手作業で設定するのは現実的ではありません。そのため、サービスメッシュは「Envoy をたくさんデプロイしただけ」ではなく、Envoy の上に構築された独自のレイヤーとして存在しています。Istio は最も代表的な例です。そのデータプレーンは Envoy そのもので、Istio 独自のコントロールプレーンである istiod が、サービスとポリシーの変更に応じて、各サイドカーの設定を自動的に生成して配信します。Istio がサイドカーを注入した Pod に kubectl exec で入ってログを見ると、実際に動作しているのは、手作業ではなく Istio によって設定された、本物の Envoy プロセスです。

混在したパターンは普通

本番のトポロジーは、これらのうち複数を組み合わせるのが普通です。クラスター全体の ingress と egress を処理するエッジの Envoy と、その内部でサービス間トラフィックを処理するサイドカーの Envoy などです。Envoy は単一のパターンを強制するものではありません。1 つか、組み合わせかを選ぶのは、どのトラフィックにどの種類の制御が必要かという問題であり、プロキシの制約ではありません。