EnvoyCon 2020が今週、仮想イベントとして開催される。
Kubernetes、Prometheusに続く３番目のCNCF卒業プロジェクトであるEnvoyは、Lyftがオリジナルを開発した、クラウドネイティブなアプリケーションやサービスメッシュアプリケーションに最適な、ハイパフォーマンスのエッジ/ミドル/サービスプロキシである。
EnvoyCon 2020に先立って、InfoQは今回、Envoyの作者でLyftのエンジニア、自称"配管工(plumber)"のMatt Klein氏に、Envoyのテクノロジおよびコミュニティ両面での急成長について聞くことができた。
氏は、マイクロサービスからの移行において開発者が直面する課題、Envoyによる最新の動的ネットワークの仮想化、アプリケーション開発者がビジネスロジックを重視する必要性、などを中心に話してくれた。EnvoyはL4/L7プロキシとして認識されることが多いが、アプリケーション開発者としてはアプリケーション層(L7)の面を重視すべき、というのが氏のアドバイスだ。インタビューの最後には、Envoyの最大の強みであるコミュニティ -- 多様なユーザとベンダの集合体 -- についても言及している。
InfoQ: Envoyの掲げる最上位の目標のひとつとして、"ネットワークはアプリケーションに対して透過的であるべきだ、問題が発生した場合には、問題の根源を簡単に特定できなければならない"、というものがあります。この目標について詳しく説明して頂けますか？
Klein: マイクロサービスアーキテクチャへの移行時にはさまざまな困難に直面しますが、その多くはネットワークと可観測性に関連しています。アプリケーション開発者の視点から、マイクロサービスアーキテクチャをモノリシックアーキテクチャのように見えるようにする(例えば、コンポーネント間の機能呼び出しを"うまく動作させる")のは、実は非常に難しい問題なのです。Envoyは、現在のデプロイメントではごく一般的なものになりつつある、回復性の極めて高い"クラウドネイティブ"なアーキテクチャを念頭に置いて設計されています。Envoyの機能セット(サービスディスカバリ、ロードバランシング、結果整合性構成、クラス最高の可観測性、高度なプロトコルのサポートなど)が、最新の動的ネットワークのアプリケーションからの抽象化を進めることによって、アプリケーションをビジネスロジックに専念できるようにします。
InfoQ: Envoyがなぜ、どのように生まれたのか、歴史的な背景について教えてください。
Klein: 私はAWS、Twitter、現在のLyftと、10年以上にわたって分散システムネットワークに携わってきました。Lyftに来る前には、Twitterの全トラフィックで使用されるエッジプロキシを書いたこともあります。さらにTwitterでは、JVM上で、Finagleベースのライブラリによるアプローチを使って、サービス間のネットワークという厄介な問題をどう扱っているのかも観察しました。そのため、Lyftに来た時には、マイクロサービスアーキテクチャをデプロイする時に一般的に見られるのと同じ(主にネットワーキングや可観測性による、上記のような)問題のすべてに、Lyftが直面していることが分かりました。加えてLyftでは、"多言語(polyglot)"アーキテクチャを採用していたことが、ライブラリベースのアプローチを困難にしていました。EnvoyはこのようなLyftのエッジネットワーキングとサービス間ネットワーキングの問題を、統合的なソリューションを使って同時に解決するために開発されました。エッジと社内ネットワークで単一のプロキシを運用することによって、運用上の複雑性を大幅に軽減することができます。
InfoQ: あなたはEnvoyを"SOAサービス用のバス"と呼んでいますが、その正確な意味について教えてください。マイクロサービスとサービスメッシュは単なるSOAの発展形ではなく、革命ではないのでしょうか？
Klein: マイクロサービスとSOAに、実際に何か違いがあるとは思いません。皮肉っぽく言うなら、"マイクロサービス"とは、コンサルタントとベンダが新製品を売るために考えた言葉なのです。マイクロサービスとSOAが同じものだとすれば、上記の最初の疑問に戻ることになります。それがデプロイの負担を軽減する方法なのです。要約すれば、ネットワークをアプリケーション開発者にとって透過的なものにする、ということに尽きます。この点においてEnvoyは、エッジとサービス間の両方において、さまざまなサービスを結び付ける"コミュニケーションバス"として機能する、ということです。
InfoQ: 開発者あるいはアーキテクトとしては、L4/L7レイヤやロードバランシングの実現方法を考慮する必要があるのではないでしょうか？もしそうであれば、L4/L7にどの程度配慮する必要があるのか、簡単に説明して頂けますか？
Klein: アーキテクチャの最新トレンドは、アプリケーションレベルのコンセプトに集中しています(アプリケーションレベルの認証/承認、アプリケーションレベルのロードバランシング、アプリケーションレベルの可観測性、というように)。ですから私は、現在のアプリケーション開発者の大半は、L4(TCP/UDP)の概念をそれほど理解する必要はない、と思っています (知っていて損はありませんが)。L7では、Envoyが非常に多くの概念を抽象化しているとは言え、すべてが抽象化されている訳ではありません。例えばHTTPのリトライやタイムアウトなどは、アプリケーション特有のものであることも多く、アプリケーション開発者からの何らかのインプットを必要とします。アプリケーション開発者に対する私からのアドバイスは、L7におけるネットワークの概念を学ぶことに持ち時間を集中せよ、ということです。
InfoQ: Envoyは一般的にHAProxyやNGINXと同次元で語られていますが、開発者として現在のプロキシを選択する場合、競合製品の中からEnvoyを選ぶべき理由は何でしょうか？
Klein: 私はいつも、トレンドを追うのではなく、自分にとって有益なテクノロジを選択するように、と話しています。HAProxyとNGINXはいずれも長く使用されてきた、素晴らしい、安定したプロジェクトです。しかしEnvoyが非常にポピュラーになったのには、コミュニティ主導のテクノロジ優先アプローチ、高い回復性を備えたクラウドネイティブなデプロイメントを念頭に構築された、一貫性のあるコンフィギュレーションエンジン(xDS)、安定性、動作速度、セキュリティの重視といった、また別の理由があるのです。私はいつも、解決すべき問題に集中するように話しています。Envoyがその問題解決に適しているのならば、それが最良の選択ということです！
InfoQ: EnvoyCon 2020が今週開催されますが、Envoyのコミュニティや全般的なロードマップ、特にテクノロジとコミュニティの両面から注目する必要のある分野については、どのうような評価をしていますか？
Klein: Envoyコミュニティの成長の早さには、ずっと驚かされ続けています。オープンソースとして公開してわずか4年で、現在のような姿のプロジェクトになるとは、全く想像もしていませんでした。"ロードマップ"についてはよく質問されるのですが、現実としてコミュニティの先導するプロジェクトなので、私としては、誰かがいつも何かをやっているというような、漠然とした感覚しか持っていません。私の知っている大きなものとしては、QUIC/HTTP3、WASM、セキュリティへの継続的投資、追加されたコンフィギュレーションオプション用の新しいxDS API、といったものがあります。ですが、本当にたくさんのことが進んでいて、把握するのが難しいのです。投資分野という意味では、ドキュメントや例題、汎用CI/リリースツールなどが、いつも多くの支援を必要としています。いずれも非常に影響の大きな分野なのですが、自分たちの日々の作業に直接的に関連するものでないことが多いため、作業してくれる人を探すのが難しいのです。
要約すると、氏はまず、Envoyがネットワーク層の複雑性を抽象化することによって、アプリケーション開発者のサービスメッシュやマイクロサービステクノロジ関連を基盤としたソリューション実装を支援する点を説明した上で、サービス指向アーキテクチャ(SOA)との類似点を示し、マイクロサービスは実際にはSOAの一形態である、と述べている。そして最後に、Envoyコミュニティの急成長について述べるとともに、支援を求めている分野について説明している。
資料と入門マニュアルは、いずれもenvoyproxy.ioで提供されている。