eunomia-bpf eBPF lightweight development framework

1、まとめ

eBPF プログラムの現在の開発と配布プロセスには、いくつかの課題がある。

まず、初心者にとって eBPF プログラムの構築と開発のハードルは高い。カーネルモードとユーザーモードの両方での対話と情報処理に注意を払う必要があり、ユーザーモードのローディングコードも記述する必要がある。

次に、さまざまな eBPF プログラムを、異なるアーキテクチャの異なるカーネルバージョン上で、便利かつ迅速にパッケージ化、配布、リリースできない。eBPF の多くの小規模ツールは異なる言語で開発され、異なるインターフェースを持つため、大規模な可観測性システムに簡単に統合できない。

さらに、現時点では優れたプラグインソリューションが存在しない。多くの場合、観測性フレームワーク全体を再コンパイルしてオンラインに再デプロイしないと、eBPF プローブやデータ処理モジュールを更新できない。さらに、サードパーティのユーザーモードデータ処理コードを導入すると、コードのクラッシュがプログラム全体のクラッシュを引き起こす。

そこで、2 つのソリューションを提案する。

まず、初心者向けに、カーネルモードのコードを記述するだけで、カーネルステートからエクスポートされるデータを自動的に取得でき、コンパイル後にロードして実行できる。これにより eBPF の学習コストが削減され、開発効率が向上する。

次に、libbpf が「一度コンパイルすればどこでも実行できる」という機能に基づき、ユーザーモードとカーネルモードのコンパイルと実行を完全に分離し、標準的な JSON または WASM モジュールを通じて配布する。再コンパイルは不要で、アプリケーションの起動に必要なリソースが少なく、時間も短縮され、コンテナの起動もさらに短時間になる。

さらに、JSON/WASM 配布など、標準化された配布方法を提供したいと考えている。WebAssembly はスタックベース仮想マシンをベースとしたバイナリ形式で、移植性を目的として設計された。当初は C、C++、Rust で書かれたコードをブラウザで実行可能にすることを目指していたが、現在では軽量でハイパフォーマンス、クロスプラットフォーム、多言語対応のサンドボックス環境に進化し、クラウドネイティブソフトウェアやコンポーネントにも適用可能になっている。設計思想は eBPF と似ているが、カーネルモードで実行されるかユーザーモードで実行されるかという違いがある。

両者の組み合わせを試みている。たとえば、カーネルコードのみの場合、eBPF プログラム全体を JSON にパッケージ化できる。JSON には各種設定情報が含まれる。たとえば、カーネルモードからユーザーモードにレポートされるデータのメモリレイアウト情報や、設定が必要なグローバル変数などである。これにより、カーネル eBPF プログラムの設定の大部分を JSON のみで完了でき、正しくロードできる。

WASM と組み合わせると、ユーザーモードではデータ処理、設定情報、完全なコマンド、関数解析などを WASM でパッケージ化し、eBPF と一緒に配布する。

2、使用例

Eunomia は完全なシステムではなく、開発ライブラリや開発フレームワークに近い。coolbpf ツールチェーンに簡単に組み込め、他のプログラムにも開発ライブラリや開発フレームワークとして組み込める。

事前コンパイル済みの eBPF プログラムを、1 行のコマンドで Web ページから直接ダウンロードして実行できる。WebAssembly または JSON モジュールを使用して配布する。デプロイ時の再コンパイルは不要で、起動速度は速い。

図の形式は URL に配置されている。OCI イメージや Docker イメージに変更することもできる。Docker リポジトリや GitHub パッケージに保存できる。使用方法は Docker と基本的に同じで、pull と run を実行するだけで動作する。コンパイル済みパッケージを直接使用することもできる。

従来の Docker イメージと比べて起動速度が速く、eBPF の重要な機能を維持している。サブモジュールやプラグインとして他のプログラムに簡単に組み込める。

Eunomia を使用すると、カーネルモードのコードを記述するだけで正しく動作するため、初心者が簡単に始められるようユーザーモードのローディングフレームワークの記述を省略でき、カーネルモードの perf イベントやリングバッファイベントを自動的にエクスポートできる。さらに、ネイティブの libbpf と完全に互換性があり、libbpf ツールのカーネルステートコードをコード変更なしで直接取得して実行できる。

追加のトレースポイントやその他の内容をコメント形式で追加できる。コンテナを使用してツールチェーンをパッケージ化・コンパイルできるため、環境設定の問題を心配する必要がない。1 行のコマンドでプロジェクトテンプレートを生成し、1 行のコマンドでコンパイルできる。

完全な eBPF ツールは通常、ユーザースペースとカーネルスペースに分かれている。ユーザースペースはカーネルモードから返される統計情報と設定情報の読み取りとロードを担当し、WASM でユーザーモードの補助プログラムを記述できる。WASM 自体が安全で効率的なユーザーモードのデータ処理と制御ロジックである。ユーザーモードでは他のアプリケーションへの干渉を心配する必要がなく、非常に高速に動作する。

ユーザーは C、C++、Go、Rust などの複数の言語で記述でき、これらはすべて WASM にコンパイルできる。カーネルモードのコードとユーザーモードのコードを一緒にパッケージ化して WASM モジュールを生成し、WebAssembly の関連エコシステムを活用して eBPF プログラムを配布・管理する。大規模アプリケーションにプログラム可能なモジュールやプラグインとして組み込める。

現在、libbpf ツールで記述されたツールを直接 WASM モジュールにコンパイルして配布する機能を実現している。

このプロセスでの主な課題は、WebAssembly のメモリレイアウト（構造体のメモリレイアウトなど）が eBPF とは完全に異なるため、API でデータのシリアル化や変換のオーバーヘッドが発生する可能性があることである。同時に、WebAssembly 自体が仮想マシンのサンドボックス環境で実行されるため、アクセスできるシステムリソースにも制限があり、追加の変換処理が必要になる。

3、システムアーキテクチャ

アーキテクチャの基盤はカーネルモードとユーザーモードのインフラストラクチャ（libbpf ライブラリやカーネルなど）に依存しており、関連するコンパイルツールチェーンを提供して JSON や WASM にパッケージ化されたモジュールの生成を支援する。ツールチェーン自体は Clang/LLVM や bpftool などのツールを使用する。動的ロードライブラリは独立して使用でき、WASM に依存せず、JSON 情報に基づいて eBPF プログラムを動的にロードできる。外側に HTTP を配置することで Web サービス形式に変換し、カーネル関数をサービスとして提供できる。

WASM 抽象化レイヤーも実装している。API 仕様（WASM を拡張するための WSAI システムが占有するアクセス形式や、eBPF との対話形式など）が含まれる。また、WASM に基づいてカスタマイズされた libbpf ライブラリ、ポータブルな補助状態プログラム、シリアル化ライブラリがあり、これらは WASM モジュール内で libbpf ベースの eBPF プログラムをロードするために使用される。

ランタイムライブラリは簡単に置換可能で、WSI の WASM ランタイムなどに変更できる。さらに、上位レイヤーでは LMP、コマンドラインツール、可観測性ツールなども実装されている。