Application practice of Coolbpf

1、eBPF CO-RE と開発モデルの比較

BPF 技術の発展に伴い、BPF プログラムの開発はますます簡便になってきました。利便性の向上と並行して、BPF はもう一つの側面——移植性も追求してきました。BPF の移植性とは、正常に記述されカーネルによって検証された BPF プログラムが、異なるカーネルバージョンで実行できることを意味します。

BPF の移行には 2 つの課題があります。

1. 異なるカーネルバージョンではメモリレイアウトが異なること。

2. カーネルの型とデータ構造は絶えず変化しており、構造体フィールドが削除または名称変更される可能性があること。

BPF CO-RE (Compile Once - Run Everywhere) は移植性を実現するための仕組みです。

CO-RE をサポートするため、以下のコンポーネントが提供されています。

① BTF：カーネルイメージの情報を記述し、カーネルと BPF プログラムの型情報およびコード情報を取得する

② Clang：BPF プログラムのリロケーション情報を .btf セクションに出力する

③ libbpf CO-RE：.btf セグメントに基づいて BPF プログラムの再配置を行う

再配置が必要な情報は 3 種類あります。

① 構造体関連のリロケーションは BTF に密接に関連しており、Clang が __builtin_preserve_access_index() を通じてメンバーのオフセットを記録します。

② map fd、グローバル変数 (data, bss, rodata)、外部変数のリロケーションは、主に ELF のリロケーション機構を利用して eBPF 命令の imm フィールドを更新します。

③ サブ関数のリロケーションは、eBPF プログラムが呼び出すサブ関数をメイン関数と統合し、カーネルに一括でロードできるようにします。

libbpf を使用した BPF CO-RE の開発手順は以下の通りです。

ステップ 1：bpftool を使用して、すべてのカーネル型情報を含む vmlinux.h ヘッダーファイルを生成する。

ステップ 2：Clang (バージョン 10 以降) を使用して、BPF プログラムのソースコードを .o オブジェクトファイルにコンパイルする。

ステップ 3：コンパイル済みの BPF オブジェクトファイルから、bpftool gen コマンドで BPF スケルトンヘッダーファイルを生成する。

ステップ 4：ユーザー空間のコードに生成した BPF スケルトンヘッダーファイルをインクルードする。

ステップ 5：ユーザー空間のコードをコンパイルし、BPF オブジェクトコードを埋め込む（個別ファイルとしてリリースしない）。

主な関数呼び出しは以下の通りです。

① __open()：BPF アプリケーションを作成して開き、skel->rodata 変数を設定する。

② __load()：BPF アプリケーション部分を初期化、ロード、検証する。

③ __attach()：自動アタッチ可能なすべての BPF プログラムをアタッチする。イベントやネットワーク操作メッセージが発生した際に、BPF プログラムがトリガーされて実行される。

④ __destroy()：アタッチ済みのすべての BPF プログラムをデタッチし、使用していたリソースをすべて解放する。

eBPF の開発方法は主に 3 つあり、それぞれに長所と短所があります。

1. カーネル付属のサンプルコード：カーネルの samples/bpf サンプルコードに基づき、CO-RE なし。サードパーティベースのオープンソースプロジェクトがなく、リソース消費は少ないです。ただし、プロジェクト全体を自分で再構築する必要があり、効率が低く、バージョン互換性も劣ります。

2. BPF CO-RE：libbpf を使用して記述された bpf_core_read コードに基づき、開発マシンでターゲットマシン用のバイナリプログラムを生成します。環境への Clang/LLVM の配備が不要で、リソース消費も少ないです。ただし、コンパイルプロジェクトの構築が必要で、一部のコードは比較的固定的で動的設定ができません。

3. BCC：最も広く使われているオープンソースプロジェクトに基づき、開発効率が高いです。ただし、実行のたびに Clang/LLVM のコンパイルが必要で、メモリや CPU などのリソース消費が大きく、ターゲット環境は対応するカーネルヘッダーファイルに依存します。

2、Coolbpf の機能とアーキテクチャ

