eBPFテクノロジーの威力の予備的調査

G バンク アプリケーションにフルスタック クラウドが使用されるケースが増えるにつれて、クラウド アプリケーションに対する要求はますます多様化しています。ネットワーク、セキュリティ、可観測性などに対する要求は、従来の「点と線」のシナリオから「面と分散」のシナリオへと徐々に移行しています。クラウド上の多くの分野では、eBPF などの新しいテクノロジーにより、さまざまなツールやサービスを実装するためのシンプルで便利かつ迅速な手段を提供できます。この記事では、eBPF の概念、主な使用シナリオ、使用方法を簡単に紹介し、フルスタック クラウドの実際の運用および保守シナリオで eBPF テクノロジを実践し、議論を促進します。

1. eBPFの基本概念

従来の BPF の動作方法: イベント駆動型フレームワークに基づいて、ユーザーは BPF 仮想マシン命令セット (RISC 縮小命令セット) を使用してフィルタリング ルールを定義します。その後、そのルールはカーネルに渡され、CPU ネイティブ命令に JIT コンパイルされて、イベントがトリガーされたときに実行されます。カーネル層でフィルタリングを実装することで、ユーザー層で定義されるフィルタリングコストが削減され、パケットフィルタリングのパフォーマンスが向上します。従来の tcpdump はこのフィルタリング方法を使用します。

eBPF は、ソフトウェア定義ネットワーク ソリューションの研究中に開発されたテクノロジーです。これは、BPF をより一般的な仮想マシンに拡張しますが、これもイベント駆動型フレームワークに基づいています。 eBPF パッチは 2014 年 3 月にメイン カーネル ブランチに統合され、JIT コンポーネントは 2014 年にリリースされた Linux 3.15 バージョンに統合され、BPF プログラムのアプリケーション レベル制御用の bpf システム コールは Linux 3.18 に統合され、その後の Linux 4.x バージョン シリーズでは、kprobes、uprobes、tracepoints、perf_events などのイベント タイプに対する eBPF サポートが追加されました。

従来の BPF 技術と比較して、eBPF はレジスタを 32 ビットから 64 ビットに拡張し、レジスタの数も 10 以上に拡張しました。マップ技術を拡張してカーネル状態とユーザー状態の共有ストレージ スペースを実現し、効率的なデータ読み取りを実現し、パケット フィルタリング イベント タイプからカーネル機能の動的インストルメンテーション、カーネル機能の静的インストルメンテーション、ユーザー機能インストルメンテーション、パフォーマンス監視、セキュリティなどの分野に拡張しました。現在の BPF 名は、デフォルトで eBPF を指します。

2. eBPFの内部動作メカニズムの図

図1. eBPFの動作図

主なプロセス:

• ユーザーは eBPF コードを記述し、LLVM、GCC などを使用してそれを eBPF バイトコードにコンパイルします。
• ユーザー モード プログラムまたはツールは、bpf システム コールを通じて eBPF バイトコードをカーネルにロードします。
• カーネル検証ツールは、バイトコードが準拠していて安全であるかどうかを検証し、カーネル例外が発生しないことを確認します。検証に合格すると、カーネル内の JIT コンパイラがバイトコードを CPU ネイティブ命令に変換し、対応するイベント インターフェイスにロードします。

カーネル内の対応するイベントがトリガーされると、ロードされた CPU ネイティブ命令が実行され、分析されたデータがユーザー モード プログラムで使用するためにマップ共有領域に配置されます。

3. eBPFの重要な応用シナリオ

1. eBPFはネットワークを定義する

