eBPF の可観測性のデコード:

過去 2 年間、クラウドネイティブ コミュニティでは eBPF について多くの議論が行われてきました。 eBPF は KubeCon の主力であり、 eBPF デイやeBPF サミットの人気は急速に高まっており、Google や Netflix などの企業は長年にわたりeBPF を使用しており、新しいユースケースが常に出現しています。特に可観測性において、eBPF はゲームチェンジャーとなることが期待されています。

それでは、eBPF について見てみましょう。このテクノロジーとは何ですか。可観測性にどのような影響を与えますか。既存の可観測性の実践とどのように比較されますか。また、将来はどうなるでしょうか?

eBPF とは実際何ですか?

eBPF は、カーネル コードを変更せずに、Linux カーネルでサンドボックス プログラムを安全に実行できるようにするプログラミング フレームワークです。

これはもともと Linux 用に開発されました (そして現在でもこのテクノロジが最も成熟している部分です) が、Microsoft はWindows 用の eBPF 実装を急速に進化させています。

eBPF プログラムは設計上、非常に効率的で安全です。オペレーティング システムの安定性やセキュリティを危険にさらさないようにカーネルによって検証されています。

では、なぜ eBPF が重要なのでしょうか?

これを理解するには、ユーザー空間とカーネル空間を理解する必要があります。

ユーザー空間は、すべてのアプリケーションが実行される場所です。カーネル空間は、ユーザー空間と物理ハードウェアの間に位置します。ユーザー空間のアプリケーションはハードウェアに直接アクセスできません。代わりに、カーネルに対してシステム コールを実行し、カーネルがハードウェアにアクセスします。

すべてのメモリ アクセス、ファイルの読み取り/書き込み、およびネットワーク トラフィックはカーネルを経由します。カーネルは同時プロセスも管理します。

基本的に、すべてはカーネルを通過します (下の図を参照)。

また、eBPF は、カーネル機能を拡張するための安全な方法を提供します。

これまで、明らかな理由から、カーネル ソース コードやオペレーティング システム層の何かを変更することは非常に困難でした。

Linux カーネルには3,000 万行のコードがあり、変更がアイデアから広く利用可能になるまでには数年かかります。まず、Linux コミュニティがそれに同意する必要があります。次に、それを正式な Linux リリースの一部にする必要があります。そして、数か月後、Red Hat や Ubuntu などのディストリビューションに採用され、より幅広いユーザーに提供されるようになります。

技術的には、カーネル モジュールをカーネルにロードして直接変更を加えることができますが、これは非常にリスクが高く、複雑なカーネル レベルのプログラミングを必要とするため、ほぼ一般的に避けられています。

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 を広く使用していました。これを実装したBrendan Greggは、eBPF の権威としてインフラストラクチャと運用の分野で広く知られるようになりました。

• 2017 - Facebook は、eBPF ベースのロード バランサーであるKatran をオープンソース化しました。 2017 年以降、 Facebook.comへのすべてのパケットは eBPF を通過しました。

• 2020 - Google は eBPF を Kubernetes サービスの一部にしました。 eBPF は、GKE のネットワーキング、セキュリティ、オブザーバビリティ層を強化するようになりました。現在では、 Capital OneやAdobeなどの企業でも広く企業に導入されています。

• 2021 - Facebook、Google、Netflix、Microsoft、Isovalent が集結し、eBPF テクノロジーの成長を管理するためのeBPF 財団を発表しました。

  
  

現在、数千の企業が eBPF を使用しており、さまざまなユースケースを模索する数百の eBPF プロジェクトが毎年登場しています。

eBPF は現在、Linux カーネル内の別個のサブシステムであり、それをサポートする幅広いコミュニティがあります。テクノロジー自体は、いくつかの新しい追加により大幅に拡張されました。

それでは、eBPF を使って何ができるのでしょうか?

eBPF の最も一般的な使用例は 3 つの領域にあります。

1. ネットワーキング
2. 安全
3. 可観測性

セキュリティとネットワーキングは、 Cilumのようなプロジェクトによって促進され、より広範な採用と応用が見られています。比較すると、eBPF ベースの可観測性製品は進化の初期段階にあり、まだ始まったばかりです。

まず、セキュリティとネットワークの使用例を見てみましょう。

安全

セキュリティは、eBPF の非常に人気のある使用例です。 eBPF を使用すると、プログラムはカーネル レベルで起こっているすべてを監視し、イベントを高速で処理して予期しない動作をチェックし、他の方法よりもはるかに迅速にアラートを生成できます。

