eBPF の可観測性のデコード: 過去 2 年間、クラウドネイティブ コミュニティでは eBPF について多くの議論が行われてきました。 eBPF は KubeCon の であり、 や の人気は急速に高まっており、Google や Netflix などの企業は長年にわたり ており、新しいユースケースが常に出現しています。特に可観測性において、eBPF はゲームチェンジャーとなることが期待されています。 主力 eBPF デイ eBPF サミット eBPF を使用し それでは、eBPF について見てみましょう。このテクノロジーとは何ですか。可観測性にどのような影響を与えますか。既存の可観測性の実践とどのように比較されますか。また、将来はどうなるでしょうか? https://www.youtube.com/watch?v=KhPrMW5Rbbc&embedable=true eBPF とは実際何ですか? eBPF は、カーネル コードを変更せずに、Linux カーネルでサンドボックス プログラムを安全に実行できるようにするプログラミング フレームワークです。 これはもともと Linux 用に開発されました (そして現在でもこのテクノロジが最も成熟している部分です) が、Microsoft は 急速に進化させています。 Windows 用の eBPF 実装を eBPF プログラムは設計上、非常に効率的で安全です。オペレーティング システムの安定性やセキュリティを危険にさらさないようにカーネルによって検証されています。 では、なぜ eBPF が重要なのでしょうか? これを理解するには、ユーザー空間とカーネル空間を理解する必要があります。 ユーザー空間は、すべてのアプリケーションが実行される場所です。カーネル空間は、ユーザー空間と物理ハードウェアの間に位置します。ユーザー空間のアプリケーションはハードウェアに直接アクセスできません。代わりに、カーネルに対してシステム コールを実行し、カーネルがハードウェアにアクセスします。 すべてのメモリ アクセス、ファイルの読み取り/書き込み、およびネットワーク トラフィックはカーネルを経由します。カーネルは同時プロセスも管理します。 基本的に、すべてはカーネルを通過します (下の図を参照)。 また、eBPF は、カーネル機能を拡張するための安全な方法を提供します。 これまで、明らかな理由から、カーネル ソース コードやオペレーティング システム層の何かを変更することは非常に困難でした。 Linux カーネルには あり、変更がアイデアから広く利用可能になるまでには数年かかります。まず、Linux コミュニティがそれに同意する必要があります。次に、それを正式な Linux リリースの一部にする必要があります。そして、数か月後、Red Hat や Ubuntu などのディストリビューションに採用され、より幅広いユーザーに提供されるようになります。 3,000 万行のコードが カーネル モジュールをカーネルにロードして直接変更を加えることができますが、これは リスクが高く、複雑なカーネル レベルのプログラミングを必要とするため、ほぼ一般的に避けられています。 技術的には、 非常に eBPF が登場してこれを解決し、カーネル内でプログラムを接続して実行するための メカニズムを提供します。 安全で効率的な eBPF がセキュリティとパフォーマンスの両方をどのように確保するかを見てみましょう。 高い安全性 - eBPF プログラムはカーネルにロードされる前に によって検証され、ハード ループ、無効なメモリ アクセス、安全でない操作など、コードが完全に安全であることが保証されます。 厳格な検証 eBPF ベリファイア - eBPF プログラムは、他のカーネル コンポーネントから分離された、カーネル内のメモリ分離サンドボックスで実行されます。これにより、カーネル メモリ、データ構造、およびカーネル ソース コードへの不正アクセスが防止されます。 サンドボックス - eBPF プログラムは通常、C 言語の小さなサブセット、つまり制限された命令セットで作成する必要があります。これにより、eBPF プログラムが実行できる操作が制限され、セキュリティの脆弱性のリスクが軽減されます。 制限された操作 高性能・軽量 - eBPF プログラムは、CPU 上でネイティブ マシン命令として実行されます。これにより、実行が高速化され、パフォーマンスが向上します。 ネイティブ マシン コードとして実行 - 通常のアプリケーションは、ユーザー空間とカーネル空間の間で定期的にコンテキストを切り替えますが、これはリソースを大量に消費します。 eBPF プログラムはカーネル層で実行されるため、カーネルのデータ構造とリソースに直接アクセスできます。 コンテキストの切り替えなし - eBPF プログラムは通常、常時オンではなく、特定のカーネル イベントに応答してのみ実行されます。これによりオーバーヘッドが最小限に抑えられます。 イベント駆動 - eBPF プログラムは、実行直前にカーネルの JIT (ジャストインタイム) コンパイラーによってマシンコードにコンパイルされるため、コードは実行される特定のハードウェア向けに最適化されます。 ハードウェア向けに最適化 したがって、eBPF は、プログラミングのためにカーネルへの安全かつ効率的なフックを提供します。そして、すべてがカーネルを通過することを考えると、これまでは不可能だったいくつかの新しい可能性が開かれます。 なぜ これが大問題になるのでしょうか？ 今だけ eBPF 周辺のテクノロジーは長い時間をかけて進化し、その開発には約 30 年かかりました。 過去 7 ～ 8 年で、eBPF はいくつかの大企業で大規模に使用されており、現在では eBPF の使用が主流になりつつある時代に入りつつあります。 eBPF の進化については、Linux の共同作成者であり eBPF の共同管理者である 参照してください。 Alexei Starovoitov によるこのビデオを eBPF - 簡単な歴史 1993 - ローレンス バークレー国立研究所の では、パケット フィルタリングにカーネル エージェントの使用を検討しています。これが、BPF (「バークレー パケット フィルター」) という名前の由来です。 論文 1997 - BPF が Linux カーネル (バージョン 2.1.75) の一部として正式に導入されました。 1997 ～ 2014 - BPF 機能を改善、安定化、拡張するためにいくつかの機能が追加されました。 2014 - 「拡張バークレー パケット フィルター」(eBPF) と呼ばれる重要なアップデートが導入されました。このバージョンでは BPF テクノロジーに大きな変更が加えられ、より広く利用できるようになりました。そのため「拡張」という言葉が付けられています。 このリリースがなぜ大きかったかというと、これによりカーネル機能の拡張が なったからです。 容易に プログラマーは多かれ少なかれ通常のアプリケーションと同じようにコーディングでき、周囲の eBPF インフラストラクチャが低レベルの検証、セキュリティ、効率性を処理します。 eBPF を中心としたサポート エコシステムと足場全体がこれを可能にします (以下の図を参照)。 出典: https://ebpf.io/what-is-ebpf/ さらに良いことに、eBPF プログラムは再起動せずにカーネルにロードおよびアンロードできます。 これらすべてにより、突然、広範囲にわたる採用と応用が可能になりました。 実稼働システムでの広範な採用 eBPF の人気はここ 7 ～ 8 年で爆発的に高まり、いくつかの大企業が大規模な生産システムで eBPF を使用しています。 2016 年までに、Netflix はトレースに eBPF を広く使用していました。これを実装した は、eBPF の権威としてインフラストラクチャと運用の分野で広く知られるようになりました。 Brendan Gregg 2017 - Facebook は、eBPF ベースのロード バランサーである オープンソース化しました。 2017 年以降、 へのすべてのパケットは eBPF を通過しました。 Katran を Facebook.com 2020 - Google は eBPF を Kubernetes サービスの一部にしました。 eBPF は、GKE の 強化するようになりました。現在では、 や などの企業でも広く企業に導入されています。 ネットワーキング、セキュリティ、オブザーバビリティ層を Capital One Adobe 2021 - Facebook、Google、Netflix、Microsoft、Isovalent が集結し、eBPF テクノロジーの成長を管理するための を発表しました。 eBPF 財団 現在、数千の企業が eBPF を使用しており、さまざまなユースケースを模索する数百の eBPF プロジェクトが毎年登場しています。 eBPF は現在、Linux カーネル内の別個のサブシステムであり、それをサポートする幅広いコミュニティがあります。テクノロジー自体は、いくつかの新しい追加により大幅に拡張されました。 それでは、eBPF を使って何ができるのでしょうか? eBPF の最も一般的な使用例は 3 つの領域にあります。 ネットワーキング 安全 可観測性 セキュリティとネットワーキングは、 のようなプロジェクトによって促進され、より広範な採用と応用が見られています。比較すると、eBPF ベースの可観測性製品は進化の初期段階にあり、まだ始まったばかりです。 Cilum まず、セキュリティとネットワークの使用例を見てみましょう。 安全 セキュリティは、eBPF の非常に人気のある使用例です。 eBPF を使用すると、プログラムはカーネル レベルで起こっているすべてを監視し、イベントを高速で処理して予期しない動作をチェックし、他の方法よりもはるかに迅速にアラートを生成できます。 例えば - 大規模な侵入検知に eBPF を使用 Google は eBPF を使用してコンテナのセキュリティを実装します Shopify は いくつかの 現在、データ収集と監視に eBPF を使用しています。 サードパーティ製セキュリティ製品は ネットワーキング ネットワーキングも広く適用されているユースケースです。 eBPF 層にあることで、送信元 IP と宛先 IP とともに、すべてのホップを含む完全なネットワーク パスの可視性など、包括的なネットワーク可観測性が可能になります。 eBPF プログラムを使用すると、非常に低いオーバーヘッドで大量のネットワーク イベントを処理し、カーネル内でネットワーク パケットを直接操作できます。 これにより、負荷分散、DDoS 防止、トラフィック シェーピング、サービス品質 (QoS) などのさまざまなネットワークのユースケースが可能になります。 eBPFを使用してDDoS攻撃を検出および防止し、ネットワークパフォーマンスに影響を与えることなく を処理します。 Cloudflareは 毎秒1,000万パケット Meta の eBPF ベースの Facebook 全体の負荷分散を行います Katran は 可観測性 ここまでで、eBPF が可観測性においてどのように役立つかは簡単に理解できるはずです。 すべてがカーネルを通過します。また、eBPF は、カーネルからすべてを監視するための高性能かつ安全な方法を提供します。 可観測性についてさらに深く掘り下げて、このテクノロジーの意味を見てみましょう。 eBPF はオブザーバビリティに具体的にどのような影響を与えますか? これを探るために、eBPF の世界から可観測性の世界に入り、標準の可観測性ソリューションを構成するものを見てみましょう。 可観測性ソリューションには 4 つの主要コンポーネントがあります。 - アプリケーションおよびインフラストラクチャからテレメトリ データを取得する データ収集 - 収集されたデータのフィルタリング、インデックス付け、および計算の実行 データ処理 - データの短期および長期ストレージ データストレージ - ユーザーによるデータの消費方法の決定 ユーザー エクスペリエンス層 このうち、eBPF が (今日の時点で) 影響を与えるのは、実際にはデータ収集層、つまり eBPF を使用してカーネルから直接テレメトリ データを簡単に収集することだけです。 したがって、今日「eBPF 可観測性」と言うとき、私たちが意味するのは、他の計測方法を使用するのではなく、テレメトリ データを収集するための計測メカニズムとして eBPF を使用することです。可観測性ソリューションの他のコンポーネントは影響を受けません。 eBPF 可観測性の仕組み eBPF 可観測性の背後にある基盤となるメカニズムを完全に理解するには、フックの概念を理解する必要があります。 前に見たように、eBPF プログラムは主にイベント駆動型です。つまり、特定のイベントが発生するたびにトリガーされます。たとえば、関数呼び出しが行われるたびに、可観測性を目的として eBPF プログラムを呼び出してデータをキャプチャできます。 まず、これらのフックはカーネル空間またはユーザー空間に配置できます。したがって、eBPF を使用して、ユーザー空間アプリケーションとカーネルレベルのイベントの両方を監視できます。 第 2 に、これらのフックは事前に決定された静的なものにすることも、実行中のシステムに (再起動なしで) 動的に挿入することもできます。 4 つの異なる eBPF メカニズムにより、これらのそれぞれが可能になります (以下の図を参照)。 所定/手動 動的 カーネル カーネルトレースポイント kプローブ ユーザースペース USDT アップローブ ユーザー空間とカーネル空間への静的および動的 eBPF フック - カーネル開発者によって事前定義されたイベントにフックするために使用されます (TRACE_EVENT マクロを使用) カーネル トレースポイント - アプリケーション コードで開発者によって設定された事前定義されたトレースポイントにフックするために使用されます。 USDT (カーネル プローブ) - 実行時にカーネル コードの任意の部分に動的にフックするために使用されます。 Kprobes (ユーザー プローブ) - 実行時にユーザー空間アプリケーションの任意の部分に動的にフックするために使用されます。 Uprobes カーネル空間には、eBPF プログラムを簡単に接続できる事前定義されたフックがいくつかあります (システム コール、関数の出入り、ネットワーク イベント、カーネル トレースポイントなど)。同様に、ユーザー空間でも、多くの言語ランタイム、データベース システム、およびソフトウェア スタックが、eBPF プログラムがフックできる Linux BCC ツール用の事前定義されたフックを公開しています。 しかし、さらに興味深いのは kprobes と uprobes です。実稼働環境で何かが壊れていて、十分な情報がなく、実行時にインストルメンテーションを動的に追加したい場合はどうすればよいでしょうか?そこで、kprobe と uprobe によって強力な可観測性が可能になります。 たとえば、uprobe を使用すると、 アプリケーションのコードを変更することなく、アプリケーション内の特定の関数にフックできます。関数が実行されるたびに、eBPF プログラムをトリガーして必要なデータをキャプチャできます。これにより、 デバッグなどの興味深い可能性が可能になります。 実行時に ライブ eBPF による可観測性がどのように機能するかがわかったので、ユースケースを見てみましょう。 eBPF 可観測性の使用例 eBPF は、ほぼすべての一般的な既存の可観測性のユースケースに使用でき、さらに新しい可能性も開きます。 eBPF を使用すると、CPU 使用率、メモリ割り当て、ディスク I/O、ネットワーク トラフィックなどのシステム レベルのイベントを詳細に監視できます。たとえば、 。 システムおよびインフラストラクチャの監視: LinkedIn はすべてのインフラ監視に eBPF を使用しています Kubernetes 固有のメトリクス、リソース使用量、および個々のコンテナーとポッドの健全性を可視化します。 コンテナーと Kubernetes の監視: ユーザー空間アプリケーションのきめ細かい可観測性と、アプリケーションのスループット、エラー率、レイテンシー、およびトレースの可視性。 アプリケーション パフォーマンス モニタリング (APM): カスタム コードを作成しないと簡単に入手できない、アプリケーションまたはインフラに固有のカスタム メトリクスを可視化します。 カスタムの可観測性: eBPF は、 、 、 などの高度な可観測性のユース ケースに使用できます。 高度な可観測性: ライブ デバッグ 低オーバーヘッドのアプリケーション プロファイリング システム コール トレース 可観測性における eBPF の新しいアプリケーションが毎日登場しています。 これは、今日の可観測性の実現方法にとって何を意味するのでしょうか? eBPF は既存の形式の計測器に置き換わる可能性がありますか?既存のオプションと比較してみましょう。 eBPF と既存の計測方法の比較 現在、eBPF とは別に、可観測性を実現するためにアプリケーションとインフラストラクチャを計測する主な方法が 2 つあります。 テレメトリ データを収集するために、アプリケーション コードまたはインフラストラクチャ ノードに統合された独立したソフトウェア SDK/ライブラリ。 エージェントベースの計測: : サイドカーは、アプリケーションまたはサービスと一緒に実行される軽量の独立したプロセスです。これらは、マイクロサービスや Kubernetes などのコンテナベースのアーキテクチャで人気があります。 サイドカー プロキシベースのインストルメンテーション eBPF ベースのインストルメンテーションとエージェントおよびサイドカーの比較の詳細については、 。以下は概要ビューです - ここを参照してください eBPF エージェント サイドカー 1. データの可視性/粒度 （ただしギャップもある） 高い 高い 低い 2. 侵入性 (帯域外) 低 (インライン) 高 (インライン) 高 3. パフォーマンスのオーバーヘッド 低い 中くらい 高い 4. 安心・安全 高い 中くらい 中くらい 5. 実装の容易さ 高い 低い 中くらい 6. メンテナンスとアップデートの容易さ 高い 低い 中くらい 7. スケーラビリティ 高い 中くらい 低い ご覧のとおり、eBPF は、ほぼすべてのパラメーターにわたって既存の計測方法よりも優れたパフォーマンスを発揮します。いくつかの利点があります - (インフラストラクチャ、アプリケーション) すべてを一度にカバーできる - eBPF は、ワークロードが実行されるたびに実行されるコード エージェントのように、実行中のワークロードのインラインではありません。データ収集は帯域外でサンドボックス化されるため、実行中のシステムには影響がありません。 煩わしさが少ない - eBPF はネイティブ マシン コードとして実行され、コンテキストの切り替えはありません。 低パフォーマンスのオーバーヘッド - 検証などの組み込みのセキュリティ対策により。 より安全 - コードの変更や再起動を行わずにドロップインできます。 インストールが簡単 - ここでもコードの変更や再起動は必要ありません。 保守と更新が簡単 - 実装とメンテナンスが簡単で、パフォーマンスのオーバーヘッドが低いため よりスケーラブル 短所に関して言えば、今日の eBPF 可観測性との主なギャップは分散トレースにあります ( が、ユースケースはまだ初期段階です)。 実現可能です eBPF が既存の計測方法に比べて大きな利点を提供していることを考慮すると、eBPF がデフォルトの次世代計測プラットフォームとして登場すると合理的に期待できます。 可観測性への影響 これは可観測性業界にとって何を意味するのでしょうか?何が変わるのでしょうか？ 可観測性ソリューションを想像してください。 5 分以内にカーネルにドロップできること コードの変更や再起動は必要ありません インフラストラクチャ、アプリケーション、すべてを一度にカバー オーバーヘッドがほぼゼロ 安全性が高い それが eBPF によって可能になります。それが、このテクノロジーに関して非常に興奮が高まっている理由です。 次世代の可観測性ソリューションにはすべて、コード エージェントではなく eBPF が組み込まれることが予想されます。 Datadog や NewRelic などの従来のプレーヤーは、コードベースのエージェント ポートフォリオを強化するために、eBPF ベースのインスツルメンテーションの構築にすでに投資しています。一方、eBPF に基づいて構築された次世代ベンダーがいくつかあり、 と の両方を解決しています。 ニッチなユースケース 複雑な可観測性 従来のプレーヤーは言語ごと、インフラストラクチャ コンポーネントごとに個別のコード エージェント言語を数年かけて構築する必要がありましたが、新しいプレーヤーは eBPF を使用すれば数か月で同程度のカバー範囲を達成できます。これにより、データ処理、ユーザー エクスペリエンス、さらには など、バリュー チェーンの上位の革新にも注力できるようになります。さらに、データ処理レイヤーとユーザー エクスペリエンス レイヤーも、新しいユースケース、量、頻度をサポートするためにゼロから構築されています。 AI これらすべてにより、この分野で大量のイノベーションが推進され、今後数年間で可観測性がよりシームレスで安全かつ簡単に実装できるようになるはずです。 eBPF 可観測性を使用するのは誰ですか? まず、最新のクラウドネイティブ環境 (Kubernetes、マイクロサービス) を使用している場合、eBPF ベースのアプローチとエージェントベースのアプローチの違いが最も顕著になります (パフォーマンスのオーバーヘッド、セキュリティ、インストールの容易さなど)。 第 2 に、大規模な運用を行っている場合、eBPF ベースの軽量エージェントは現状よりも劇的な改善をもたらします。これが、LinkedIn、Netflix、Meta などの巨大な拠点を持つテクノロジー企業で eBPF の導入が最も進んでいる理由の 1 つであると考えられます。 第三に、技術が不足している場合。容量に余裕があり、インストールと保守にほとんど労力を必要としない可観測性ソリューションを探している場合は、eBPF ベースのソリューションを直接選択します。 まとめ 要約すると、eBPF は、大幅に優れた計測メカニズムを提供することにより、今後数年間で可観測性へのアプローチを根本的に再構築する可能性を秘めています。 この記事では主にデータ収集/計測における eBPF のアプリケーションについて検討しましたが、将来のアプリケーションでは、データ処理やデータ ストレージ層でさえも eBPF が使用される可能性があります。可能性は広く、まだ開拓されていません。 参考文献 https://www.oreilly.com/library/view/learning-ebpf/9781098135119/ch01.html https://ebpf.io/ https://ebpf.io/summit-2022.html https://github.com/microsoft/ebpf-for-windows https://events.linuxfoundation.org/wp-content/uploads/2022/10/elena-zannoni-tracing-tutorial-LF-2021.pdf こちらでも公開しております。