eBPF は Linux カーネルから分離されていますが、プログラマビリティと効率的な処理により、フィルタリング、トラフィック制御、転送、実行パスの最適化、プロトコル解析、その他ほぼすべての操作を含む処理ロジックを Linux カーネル パケット処理コンテキストに動的に追加でき、ネイティブにコンパイルされたカーネル コードに近い効率で実行できます。例えば、Linux カーネルの XDP (高速データパス) フレームワークでは、eBPF プログラムをフレームワークに実装することで、3 層ルーティング転送、4 層ロード バランシング、分散ファイアウォール、アクセス制御 ACL などのカスタマイズされた機能を実現できます。 eBPF プログラムをネットワーク カード ドライバー層に書き込んでマウントすると、Linux カーネルをバイパスしてネットワーク トラフィックを直接処理し、専用のネットワーク プロセッサ (NPU) を使用してネットワーク トラフィックを処理し、CPU リソースを解放することができます。オープンソース コミュニティの代表的な例としては、Facebook のオープンソース Katran 4 層ロード バランサーが挙げられます。 Tencent は TKE の基盤エンジンとして Cilium を使用し、Alibaba Cloud は eBPF テクノロジーを使用して CNI ネットワーク カードを実装します。 G-Bank のフルスタック クラウドで使用されている DeepFlow トラフィック収集および分析テクノロジーも eBPF テクノロジーを使用しています。

2. eBPFはセキュリティを定義する

bpf テクノロジに基づいて実装された初期のカーネル ランタイム セキュリティ コンピューティング モデル Seccomp および LSM Linux セキュリティ モジュールに加えて、Flacon 異常動作検出ツールなど、ネットワーク セキュリティ ポリシーを効率的かつ柔軟に実装するための eBPF ベースのテクノロジが業界に多数存在します。コンテナ ネットワーク分野のオープン ソース プロジェクトである Cilium は、eBPF テクノロジーを多用して、クラウド ネイティブ シナリオなどで 3 層/4 層/7 層のネットワーク セキュリティ ポリシーを実装しています。Cilium のセキュリティ ポリシーは、アプリケーション コードやコンテナ構成を変更せずに公開および更新できます。 Linux 用のランタイム セキュリティおよびフォレンジック ツールである Tracee は、Linux eBPF テクノロジーを使用して、実行時にシステムとアプリケーションを追跡し、イベントを収集し、疑わしい動作パターンを分析および検出します。

3. eBPFの可観測性とリアルタイムトレース

Netflix は eBPF をベースに本番環境のトレースを実装し、AWS は eBPF を RPC 監視ツールとして使用し、国内のインターネット大手 ByteDance は eBPF 技術を使用してホストの可観測性と ACL アクセス制御を実装しています。

フルリンク ネットワーク パケットのトラブルシューティング用のオープン ソース ツール pwru (パッケージ名は ru) は、eBPF に基づいて開発されたネットワーク パケットのトラブルシューティング ツールであり、完全なきめ細かなネットワーク パケットのトラブルシューティング ソリューションを提供します (カーネル バージョンは 5.5 以降である必要があります)。

IV. eBPFの主な用途

1. C、Goなどのプログラミング言語を使用して、独自のeBPFプログラムを作成し、ロジック制御、監視、追跡などの機能を実装します。詳細については、コミュニティチュートリアルを参照してください。

2. 高レベルのカプセル化ツール BCC を使用して、eBPF の監視および追跡プログラムを作成します。 BPF プログラム開発の敷居を下げるために、コミュニティは BCC プロジェクトを立ち上げました。このプロジェクトは、Python や Lua などのスクリプト言語で記述できる eBPF プログラムの作成、読み込み、実行のための使いやすいフレームワークを提供します。さらに、カーネル、CPU、メモリ、スケジューリング、ネットワーク セグメントなどのサブシステムの監視と追跡も多数用意されています。https://github.com/iovisor/bcc を参照してください。

3. 高レベルのカプセル化ツール bpftrace を使用して、eBPF の観察およびトレース プログラムを作成します。 eBPF パフォーマンス監視ツールはコマンド ラインを通じて実装できるため、eBPF の使用が簡素化されます。 Linux カーネルのトレースとデバッグ、およびカーネルの動作メカニズムの理解に非常に役立ちます。欠点は、カーネル関数やカスタム関数を呼び出すことができないことです (このようなシナリオは、BCC または C、GO 言語で開発する必要があります)。参考までに、https://github.com/iovisor/bpftrace を参照してください。