例えば -

• Google は大規模な侵入検知に eBPF を使用

• Shopify はeBPF を使用してコンテナのセキュリティを実装します

  
  

いくつかのサードパーティ製セキュリティ製品は現在、データ収集と監視に eBPF を使用しています。

ネットワーキング

ネットワーキングも広く適用されているユースケースです。 eBPF 層にあることで、送信元 IP と宛先 IP とともに、すべてのホップを含む完全なネットワーク パスの可視性など、包括的なネットワーク可観測性が可能になります。 eBPF プログラムを使用すると、非常に低いオーバーヘッドで大量のネットワーク イベントを処理し、カーネル内でネットワーク パケットを直接操作できます。

これにより、負荷分散、DDoS 防止、トラフィック シェーピング、サービス品質 (QoS) などのさまざまなネットワークのユースケースが可能になります。

• CloudflareはeBPFを使用してDDoS攻撃を検出および防止し、ネットワークパフォーマンスに影響を与えることなく毎秒1,000万パケットを処理します。
• Meta の eBPF ベースのKatran はFacebook 全体の負荷分散を行います

可観測性

ここまでで、eBPF が可観測性においてどのように役立つかは簡単に理解できるはずです。

すべてがカーネルを通過します。また、eBPF は、カーネルからすべてを監視するための高性能かつ安全な方法を提供します。

可観測性についてさらに深く掘り下げて、このテクノロジーの意味を見てみましょう。

eBPF はオブザーバビリティに具体的にどのような影響を与えますか?

これを探るために、eBPF の世界から可観測性の世界に入り、標準の可観測性ソリューションを構成するものを見てみましょう。

可観測性ソリューションには 4 つの主要コンポーネントがあります。

1. データ収集- アプリケーションおよびインフラストラクチャからテレメトリ データを取得する

2. データ処理- 収集されたデータのフィルタリング、インデックス付け、および計算の実行

3. データストレージ- データの短期および長期ストレージ

4. ユーザー エクスペリエンス層- ユーザーによるデータの消費方法の決定

   
   

このうち、eBPF が (今日の時点で) 影響を与えるのは、実際にはデータ収集層、つまり eBPF を使用してカーネルから直接テレメトリ データを簡単に収集することだけです。

したがって、今日「eBPF 可観測性」と言うとき、私たちが意味するのは、他の計測方法を使用するのではなく、テレメトリ データを収集するための計測メカニズムとして eBPF を使用することです。可観測性ソリューションの他のコンポーネントは影響を受けません。

eBPF 可観測性の仕組み

eBPF 可観測性の背後にある基盤となるメカニズムを完全に理解するには、フックの概念を理解する必要があります。

前に見たように、eBPF プログラムは主にイベント駆動型です。つまり、特定のイベントが発生するたびにトリガーされます。たとえば、関数呼び出しが行われるたびに、可観測性を目的として eBPF プログラムを呼び出してデータをキャプチャできます。

まず、これらのフックはカーネル空間またはユーザー空間に配置できます。したがって、eBPF を使用して、ユーザー空間アプリケーションとカーネルレベルのイベントの両方を監視できます。

第 2 に、これらのフックは事前に決定された静的なものにすることも、実行中のシステムに (再起動なしで) 動的に挿入することもできます。

4 つの異なる eBPF メカニズムにより、これらのそれぞれが可能になります (以下の図を参照)。

ユーザー空間とカーネル空間への静的および動的 eBPF フック

1. カーネル トレースポイント- カーネル開発者によって事前定義されたイベントにフックするために使用されます (TRACE_EVENT マクロを使用)

2. USDT - アプリケーション コードで開発者によって設定された事前定義されたトレースポイントにフックするために使用されます。

3. Kprobes (カーネル プローブ) - 実行時にカーネル コードの任意の部分に動的にフックするために使用されます。

4. Uprobes (ユーザー プローブ) - 実行時にユーザー空間アプリケーションの任意の部分に動的にフックするために使用されます。

   
   

カーネル空間には、eBPF プログラムを簡単に接続できる事前定義されたフックがいくつかあります (システム コール、関数の出入り、ネットワーク イベント、カーネル トレースポイントなど)。同様に、ユーザー空間でも、多くの言語ランタイム、データベース システム、およびソフトウェア スタックが、eBPF プログラムがフックできる Linux BCC ツール用の事前定義されたフックを公開しています。

