eBPFとWASMに思いを馳せる2022 ～TechFeed Conference 2022講演より

本記事は、2022年5月に開催されたTechFeed Conference 2022のセッション書き起こし記事「eBPFとWASMに思いを馳せる2022（Masaya Aoyama⁠）⁠ — TechFeed Conference 2022講演より」を転載したものです。オリジナルはTechFeedをご覧ください。

本日は「eBPFとWASMに思いを馳せる2022」というテーマで、CyberAgentの青山が発表させていただきます。

ふだんはKubernetes基盤のプロダクトオーナーとして勤めるほか、いくつかの会社で技術顧問やカンファレンスのCo-chairなどを務めています。また著書としては『Kubernetes 完全ガイド』（⁠インプレス）があります。

本日は、WASMとeBPF関連のプロダクトの紹介を行っていきたいと思います。

WASMのおさらい

WASMのおさらいですが、WASMではさまざまな言語で関数を実装して、WASMバイナリとしてビルドして、たとえばブラウザに組み込まれたWASMランタイム上で動作させることができます。これをLinuxカーネル上やProxy上で動作させるために、WASI / Proxy-WASMといったインターフェースが整備され、ある程度制約はあるのですが、一般的なサーバサイドアプリケーションやProxyに対する拡張モジュールとして、WASMモジュールを動作させられるようになりました。

たとえばProxyに対する拡張モジュールを実装しようとした場合ですが、Proxyの処理の特定のタイミングでWASMモジュールが呼び出され、任意の処理を行わせることができます。このときProxy側の機能を呼び出すHost関数を利用することもできます。

このようにProxy-WASMでは、 Proxy側から呼び出される方向と、Proxy側を呼び出す側の2種類の方向が定義されています。Proxy側からWASMモジュールを呼び出すフックポイントもさまざまありますし、WASMモジュールから使えるProxy側の機能もインターフェースとして多岐に渡って定義されて用意されています。

API Clarity ―Proxy-WASMを利用したプロダクトの一例

今回紹介するプロダクトのAPI Clarityも、このProxy-WASMを用いて実装されたプロダクトです。

API Clarityでは、使われてないAPIやOpenAPI specにないAPIを検知したり、収集した情報からOpenAPI specを再構成したりする機能を持っているプロダクトです。

API Clarityでは、サービスメッシュとして展開されている各Envoy ProxyにWASMモジュールをロードして、これから紹介する処理を行っています。

どんな処理かというと、HTTPリクエストを受けたときから内部でcontextを取り回しながら情報を収集します。

API Clarityの処理 - WASMモジュールをロードして、内部でcontextを取り回しながら情報を収集する

終了時に再びWASMモジュールの関数が呼び出されるので、データを成形して、先ほどのHost関数を使ってHTTPリクエストを送っていくような形になります。

API Clarityの処理 - 先ほどのHost関数を使って任意のクラスタにHTTPリクエストを送信

ちなみにWASMモジュールをEnvoyに組み込む場合は、フィルタに設定を行うことでロードできるようになっています。将来的にはOCIイメージ化されたWASMモジュールをロードするような仕組みも整備されていきそうです。

API Clarity自体は斬新なプロダクトというわけではないのですが、「⁠Proxy-WASMを利用して拡張する例」は頭に置いておくと、実現方法のひとつにはなっていきそうです。

ほかにもポリシーエンジンのOPA（Open Policy Agent）も、 WASMモジュールで拡張できるようになっていたりします。

WASMランタイムでありプラットフォーム wasmcloud

もうひとつWASMネタとしては、本日は解説をスキップするんですが、wasmcloudにも興味を持っています。まだまだ日が浅いプロダクトですが、挑戦的に新たなコンピューティングの可能性を模索しているため、興味を持っています。

Capability Providerという機能があったり、Networkingにはアクターモデルを使っていて、さまざまなデバイスをスコープに掲げていたり、グローバルなSupercluster(NATS Supercluster)を使って、広域に展開したりといったこともスコープに入っています。

eBPFの現状

最後にeBPF周りのお話をしたいと思います。

eBPFはカーネルのソースコード変更やカーネルモジュールの組み込みをせずに、任意のプログラムをカーネルに組み込む機能になっています。

カーネルモジュールとは異なって、カーネルをクラッシュさせないように検証する機能などもあるんですけど、それによって使える機能の制限とか文法上の制約というのがあります。eBPFプログラムはイベント駆動で動作して、システムコール・カーネルのトレースポイント・ネットワークイベントなどのフックポイントで呼び出されて実行されるような形になっています。

eBPFを活用している領域としては、たとえばNetworkingのCalicoやCilliumだと、KubernetesのKube-Proxyがやっていたサービスのバランシングの部分をeBPFを使っていたり、あとはサービスメッシュを構成する際にSidecarとしてデプロイされていたEnvoyを削除して、その部分の処理をeBPFが処理していたりします。オブザーバビリティの文脈ではPixieなどがeBPFを用いてカーネル空間を含めて多岐に渡るデータを取得していたり、セキュリティの文脈のFalcoだと、カーネル空間のイベントをフックすることでアラート発報していたりします。Falcoは以前はカーネルモジュールを利用していたんですが、途中からこのeBPF probe modeになりました。

このようにeBPFの恩恵で低レイヤのプログラマビリティが向上したことによって、ノードのカーネルレベルでの機能拡張や高性能化が可能になってきています。

まとめ

ということで、2022年はもっとeBPFやWASMが推進されていくと思うので、楽しみにしていきましょう。

ご視聴ありがとうございました。