5. G-Bank のフルスタック クラウド CaaS 環境での eBPF テクノロジーの初体験 ケース 1: フルスタック クラウド ハイパーホストでの ping レイテンシが高い

フルスタッククラウドの一部のハイパー物理マシンでは、ping 127.0.0.1のレイテンシが高いことが判明しました（図2）。

図2 高いping遅延

perf パフォーマンス分析ツールを使用して、通常の ping プロセスと ping 遅延のあるプロセスに対してトレース サンプリングを実行し、フレーム グラフを作成して、時間のかかる部分を分析します。

通常のping（図3）：

図3 通常のpingフレームグラフ

異常な ping (高遅延、図 4):

図4 異常なpingフレームグラフ

フレーム グラフからわかるように、高レイテンシの ping プロセスでは、通常の ping よりも try_to_wakeup_up() 呼び出し中に多くの時間がかかります。

ping 遅延中の try_to_wakeup_up の特定の状況をさらに理解するために、bpftrace kprobe タイプのプログラムを作成して、それを try_to_wakeup_up カーネル関数にマウントします。

 #include <linux/sched.h> kprobe:try_to_wake_up / pid == $1 / { $task = ((struct task_struct *) arg0); $pid = $task->pid; printf("from %s -> wakeup comm %s pid %d\n", comm, $task->comm, $pid); }

この eBPF プログラムを bpftrace で実行して、try_to_wakeup_up である ping プロセスの詳細なプロセスを監視します (図 5)。

図5 eBPFトレースデータ

図から、ping プロセス中に try_to_wakeup_up が isc-socket プロセスを頻繁に起動していることがわかります。分析の結果、これは dhcpd 関連のプロセスであり、分散仮想ルーティング dvr マスターと IaaS レイヤーのクライアント間の処理ロジックであることがわかりました。 dhcpd 関連のプロセスを別のマシンに移行した後、このマシン上の ping 127.0.0.1 の遅延は正常に戻りました。

上記の事例から、eBPF には強力な可観測性とリアルタイム トレース機能があることがわかります。シナリオに応じて適切なトレース機能を簡単にカスタマイズできるため、カーネルやプロセスの実行ロジックを観察および特定するのに非常に便利です。

ケース2: パケットの送受信のメインプロセスの時間消費を観察する

フルスタックのクラウド CaaS 環境では、各ビジネスはポッドの形式で独自の名前空間で実行されます。異なるポッド間の通信が時々不安定になったり遅くなったりする場合、ネットワーク カード、プロトコル スタック、アプリケーション層など、どのリンクに問題があるかをどのように判断すればよいでしょうか。従来の tcpdump パケット キャプチャ ツール (下部にある従来の bpf ライブラリに基づく) は、ソフト割り込みがネットワーク カード キュー (リング バッファー) からデータを読み取り、それをプロトコル スタックに送信するときにパケットをキャプチャします。 tcpdump からは、ネットワーク カード インターフェイスでシーケンス データ パケットが送受信されるのにかかる時間のみを確認できます。通常の状況では、カーネル処理の遅延やユーザー モードの遅延など、遅延のより深い理由を直接確認することはできません。

パケットを送受信するための veth ドライバーの主要なカーネル関数と、プロトコル スタック処理と veth ドライバー間の接続ポイントがわかっている場合は、これらの主要な関数の入口または出口にマウントする eBPF プログラムを作成できます。 kprobe または tracepoint を通じて、プロトコル スタックの各レイヤーの主要な機能にフック ポイントを追加できます。データ パケットが関数を通過すると、シーケンス、ネットワーク名前空間、タイムスタンプなどの重要な情報が出力され、問題の範囲をすばやく特定したり絞り込んだりするのに役立ちます。