しかし、さらに興味深いのは kprobes と uprobes です。実稼働環境で何かが壊れていて、十分な情報がなく、実行時にインストルメンテーションを動的に追加したい場合はどうすればよいでしょうか?そこで、kprobe と uprobe によって強力な可観測性が可能になります。

たとえば、uprobe を使用すると、実行時にアプリケーションのコードを変更することなく、アプリケーション内の特定の関数にフックできます。関数が実行されるたびに、eBPF プログラムをトリガーして必要なデータをキャプチャできます。これにより、 ライブデバッグなどの興味深い可能性が可能になります。

eBPF による可観測性がどのように機能するかがわかったので、ユースケースを見てみましょう。

eBPF 可観測性の使用例

eBPF は、ほぼすべての一般的な既存の可観測性のユースケースに使用でき、さらに新しい可能性も開きます。

1. システムおよびインフラストラクチャの監視: eBPF を使用すると、CPU 使用率、メモリ割り当て、ディスク I/O、ネットワーク トラフィックなどのシステム レベルのイベントを詳細に監視できます。たとえば、 LinkedIn はすべてのインフラ監視に eBPF を使用しています。

   
   

2. コンテナーと Kubernetes の監視: Kubernetes 固有のメトリクス、リソース使用量、および個々のコンテナーとポッドの健全性を可視化します。

   
   

3. アプリケーション パフォーマンス モニタリング (APM):ユーザー空間アプリケーションのきめ細かい可観測性と、アプリケーションのスループット、エラー率、レイテンシー、およびトレースの可視性。

   
   

4. カスタムの可観測性:カスタム コードを作成しないと簡単に入手できない、アプリケーションまたはインフラに固有のカスタム メトリクスを可視化します。

   
   

5. 高度な可観測性: eBPF は、 ライブ デバッグ、低オーバーヘッドのアプリケーション プロファイリング、システム コール トレースなどの高度な可観測性のユース ケースに使用できます。

   
   

可観測性における eBPF の新しいアプリケーションが毎日登場しています。

これは、今日の可観測性の実現方法にとって何を意味するのでしょうか? eBPF は既存の形式の計測器に置き換わる可能性がありますか?既存のオプションと比較してみましょう。

eBPF と既存の計測方法の比較

現在、eBPF とは別に、可観測性を実現するためにアプリケーションとインフラストラクチャを計測する主な方法が 2 つあります。

1. エージェントベースの計測:テレメトリ データを収集するために、アプリケーション コードまたはインフラストラクチャ ノードに統合された独立したソフトウェア SDK/ライブラリ。

1. サイドカー プロキシベースのインストルメンテーション: サイドカーは、アプリケーションまたはサービスと一緒に実行される軽量の独立したプロセスです。これらは、マイクロサービスや Kubernetes などのコンテナベースのアーキテクチャで人気があります。

   
   

eBPF ベースのインストルメンテーションとエージェントおよびサイドカーの比較の詳細については、ここを参照してください。以下は概要ビューです -

ご覧のとおり、eBPF は、ほぼすべてのパラメーターにわたって既存の計測方法よりも優れたパフォーマンスを発揮します。いくつかの利点があります -

1. すべてを一度にカバーできる(インフラストラクチャ、アプリケーション)

2. 煩わしさが少ない- eBPF は、ワークロードが実行されるたびに実行されるコード エージェントのように、実行中のワークロードのインラインではありません。データ収集は帯域外でサンドボックス化されるため、実行中のシステムには影響がありません。

3. 低パフォーマンスのオーバーヘッド- eBPF はネイティブ マシン コードとして実行され、コンテキストの切り替えはありません。

4. より安全- 検証などの組み込みのセキュリティ対策により。

5. インストールが簡単- コードの変更や再起動を行わずにドロップインできます。

6. 保守と更新が簡単- ここでもコードの変更や再起動は必要ありません。

7. よりスケーラブル- 実装とメンテナンスが簡単で、パフォーマンスのオーバーヘッドが低いため

   
   

短所に関して言えば、今日の 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 が使用される可能性があります。可能性は広く、まだ開拓されていません。

参考文献

1. https://www.oreilly.com/library/view/learning-ebpf/9781098135119/ch01.html
2. https://ebpf.io/
3. https://ebpf.io/summit-2022.html
4. https://github.com/microsoft/ebpf-for-windows
5. https://events.linuxfoundation.org/wp-content/uploads/2022/10/elena-zannoni-tracing-tutorial-LF-2021.pdf

こちらでも公開しております。