Didi テクノロジーを「スター ⭐️」に設定します
記事の更新情報をできるだけ早く受け取る
ガイド
eBPF は Linux カーネルの革新的なテクノロジーであり、安全かつ効率的にカーネル機能を拡張でき、特に業界で注目を集めているクラウドネイティブの可観測性の分野で幅広い用途に使用できます。Didi Cloud のネイティブ環境では、eBPF テクノロジーがビジネス実践と内部ソースの共同構築を実行し、HuaTuo eBPF プラットフォームはすぐに導入され、初期のメリットを達成しました。現在、サービス アクセス関係トポロジなどのクラウド ネイティブの主要コンポーネントをサポートしています。 、コンテナ セキュリティ、ホスト セキュリティ、ネットワーク診断、根本原因特定およびその他のサービス、HuaTuo は Didi オープンソース委員会のブティック インキュベーション プロジェクトでもあります。この記事が業界の開発者に、eBPF テクノロジをクラウド ネイティブ シナリオに迅速に適用し、クラウド ネイティブ システムの深い可観測性を共同で向上させる方法を提供することを期待しています。
この記事は次のように分かれています。
1. BPF テクノロジーの過去
2. BPF テクノロジーの現状
3. Didi の生産環境におけるビジネス上の問題点
トラフィック再生テスト
サービスアクセストポロジ
コンテナのセキュリティ
カーネルの根本原因の場所
4. Didi HuaTuo eBPF プラットフォームの実践
プラットフォーム構築
プラットフォーム構成
プラットフォームの使用状況
5. Didi ビジネスランディングの実践
カーネルの根本原因の場所の背景
カーネルの根本原因の場所のアイデア
カーネル根本原因位置特定プラットフォーム
6. 今後の展望
1 ►
BPF テクノロジーの過去
バークレー パケット フィルタ BPF バークレー パケット フィルタは、もともと 1993 年に Steven McCanne と Van Jacobson の論文「BSD パケット フィルタ: ユーザー レベルのパケット キャプチャのための新しいアーキテクチャ」で考案されました。その目標は、ネットワーク パケットを効率的にフィルタリングする新しい方法を提供することです。初期状態では、BPF は Linux カーネル ネットワーク ソケットにのみ接続されており、ソケットが BPF バイトコードにバインドされている場合、メッセージを受信するたびにそのバイトが実行されます。カーネルは、BPF バイトコードの戻り値に応じて、ネットワーク パケットの通過を許可するかどうかを決定します。
命令セットの観点から見ると、BPF の初期アーキテクチャは比較的単純で、32 ビット幅のアキュムレータ A、32 ビット幅のレジスタ X、および 16x32 ビット配列メモリ空間のみを備えています。ただし、BPF はロード、ストア、ジャンプ、演算の 4 種類の命令を実装します。BPF には当初、ジャストインタイム コンパイラ JIT がありませんでした。パフォーマンスが他のメッセージ フィルターを完全に打ち破ったにもかかわらず、これらの命令はすべて、小さなカーネルを備えた仮想マシンで完全に実行されました。
BPF はさらに使いやすく、tcpdump、libpcap、または bpf_asm を通じて BPF バイトコードを生成し、setsockopt SO_ATTACH_FILTER を通じてカーネルにロードできます。以下のような ICMP パケットフィルタリングを実装するには、L2/L3 パケットヘッダのドリフト量に基づいてプロトコル番号が条件を満たすかどうかを判断するだけで済みます。
BPF は最初に sk_filter で使用され、その後 netfilter、seccomp、チーム ドライバーなどのネットワーク サブシステムで使用されましたが、アプリケーションの方向性は依然としてネットワーク パケット処理にあります。
2 ►
BPF技術の現在
BPF の核となる考え方は、カーネルのプログラマビリティ、つまりソース コードの変更やカーネルの再コンパイルを行わずにカーネル機能の効率的な拡張を実現することです。2013 年、Alexei Starovoitov は BPF を変更して、新しい機能を追加し、パフォーマンスを向上させました。BPF のさらなる開発により、カーネルに大きな変更がもたらされ、カーネルがより強力でプログラム可能な動的変更機能を備えられるようになりました。この機能は、カスタマイズが必要なさまざまなアプリケーション シナリオで非常に価値があり、機能の拡張やパフォーマンスの最適化に使用できます。新しいバージョンは eBPF (「拡張 BPF」) と名付けられ、以前の BPF は cBPF (「クラシック」BPF) になりました。次の章では、BPF は特にこのテクノロジーを指します。
まず命令セットの観点から見ると、eBPF は 10 個の 64 ビット汎用レジスタ R0 ～ R9 をサポートする簡素化された命令セットです。このうち、R0 レジスタはカーネル関数の戻り値に使用され、R1 ～ R5 レジスタはカーネル関数のパラメータ転送に使用され、x86_64 や aarch64 と同様です。eBPF は、64 ビット幅の基本エンコードと 128 ビット幅の命令エンコードの 2 つの命令セット エンコード形式をサポートします (命令エンコードは、基本エンコードの後に 64 ビットの即値を追加することによって実装されます)。また、eBPFでは4種類の命令セットも充実しています。
Just In Time、JIT コンパイラー、BPF 命令は、カーネルの JIT コンパイラーによって物理マシンのネイティブ命令に動的にコンパイルされ、動作効率の「ゼロ」損失を実現します。この機能は cBPF 期間中に Eric Dumazet によって実装され、x86-64 アーキテクチャのみをサポートします。eBPF は、独自の命令の特性に従ってコンパイラを再度拡張します。eBPF 命令は、物理マシンの CPU ネイティブ命令に JIT 変換できるだけでなく、一部のスマート ネットワーク カードなどの一部のデバイスの特定の命令に変換することもできます。このようにして、スマート ネットワーク カードなどのデバイスを eBPF を通じてプログラムできます。
eBPF は、命令レベルの強化と拡張に加えて、キーと値のペアに基づくデータ ストレージ メカニズムも追加します。これは、カーネル ユーザー モードでのデータ ストレージと交換の実装に使用できます。eBPF には、より豊富な BPF ヘルパー機能が追加されました。これにより、BPF プログラムがカーネル機能にアクセスし、BPF プログラムとカーネル間のセキュリティ分離を維持しながら BPF 機能を拡張できるようになります。
BPF 機能の強化により、このテクノロジーはカーネル ネットワーク サブシステムに限定されなくなり、動的追跡、イベント検出、パフォーマンス分析と最適化、IO サブシステム、プロセス スケジューリング、ファイル サブシステムなどにも徐々に適用されています。アプリケーション シナリオは、特定のポイントから可観測性、トレース、セキュリティ、パフォーマンス分析、根本原因分析などの領域にも拡張されます。同時に、Bcc、Cilium、bpftrace、Falco、Katran、Pixie などの優れたオープンソース プロジェクトが多数登場しました。
3 ►
Didi の生産環境におけるビジネス上の課題
データセンターには多くの基本サービスがあり、安定性、生産効率、拡張性、セキュリティなどにおいて重要な役割を果たしており、実際の導入時にはさまざまな課題に直面します。
トラフィック再生テスト
クラウドネイティブの規模はますます大きくなり、業務内容やビジネストラフィック、規模も急速に拡大しており、ソフトウェアテストにおいてもテスト環境の構築やテストケースの作成・保守など大きな課題に直面しています。トラフィック再生テストは、まったく新しいテスト方法です。回帰テストはオフライン テスト環境での再生を通じて実現され、トラフィックの再生により複雑なオンライン ビジネス アクセス シナリオを完全に再現できるため、プロジェクトの反復効率が大幅に向上し、ビジネス回帰テストの進捗が加速され、ビジネスの研究開発品質が確実に向上します。プロジェクトが直面する課題:
多くのビジネス プログラミング言語と基本ライブラリのさまざまなバージョンがあります。
ビジネスネットワークモデルが統一されていない（phpのシングルプロセス処理、golangのコルーチン処理、その他のプログラミング言語のマルチスレッド/プロセス）。
特定のビジネス向けにカスタマイズされているため、カバレッジを向上させるのが難しく、コストが高くなります。
ビジネス感があり、安定性を担保するのは難しい。
サービスアクセストポロジ
マイクロサービス アーキテクチャの台頭により、サービスの数は日々増加しており、サービス間の依存関係はますます複雑になっています。サービス リンクの可観測性は、ビジネスの安定性を保証する上で非常に重要です。サービスインターフェース間のアクセス関係や、パフォーマンス、遅延、タイムアウトなどのビジネス指標を明確に表示できます。オンラインで問題が発生した場合、サービス トポロジ関係に従って問題のノードを迅速に特定できます。プロジェクトが直面する課題:
業種が多数あるため、手作業による仕分けはコストが高く、間違いも発生しやすくなります。
ログ内のメトリクスとサービス呼び出しの関係に依存して直列に接続して特定の SDK をプロモートすることは非常に困難であり、運用環境ではリンクが切断されやすくなります。
コンテナのセキュリティ
クラウド ネイティブの一般的な傾向に伴い、クラウド ネイティブの採用を選択する企業がますます増えており、コンテナは、クラウド ネイティブ時代のアプリケーション配信、コンピューティング リソースおよびサポート機能の配信単位の標準となっています。コンテナの使用はますます一般的になり、コンテナのセキュリティ問題はますます顕著になってきています。Didi はコンテナ セキュリティのための完全なソリューション セットを備えており、核となる問題点の一部は eBPF テクノロジーによって解決されます。
カーネルの根本原因の場所
Didi Cloud のネイティブ プラットフォームのコンテナ導入密度と過剰販売率は高く、共有カーネル コンテナ仮想化シナリオではリソースの不当な使用によって引き起こされる問題が発生する傾向があります。従来のカーネル インジケーターは、基本的、全体的、および粗粒度の統計検出に偏っていますが、同時に、従来の測位ツールはより多くのリソースを消費し、パフォーマンスに大きな影響を与えます。したがって、カーネルの根本原因を徹底的に特定するには、カーネル サブシステムを詳細に観察し、イベント中およびイベント後に発生するバースト、タイムアウト、グリッチなどの困難な問題を解決するための正規化された観察を実現する必要があります。
4 ►
Didi HuaTuo eBPF プラットフォームの実践
eBPF テクノロジーは、前述の言語依存の問題点を十分に解決できると同時に、eBPF と動的追跡テクノロジーの組み合わせにより、深層観察カーネルの実現をサポートします。ただし、実際の着陸プロセスでは次の質問に答える必要があります。
多くのニーズがある場合、それらのニーズを迅速に満たし、研究開発の効率を向上させて迅速に実装するにはどうすればよいでしょうか?
現在、業界での導入事例はあるものの規模は比較的小さいため、ポイントからエリアへの導入をどのように実現し、ホストマシンの安定性をどのように確保するのか。
ステーキングポイントのパフォーマンス損失を均一に観察して保証する方法、また問題が発生した場合に迅速にロールバック、ダウングレード、損失ストップを行う方法とは?
プラットフォーム構築
上記の考慮事項に基づいて、私たちは eBPF プラットフォームを開発しました。企業は、プラットフォームが提供する一般的な機能を直接使用でき、独自のロジックの実装のみに集中する必要があります。プラットフォーム構築プロセスは、研究開発効率の向上、ビジネスの視点の提供、安定性とパフォーマンスの確保に重点を置いています。
研究開発効率の向上
初期のユーザーは、BPF バイトコードを解析する方法、それをカーネルにロードする方法、KV マップを作成する方法、および特定のセクション コードを特定の実行中のノードにアタッチする方法に注意する必要があります。最後に、ユーザーはカーネルからデータを取得する方法にも注意を払う必要があります。プラットフォームの重要な機能は、基礎となる技術的な詳細を保護することです。上記の同様の機能では、bpfload インターフェイスと bpfmap インターフェイスを呼び出すだけで済みます。
ビジネスの視点を提供する
ビジネスとプラットフォーム、ビジネスとビジネスのリリースルールは異なります。最後に、BPF Obj バイトコードを使用してビジネスのロジックをプラットフォームから分離し、ビジネスは要件に応じてプラットフォーム インターフェイスを呼び出すことができます。同時に、プラットフォームは、既存の BPF バイトコードと互換性があり、プラットフォーム上で直接実行できるように、標準化を考慮し、他のオープン ソース コンポーネントによって定義された SEC をサポートする必要があります。
安定性を保証
新しいテクノロジーが実装されると、ホストの安定性に焦点を当てる必要があります。安定性の保証は主にコア層、フレームワーク側、ビジネス認識の側面から確立されます。
保証された性能
すべての BPF コードはカーネル モードで実行されるため、時間がかかりすぎるとシステムに影響を及ぼします。イベント駆動型、共有メモリ、リングバッファの生成と消費はすべてこのプラットフォームに適用されます。
プラットフォーム構成
BPF バイトコード管理
1 つ目は、SEC、マップ、変数、構造の定義を含む ELF 機能を分析することです。SEC を通じて、BPF Prog のタイプと自動ロードできるフックの取り付けポイントを明確にすることができます。Map の定義を通じて、その型、サイズ、Key 型、Value 型、その他の情報が解析されます。
高性能データ処理
プラットフォームは多くのビジネス タイプをサポートしているため、パフォーマンスの保証をさまざまな側面から考慮する必要があります。まず、カーネル側のプローブ フック ポイントを動的に評価して、ヒューズ メカニズムを提供します。プラットフォーム側で高性能なデータ通信を実現し、ringbuf生成・消費方式によりレイテンシを低減します。
安定管理
プラットフォーム設計の本来の目的は、オンラインの問題を解決し、ビジネスの安定性を確保することであるため、プラットフォーム自体がイベントの融合と自己修復機能を実現しています。ホスト BPF で異常が検出されると、プラットフォームは自動的に bpf をアンロードし、現在の BPF によって引き起こされる過剰な負荷を回避します。イベントのヒューズと自己修復を実現することに加えて、CPU やメモリなど、プラットフォームによって使用されるシステム リソースも制限されます。
コンテナ情報管理
この機能の実現は主に次の要素に基づいています。 1. コンテナ内で実行されるすべてのサービス、パラメータ送信、およびサービス識別には、この情報が必要です。2. カーネル cgroup 情報をコンテナ情報と集約する必要があります。
プラットフォームの使用状況
API インターフェイスに加えて、プラットフォームはコマンド ライン モードも提供するため、異常な実行中の BPF OBJ またはデバッグ OBJ をプラットフォーム上で実行できます。
コード例は次のとおりです。
コンパイル：
clang -O2 -g -target bpf -c $(NAME).bpf.c -o $(NAME).o実行: プラットフォームは、BPF によって定義された構造を自動的に解析し、標準出力に出力します。
5 ►
Didi ビジネスランディング実践
Didi の多くの企業は、サービス テスト回帰、コンテナ セキュリティ、ホスト セキュリティ、サービス アクセス トポロジ、ネットワーク診断、カーネルの根本原因の特定など、HuaTuo eBPF プラットフォームに接続しています。以下では、主にカーネルの根本原因の場所を例として説明します。
カーネルの根本原因の場所の背景
現在、多くのインターネット企業ではコスト削減と効率化がテーマとなっていますが、滴滴ではコンテナの導入密度が高く、売れすぎ率が高く、リソースの無駄な使用による他のビジネスへの影響を避けることが困難です。障害が発生した場合、最初の対策は損失を止めることですが、コンテナが流れて問題箇所が失われてしまうため、オフラインで問題を再現することは難しく、人的コストや機械コストが非常に高くなります。さらに、回線上で時折発生する不具合、時間のかかる問題、タイムアウトの問題には従うべきルールがありません。要約すると、通常の観察が非常に強力な要件となります。
カーネルの根本原因の場所のアイデア
可観測性の 3 つの柱 (以下の図を参照) に従って、まずカーネルの深さの観察指標を確立します。これは、よりきめ細かく、カーネルの各サブシステムの健全性状態を反映できます。これらの指標を設定する際には、合理性や業績への影響などをさまざまな角度から評価し、最終的に正常な観測を実現します。第 2 に、イベント駆動型実装はカーネル例外ログ コンテキストを取得します。また、カーネル サブシステムの異常パス、低速パス、その他のエラー状態におけるエラーの収集が懸念されます。例外イベントは、カーネル問題の根本原因を解決する鍵となります。基礎的な基本機能を確立すると、この情報を要約、分析し、最終的に分析レポートを提供することができます。
カーネル根本原因位置特定プラットフォーム
カーネルの根本原因特定プラットフォームを 4 つの部分に分割します。
カーネル データの収集。この部分は主に、カーネル コア インジケーターのコレクションとカーネル例外コンテキストのコレクションを実装します。
カーネルデータの集約。この部分では主にカーネルの観測データやコンテナ/Pod情報のサマリーを実装し、ストレージ装置にアップロードします。
データ分析層。この部分は主に収集されたデータを処理し、分析サービスを提供します。
データ表示レイヤー。主に分析・診断センター、観測センター、ログセンター、分析レポート、警報センターなどを行っています。
6 ►
将来計画の見通し
eBPF コア テクノロジーは、Didi Cloud のネイティブ シナリオの大規模なマルチ シナリオに実装されており、将来的には、HuaTuo eBPF プラットフォームはより多くのビジネス ラインにサービスを提供する予定です。現在、私たちはプロジェクトを育成し、業界の開発者と構築して共有するための適切な基盤を探しています。近年、eBPF テクノロジーは大きな進歩を遂げていますが、パフォーマンスの最適化、CPU スケジューリングなど、オフラインの混合展開シナリオでの詳細な調査など、一部のシナリオにおける機能は十分に完璧ではありません。将来のあなたについてのディスカッション。