この記事では、ノード上の仮想ネットワーク カードの遅延をシミュレートします (図 6)。このとき、ノードとポッドノード（遅延した仮想ネットワーク カードとペアになっている）は、ネットワーク カードが遅いのか、プロトコル スタックの処理が遅いのかをどのように判断できるでしょうか。

図6 テスト環境

まず、このシナリオで eBPF プログラムの適切なカーネル マウント ポイントを分析し、bpftrace ツールに基づいて eBPF プログラムを記述し、観察と追跡エクスペリエンスを実行する必要があります。

1. Veth は主要なカーネル関数を送信します。

__dev_queue_xmit (データをドライバー層に送信する)

マウント ポイントで、TCP の 4 タプル情報を取得し、TCP シーケンスを取得し、グローバル変数を使用して受信時間 (ナノ秒) を保存します @rcvpkg[$seq] = nsecs;

2. Veth は主要なカーネル関数を受け取ります。

__netif_receive_skb (プロトコルスタックへのメッセージを受信する)

tcp_rcv_state_process (TCP ステートマシン処理関数)

tcp_rcv_established (tcp 確立プロセス処理)

上記の 3 つの例のマウント ポイントを選択し、TCP 4 タプル情報を取得し、TCP シーケンスと現在の時刻を取得し、__dev_queue_xmit レコードの開始時刻を減算すると、送信から受信までの消費時間とプロトコル スタックの主な処理機能を取得できます。一定時間を超えるとアラームを印刷することができます。

 if( ($seq) == @sequence ){ $delta = ((nsecs - @rcvpkg[$seq]) / 1000000) % 1000; if( $delta >= $1 ){ time("\n%H:%M:%S "); printf("%-19u %-5s %d,%s,%s,%-10d ", $nsid, $netif, pid, comm, func, cpu); printf("flags:%s, seq:%-u, ack:%u, win:%-25u ", $pkgflag, $seq, $ack, $win); printf("%s:%-15d %s:%-15d %d ms\n", $srcip, $sport, $dstip, $dport, (nsecs / 1000000) % 1000); printf("Slow pkg: duratinotallow=%u ms, seq=%-u\n", $delta, $seq); } }

ネットワーク遅延のシミュレーション:

tc qdisc 追加 dev vnice9657d91c32 ルート netem 遅延 10 ミリ秒

tc qdisc 追加 dev vnicb8898168feb ルート netem 遅延 20 ミリ秒

ノード上で eBPF プログラムを実行します。

bpftrace ネットポッド.bt 5 > tt

ノード上でテスト コマンドを実行します。

カール 30.254.10.7:8099;

nsenter -n -t 20720 telnet 30.254.10.6 22627

eBPFキャプチャデータは次のとおりです。 xmit 送信時に tc で設定した遅延が発生し、受信側と tcp プロトコル スタックの処理時間は正常であることがわかります (図 7-1、図 7-2)。

図7-1 eBPFトレースネットワーク遅延データ

図7-2 eBPFトレースネットワーク遅延データ

6. eBPFの進化傾向の展望

eBPF テクノロジーは、探索や変革のために行きたい場所に移動できるポータルのようなもので、クラウド時代に活用できます。 Linux カーネルは、複雑さ、パフォーマンス、スケーラビリティ、および下位互換性に対する要求がますます高まっています。カーネルの段階的な開発を維持する必要があり、より多くの新しい機能や特徴をタイムリーにカーネルにマージすることはできません。 eBPF のカーネル プログラマビリティにより、セキュリティが確保されるだけでなく、カーネル コードを変更せずに新しい機能や特徴を迅速に適用できるようになります。カーネルの開発に新しいティックトック反復ソリューションを提供できます。今後のカーネル開発では、eBPF 技術をベースにしたソフトウェア定義カーネルが実現される可能性が高いと考えられます。フルスタック クラウド プラットフォームの場合、eBPF テクノロジの開発を追跡し、eBPF のアプリケーション シナリオを研究して、クラウド アプリケーションをより適切にサポートできます。