プロキシにおける拡張性の再定義 - EnvoyとIstioへのWebAssembly導入
WASMを用いたIstio拡張性の未来。
2016年にEnvoyを採用して以来、Istioプロジェクトは常に、ユーザーの多様なニーズを満たすために、豊富な拡張機能を構築できるプラットフォームを提供することを目指してきました。サービスメッシュのデータプレーンに機能を追加する理由は数多くあります。例えば、新しいプロトコルをサポートしたり、独自のセキュリティ制御と統合したり、カスタムメトリクスで監視機能を強化したりすることが挙げられます。
過去1年半、GoogleのチームはWebAssemblyを使用してEnvoyプロキシに動的な拡張性を追加することに取り組んできました。本日、その成果とWebAssembly (Wasm) for Proxies（Proxy-Wasm）を発表できることを嬉しく思います。これは、標準化を目指したABI、SDK、そして新しい低遅延のIstioテレメトリシステムという最初の主要な実装です。
また、コミュニティと緊密に協力して、ユーザーが迅速に開始できる優れた開発者エクスペリエンスを確保しました。GoogleチームはSolo.ioのチームと緊密に協力し、Wasm拡張機能の構築、共有、検出、展開のためのサービスであるWebAssembly Hubを構築しました。WebAssembly Hubを使用すると、Wasm拡張機能はコンテナと同じように簡単に管理、インストール、実行できます。
この作業は本日アルファ版としてリリースされ、まだ多くの作業が残っていますが、開発者の皆様にこの素晴らしい可能性を試していただくために、リリースすることに興奮しています。
背景
拡張性の必要性は、IstioとEnvoyの両プロジェクトの創設以来の信条でしたが、両プロジェクトは異なるアプローチを取っていました。Istioプロジェクトは、軽量な開発者エクスペリエンスを備えたMixerと呼ばれる一般的なアウトオブプロセス拡張モデルを可能にすることに重点を置いていました。一方、Envoyはインプロキシ拡張機能に重点を置いていました。
それぞれのアプローチには長所と短所があります。Istioモデルは、テールレイテンシとリソース利用率に影響を与える著しいリソースの非効率性を招きました。このモデルは本質的に制限もありました。たとえば、カスタムプロトコル処理の実装をサポートすることは決してありませんでした。
Envoyモデルは、モノリシックなビルドプロセスを課し、拡張機能をC++で記述する必要があり、開発者エコシステムが制限されていました。新しい拡張機能をフリートに展開するには、新しいバイナリをプッシュして再起動する必要があり、これは調整が難しく、ダウンタイムのリスクがあります。これはまた、ごく一部の展開でしか使用されていない拡張機能をEnvoyにアップストリームするインセンティブを与え、そのリリースメカニズムに便乗していました。
時間の経過とともに、Istioの最もパフォーマンスに敏感な機能の一部はEnvoyにアップストリームされました。例えば、トラフィックに対するポリシーチェックやJWT認証などです。それでも、トレードオフが少ない単一の拡張性スタックに常に収束したいと考えていました。つまり、Envoyのリリースを拡張機能エコシステムから切り離し、開発者が好きな言語で作業できるようにし、Istioがダウンタイムのリスクなしで新しい機能を確実にロールアウトできるようにするものです。そこでWebAssemblyが登場します。
WebAssemblyとは何か？
WebAssembly（Wasm）は、複数の言語で記述されたコードをネイティブに近い速度で実行するためのポータブルなバイトコード形式です。その最初の設計目標は、上記の課題とよく合致しており、業界からの大きな支持を得ています。Wasmは、主要なすべてのブラウザでネイティブに実行される4番目の標準言語（HTML、CSS、JavaScriptに続く）であり、2019年12月にW3C勧告になりました。これは、戦略的にWasmに賭けることに自信を与えてくれます。
WebAssemblyは当初クライアントサイドテクノロジーとして始まりましたが、サーバーで使用することには多くの利点があります。ランタイムはメモリセーフで、セキュリティのためにサンドボックス化されています。テキスト形式またはバイナリ形式のWasmをコンパイルおよびデバッグするための大規模なツールエコシステムがあります。W3CとBytecodeAllianceは、他のサーバーサイドの取り組みの活発なハブとなっています。たとえば、WasmコミュニティはW3Cで“WebAssembly System Interface”（WASI）を標準化しており、サンプル実装を提供しており、Wasm「プログラム」にOSのような抽象化を提供します。
EnvoyへのWebAssemblyの導入
過去18ヶ月間、Envoyコミュニティと協力して、EnvoyにWasm拡張機能を組み込み、それをアップストリームに貢献してきました。Istio 1.5に同梱されているEnvoyビルドでアルファ版として利用可能であることを発表できることを嬉しく思います。envoy-wasm開発フォークにソースコードがあり、メインのEnvoyツリーにマージする作業が進行中です。この実装は、Googleの高性能V8エンジンに組み込まれたWebAssemblyランタイムを使用しています。
基盤となるランタイムに加えて、次のものも構築しました。
プロキシにWasmを埋め込むための汎用アプリケーションバイナリインターフェース（ABI）。つまり、コンパイルされた拡張機能は、異なるバージョンのEnvoy、またはABIを実装することを選択した場合、他のプロキシでも動作します。
C++、Rust、AssemblyScriptでの簡単な拡張機能開発のためのSDK（今後さらに追加されます）。
IstioとスタンドアロンEnvoyでの展開方法に関する包括的なサンプルと手順。
他のWasmランタイムを使用できるようにするための抽象化。これには、拡張機能をEnvoyにネイティブにコンパイルする「null」ランタイムが含まれます。テストとデバッグに非常に役立ちます。
Envoyの拡張にWasmを使用することで、いくつかの重要な利点が得られます。
俊敏性：拡張機能は、Istioコントロールプレーンを使用してランタイムで配信およびリロードできます。これにより、Envoyのロールアウトを必要とせずに、拡張機能の開発→テスト→リリースサイクルが高速化されます。
標準リリース：メインツリーへのマージが完了すると、Istioおよびその他は、カスタムビルドではなく、Envoyの標準リリースを使用できるようになります。これにより、Envoyコミュニティは、いくつかの組み込み拡張機能をこのモデルに移行し、サポートするフットプリントを削減することもできます。
信頼性と分離：拡張機能は、リソース制約のあるサンドボックス内で展開されるため、クラッシュしたり、メモリリークが発生したりしても、Envoyプロセス全体が停止することはありません。CPUとメモリの使用量も制限できます。
セキュリティ：サンドボックスには、Envoyとの通信のための明確に定義されたAPIがあるため、拡張機能は接続またはリクエストの限定された数のプロパティにのみアクセスし、変更できます。さらに、Envoyがこのインタラクションを仲介するため、拡張機能から機密情報を非表示またはサニタイズできます（例：「Authorization」および「Cookie」HTTPヘッダー、またはクライアントのIPアドレス）。
柔軟性：30以上のプログラミング言語をWebAssemblyにコンパイルできます。これにより、C++、Go、Rust、Java、TypeScriptなど、あらゆるバックグラウンドの開発者が、好みの言語でEnvoy拡張機能を作成できます。
「EnvoyにWASMサポートが追加されるのを見るのは非常に興奮します。これは、Envoy拡張性の未来です。EnvoyのWASMサポートとコミュニティ主導のハブを組み合わせることで、サービスメッシュとAPIゲートウェイの両方のユースケースにおいて、ネットワーク分野で信じられないほどのイノベーションが解き放たれます。コミュニティが今後構築するものを楽しみにしています。」– Envoyの作成者、Matt Klein。
実装の詳細については、近日中にEnvoyブログに投稿される記事をご覧ください。
ホスト環境と拡張機能間のProxy-Wasmインターフェースは、プロキシに依存しないように意図的に設計されています。Envoyに組み込みましたが、他のプロキシベンダーが採用できるように設計されています。IstioとEnvoy用に記述された拡張機能を他のインフラストラクチャで実行できる世界を目指しています。そのことについては、まもなく詳細を発表します。
IstioにおけるWebAssemblyの構築
Istioは、パフォーマンスを大幅に向上させるために、1.5リリースの一部として、いくつかの拡張機能をEnvoyのビルドに移行しました。その作業を行う際に、それらの同じ拡張機能が動作に違いなくProxy-Wasmモジュールとしてコンパイルおよび実行されることを確認するためのテストを実施しました。Wasmサポートをアルファ版と見なしているため、この設定をデフォルトにする準備はまだできていませんが、これは、開発されたホスト環境、ABI、およびSDKに対する一般的なアプローチと、大きな自信を与えてくれました。
また、IstioコントロールプレーンとそのEnvoy構成APIがWasm対応であることを確認するようにも注意してきました。カスタムヘッダーのデコードやプログラムによるルーティングなど、ユーザーからよく寄せられる一般的なカスタマイズをどのように実行できるかを示すサンプルを用意しています。このサポートをベータ版に移行するにつれて、WasmとIstioの使用方法に関するベストプラクティスを示すドキュメントが公開されます。
最後に、Mixerアダプターを開発した多くのベンダーと協力して、最適な方法であればWasmへの移行を支援しています。Mixerは今後のリリースでコミュニティプロジェクトに移行し、レガシーユースケースで使用できるようになります。
開発者エクスペリエンス
強力なツールは、優れた開発者エクスペリエンスがなければ意味がありません。Solo.ioは最近、発表したWebAssembly Hubをリリースしました。これは、EnvoyとIstio向けのEnvoy Proxy Wasm拡張機能の構築、展開、共有、検出のためのツールとリポジトリのセットです。
WebAssembly Hubは、Wasm拡張機能の開発と展開に必要な多くの手順を完全に自動化します。WebAssembly Hubツールを使用すると、ユーザーはサポートされている任意の言語でコードをWasm拡張機能に簡単にコンパイルできます。その後、拡張機能をHubレジストリにアップロードし、単一のコマンドでIstioに展開および展開解除できます。
内部では、Hubは、正しいツールチェーンの取得、ABIバージョン検証、権限制御など、多くの細かい作業を処理します。このワークフローでは、拡張機能の展開を自動化することにより、Istioサービスプロキシ間の構成変更による労力を削減します。このツールは、誤った構成やバージョン不一致による予期せぬ動作をユーザーとオペレーターが回避するのに役立ちます。
WebAssembly Hubツールは、強力なCLIと、エレガントで使いやすいグラフィカルユーザーインターフェースを提供します。WebAssembly Hubの重要な目標は、Wasmモジュールの構築に関するエクスペリエンスを簡素化し、開発者が便利な拡張機能を共有および検出するための協調の場を提供することです。
最初のProxy-Wasm拡張機能を作成するには、入門ガイドをご覧ください。
今後のステップ
ベータ版リリースに向けて取り組んでいることに加え、Proxy-Wasmの持続可能なコミュニティを確立することに尽力しています。ABIを最終化し、適切な標準化団体内で幅広いフィードバックを得て標準化を進める必要があります。Envoyメインラインへのアップストリームサポートの完了はまだ進行中です。また、ツールとWebAssembly Hubに適したコミュニティのホームを探しています。
詳細情報
WebAssembly SF トーク（ビデオ）：John Plevyakによるネットワークプロキシの拡張機能
