2021年12月2日、Cilium プロジェクトは、Cilium Service Mesh のベータテストプログラムを発表した。1年以上前の2020年8月に発表された Google Cloud の eBPF ベースの Google Kubernetes Service (GKS) Dataplane V2 によって開拓されたコンセプトに基づいて、Cilium Service Mesh は「サイドカーレスサービスメッシュ」のアイデアを推進している。Cilium eBPF 製品を拡張して、L7 ルーティングとロードバランシング、TLS ターミネーション、アクセスポリシー、ヘルスチェック、ロギングとトレース、組み込みの Kubernetes Ingress など、サービスメッシュのサイドカープロキシ機能の多くを処理する。
Cillium の作成者である Isovalent 氏は、「How eBPF will solve Service Mesh - Goodbye Sidecars (どのように eBPF がサービスメッシュを解決するのか - さようならサイドカー)」というタイトルの記事で、サイドカープロキシに代えて eBPF を使用する理由を説明した:
これにより、サイドカーモデルから解放され、既存のプロキシテクノロジーを既存のカーネル名前空間の概念に統合して、すでに毎日使用している美しいコンテナ抽象化の一部にすることができます。
一言で表すと、eBPF は、サービスメッシュの主な問題点、つまり、きめ細かいマイクロサービスが多数ある場合のパフォーマンスの欠如の解決を約束する。ただし、サイドカープロキシに代えて eBPF を使用することは斬新なアイデアで論争がないわけではない。
(出典: How eBPF will solve Service Mesh - Goodbye Sidecars)
サービスメッシュのデータプレーンとはインフラストラクチャサービスを指している。マイクロサービスアプリケーションとの間でデータトラフィックをルーティングおよび配信する方法を管理する。現在、これはサービスプロキシを使うことで実現されている。このデザインパターンは、一般にサイドカーパターンとも呼ばれている。サイドカーを使用すると、接続されたマイクロサービスがサービスメッシュ内の他のコンポーネントとの間で透過的にリクエストを送受信できる。
サイドカーには通常、Envoy、Linkerd、MOSN などの L7 ネットワークプロキシを含んでいる。プロキシは、トラフィックルーティング、負荷分散、ヘルスチェック、認証、認可、暗号化、ロギング、トレース、および統計収集を処理する。サイドカーは、ネットワークプロキシを超えたアプリケーションサービスを提供するため、Dapr などの SDK ベースのアプリケーションフレームワークを含めることもできる。このようなアプリケーションサービスの例には、サービス登録、サービスディスカバリ、リソースバインディング、名前ベースのサービス呼び出し、状態管理、アクターフレームワーク、およびシークレットストアなどがある。
サイドカープロキシとサービスは通常 Kubernetes Pod またはコンテナ内で実行される。マイクロサービスアプリケーションもコンテナ内で実行され、ネットワークインターフェイスを介してサイドカーに接続する。ただし、これらのコンテナ化されたアプリケーションの重要な問題は、リソースの消費だ。サイドカーサービスは、マイクロサービスの数とともに幾何学的に増加する。アプリケーションに何百もの相互リンクされ負荷分散されたマイクロサービスがある場合、オーバーヘッドが甚大になる可能性がある。サービスメッシュプロキシベンダーは、パフォーマンスを競っている。以前 InfoQ が報告したように、Linkerd はプロキシを Go から Rust に書き直し、顕著なパフォーマンス向上を達成している。
当然のことながら、既存のサービスメッシュプロバイダは、eBPF がすべての問題を解決する聖杯とは考えていない。Idit Levine 氏他。Envoy Proxy と Istio をベースとする大手サービスメッシュプロバイダの Solo.io は Cilium の発表に対応する記事を書いている。この記事のタイトルは「eBPF for Service Mesh? Yes, But Envoy Proxy is Here to Stay. (サービスメッシュのための eBPF? わかりました、しかし Envoy Proxy はここにとどまります)」だ。
Solo.io では、eBPF をサービスメッシュを最適化する強力な方法と見なしており、Envoy プロキシをデータプレーンの基礎と見なしています。
Solo.io の作者が指摘した重要な点は、サイドカープロキシが単なるネットワークトラフィック管理以上のことを行うようになったということだ。今日のサービスメッシュデプロイメントには複雑な要件がある。これは eBPF でサポートされる限られたプログラミングモデルをはるかに超えている。チューリング不完全であり、カーネルの安全性のために多くの制限がある。Cilium eBPF 製品は、すべてではないが、サイドカープロキシによって実行される多様なタスクの多くを処理できる。さらに、Solo.io の作者は、eBPF をノードそれぞれでプロキシを設定すると、柔軟性が大きく低下し、従来のプロキシの Pod それぞれにプロキシを設定する場合に比べ全体的なオーバーヘッドが増えると述べている。これらの eBPF の欠点はアプリケーション固有ロジック (トラフィックルーティング、負荷分散、および開発者がサービスメッシュプロキシに作成、デプロイの必要がある認可) で特に顕著だ。
Terate.io の開発者は、「Istioとサービスメッシュに関するコミュニティでの討論」というタイトルの Cilium の発表に対して、同様の議論を行った。彼らは述べている。今日のサイドカープロキシのパフォーマンスは妥当であり、オープンソースコミュニティはパフォーマンスをさらに向上させる方法をすでに考え出している。同時に、開発者が eBPF のような斬新でチューリング不完全なテクノロジーでアプリケーション固有のデータプレーンロジックを構築することは非常に難しい。
Istio アーキテクチャは安定しており、プロダクションレディで、エコシステムは芽吹いています。
eBPF の問題の多くは、それがカーネルテクノロジーであるという事実に関連して、安全上の制限が必要なことだ。ユーザスペーステクノロジーを使用してパフォーマンスを低下させることなく、複雑なアプリケーション固有のプロキシロジックをデータプレーンに組み込む方法があるのだろうか? WebAssembly (Wasm) がまさにその選択かもしれないことがわかった。Wasm ランタイムは、ネイティブに近いパフォーマンスでユーザースペースコードを安全に分離して実行できる。
Envoy Proxy は、データプレーンをプログラムするための拡張メカニズムに Wasm を使用するアプローチを開拓した。開発者は、C、C ++、Rust、AssemblyScript、Swift、TinyGo などの言語でアプリケーション固有のプロキシロジックを記述し、モジュールを Wasm にコンパイルできる。proxy-Wasm 標準により、プロキシは、Wasmtime や WasmEdge などの高性能なランタイムでこれらのWasmプラグインを実行できる。現在、Envoy Proxy、Istio Proxy、MOSN、および OpenResty が proxy-Wasm をサポートしている。
(コンテナエコシステムの Wasm。出典: WasmEdge Book)
さらに、Wasm は汎用アプリケーションコンテナとして機能することができる。サービスメッシュデータプレーンでのアプリケーションは、サイドカープロキシに限定されない。サイドカーに接続されたマイクロサービスは、独自の軽量 Wasm ランタイムで実行できる。WasmEdge WebAssembly ランタイムは、安全、軽量、高速、ポータブルそしてポリグロットなランタイムで、Kubernetes のコンテナとして直接管理できる。2021年12月までに、コントリビュータの WasmEdge コミュニティは、WasmEdge ベースのマイクロサービスがゲスト OS と完全なソフトウェアスタックを備えた重量級の本格的な Linux コンテナの代わりに Dapr および Linkerd サイドカーで機能することを実証した。Linuxコンテナアプリケーションと比較して、WebAssembly マイクロサービスはリソースの1％の消費とコールドスタートは1％の時間で開始された。
eBPF と Wasm は、データプレーンで高いパフォーマンスを実現するためのサービスメッシュアプリケーションの新鋭だ。まだ初期のテクノロジーだが、マイクロサービスエコシステムにおける今日の Linux コンテナの代替または補完するものになる潜在力がある。