Coolbpf はリモートコンパイル（クラウドコンパイル）を提供します。リモートコンパイルとは、プログラムの実行マシンとコンパイラが異なるマシン上にあることを意味し、リソース占有の問題を解決できます。ローカルコンパイルと基本ライブラリのラッピングにより、ユーザーが基本ライブラリを簡単に呼び出せるようになっています。低バージョンカーネルのサポートも提供されています。BTF の自動生成とリリースを提供し、ユーザーは手動での適合作業が不要です。さらに、自動化テストをサポートし、Python、Go、Rust などの高レベル言語でのアプリケーション開発に対応しています。

Coolbpf は BPF の CO-RE 機能をネイティブサポートしており、コンパイルとリソース消費の問題を解決しています。同時に、前述の複雑な libbpf の開発手順が完全に簡素化されており、ユーザーは独自の関数開発に集中でき、環境構築や冗長なコード開発に時間を割く必要がありません。

Coolbpf は標準化された BPF コンパイルサービスを提供します。まず、bpf.c をリモートコンパイルサーバーに送信すると、サーバーはカーネルバージョンに応じて、異なる言語向けの bpf.so または bpf.o を返し、上位アプリケーションにサービスを提供します。そのため、高レベル言語のコードでは、bpf.so を読み込むだけでプログラムを実行でき、Libbpf の open()、load()、attach() などの関数を個別に呼び出す必要がなく、高レベル言語プログラムの init() が自動的に処理します。これにより、ユーザーは迅速に構築・デプロイでき、データ出力後の処理に集中できます。

Coolbpf は eBPF 機能がない低バージョンカーネルでも動作をサポートし、提供する eBPF ドライバーを通じて低バージョンカーネル上で安全に実行されます。高バージョンの eBPF ベリファイアの検証機能をドライバーに実装しており、さまざまなセキュリティチェックを実行し、カーネルモジュールと同等のセキュリティを確保します。さらに、従来の libbpf ベースの呼び出しを ioctl システムコールに変換します。

以前サポートされていたヘルパー関数、マップの作成、プログラムのロードは、すべて低バージョンで kprobe または tracepoint 実装に変換されます。さらに、perf イベントと JIT もサポートされています。これにより、eBPF プログラムコードを変更することなく、同じユーザープログラムにドライバーをロードして低バージョンカーネルで安全に実行できます。

3、Coolbpf のネットワークアプリケーション実践

Raptor は Coolbpf ベースのシステム可観測性ツールで、AliOS や CentOS 3.10 などの低バージョンカーネルで動作します。サードパーティがデータ収集に利用できる SDK として使用できます。

ネットワークアプリケーション観測では、システムコール内のデータ送受信、リクエスト、レスポンス情報をモニタリングして、インタラクティブなデータ内容と 5 タプル情報を特定し、マップ経由でユーザー空間に送信することで、非侵入型の観測を実現し、トラフィック統計やリクエスト遅延などの観測結果を提示します。

具体的な問題を通じて、Coolbpf がパケット受信フェーズでネットワークジッター問題をどのように特定するかを見ていきましょう。ネットワークパケットの受信は 2 つのフェーズに分かれます。

フェーズ 1：OS がソフトインタラプトを通じてパケットをアプリケーションのパケット受信キューに送信し、プロセスに通知してプロトコルスタックのパケット受信を完了させる。

フェーズ 2：アプリケーションが通知を受け取った後、パケット受信キューからデータを取得する。

Coolbpf で BPF プログラムを作成し、2 つのトレースポイント tcp_probe と tcp_rcv_space_adjust をモニタリングするだけで、第 2 フェーズの遅延問題をクエリできます。

このケースでは、あるサービスアプリケーションのパケット受信が遅い問題が発生しました。カーネル側は既に TCP パケットを受信していましたが、アプリケーション側は約 1 秒後に受信していました。観測方法：eBPF エージェントをデプロイし、第 2 フェーズの「パケット受信遅延時間」が約 1 秒であることを確認しました。

原因の特定：遅延が発生するたびに、毎回約 42 秒の周期で発生していました。アプリケーション自体がビジネス関連の定期タスクに関与している可能性を疑い、最終的に、ビジネスのタスクが定期的に JVM のパラメータを収集しており、その際にビジネスプロセスを一時停止させていることが判明しました。

解決策：そのタスクを停止させたところ、ジッター問題は解消されました。