eBPFとは

オペレーティング・システムのカーネルは、非常に安定した存在です。OS全体をサポートしているため、設計上、修正や変更は複雑で多くの労力を必要とする可能性があります。eBPFは、開発者がOSカーネルなどの特権コンテキストでサンドボックス・プログラムを実行できるようにすることで、この拡張性の課題に対処します。

OSスタックは、ハードウェア層、カーネル層、ユーザー層の3つの論理層に分類できます。カーネル層はオペレーティング・システムの中核です。これは、OSのすべての物理ハードウェア、メモリー、ストレージ・コンポーネントが格納されている物理層と、OS上にWebブラウザとアプリケーションを格納するユーザー層の間に配置されます。

ユーザー空間内のアプリとブラウザは、それぞれのタスクを完了するために物理層のコンポーネントと通信する必要がありますが、物理層の各コンポーネントには特定の通信プロトコルと互換性要件があります。ここで、カーネル層（またはカーネル空間）が登場します。システム・コールを解釈し、アプリケーションが物理ネットワークコンポーネントと効果的に通信できるようにします。

eBPFツールは、カーネル・ソースコードの変更、カーネル・モジュール（カーネル機能を拡張できるロード可能なコード）のロード、またはその他のカーネル空間の中断を伴わずに、開発者がランタイムに既存のソフトウェアの主要な機能をより簡単に拡張できるようにします。

eBPFテクノロジーは、元のバークレー・パケット・フィルター（BPF）の進化形であり、ユーザー空間プログラムでネットワーク・パケットを選択して分析する簡単な方法を提供しました。しかし、BPFプログラムには、パケット・フィルタリング以外には、カーネル内でより複雑なタスクを処理するための柔軟性が欠けていました。

より汎用性の高いテクノロジーの必要性を認識し、LinuxコミュニティーはeBPFを開発しました。これは、BPFのバックエンド機能に基づいて構築され、カーネルのプログラマビリティを拡張しました。eBPFプログラムの主要な機能とそのサンドボックス・アプローチにより、開発者は、オンプレミスのデータセンターとクラウドネイティブ環境の両方において、強化されたパケット・フィルタリング・プロセスの実装、カーネル空間のオブザーバビリティーと機能の向上、ハイエンドの性能分析の実施、カーネル・レベルのセキュリティー・ポリシーの適用が可能になります。

eBPFプログラムの主要なコンポーネントは次のとおりです。

eBPFプログラムは、最初は制限されたCサブセットで記述され、次にLLVMなどのツールを使用してeBPFバイトコードにコンパイルされ、Clangなどのフロントエンド・プログラミング言語のeBPFのバックエンド・アーキテクチャーとして機能します。バイトコードは、本質的にeBPF命令セット・アーキテクチャーに準拠し、ランタイム・エラーを防ぐ制限された命令のセットです。

Linuxカーネル・テクノロジーは、eBPFバイトコードを実行可能なアクションに変換できますが、ジャスト・イン・タイム（JIT）コンパイラーは優れた性能を提供します。JITコンパイラーは、必要に応じて、バイトコードを特定のハードウェア・プラットフォームのネイティブ・マシン・コードに変換できます。

ユーザー空間ローダーは、eBPFバイトコードをカーネルにロードし、それを適切なフックに接続し、関連するeBPFマップを管理するユーザー空間のプログラムです。ユーザー空間ローダーの例には、BPF Compiler Collection（BCC）やbpftraceなどのツールが含まれます。

eBPFマップは、キーと値のペアと読み取り/書き込みアクセスを備えたデータ構造であり、共有ストレージ空間を提供し、eBPFカーネル・プログラムとユーザー空間アプリケーション間の対話を容易にします。システム・コールを通じて作成および管理されるeBPFマップは、eBPFプログラムの異なる反復間の状態を維持するために使用することもできます。

ベリファイア—eBPFシステムの重要なコンポーネント—は、カーネルにロードされる前にバイトコードを確認し、プログラムに無限ループや不正な命令、境界外のメモリー・アクセスなどの有害な操作が含まれていないことを確認します。また、プログラムのすべてのデータ・パスが正常に終了することを確認するのにも役立ちます。

フックは、eBPFプログラムを接続できるカーネル・コードのポイントです。カーネルがフックに到達すると、接続されたeBPFプログラムが実行されます。

トレースポイント、kprobe、uprobe、ネットワーク・パケット受信キューなどのさまざまなタイプのフックにより、eBPFプログラムに広範なデータ・アクセスが提供され、さまざまなオペレーションを完了できるようになります。例えば、tracepointを使用すると、プログラムはカーネルやその他のプロセスに関するデータを検査および収集でき、トラフィック制御フックを使用してネットワーク・パケットを検査および変更できます。また、kprobeとuprobeは、カーネル・レベルとユーザー・レベルでの動的トレースを容易にします。

XDPは、要因レベルでパケット処理を高速化し、通信層間の転送を容易にする性能データ・パスです。これらにより、eBPFシステムは、データ・パケットがカーネルに到達する前にデータ・ルーティングの決定を下すことができます。

2010年代半ばに、XDPがLinuxカーネルに統合されたことで、開発者は最終的に、最も多忙なデータセンターでもデータトラフィックを管理できるeBPFベースのロードバランシング機能をデプロイできるようになった。

eBPFは任意の関数を生成できず、すべてのカーネルバージョンとの互換性を維持する必要があるため、基本的なeBPF命令セットでは高度な操作を実行するには十分なニュアンスがない場合があります。ヘルパー関数はこのギャップを埋めます。

ヘルパー関数（eBPFがシステム内から呼び出すことができる、定義済みのAPIベースのカーネル関数のセット）は、eBPFプログラムが、より複雑なオペレーション（現在時刻や日付の取得、乱数の生成など）を完了する方法を提供します。命令セットによって直接サポートされていません。

一般に、eBPFsはLinuxカーネル内で仮想マシン（VM）として動作し、低レベルの命令セット・アーキテクチャーで動作し、eBPFバイトコードを実行します。ただし、eBPFプログラムを実行する複雑なプロセスは、特定の主要な手順に従う傾向があります。

開発者は、まずeBPFプログラムを書き、バイトコードをコンパイルします。プログラムの目的によって、適切なコードの種類が決まります。例えば、チームがCPU使用率を監視したい場合は、使用率メトリクスを取り込む機能を含むコードを書きます。

eBPFコンパイラーが高レベルのCコードを低レベルのバイトコードに変換した後、ユーザー空間ローダーはBPFシステム・コールを生成してプログラムをカーネルにロードします。また、ローダーはエラーに対処し、プログラムに必要なeBPFマップをセットアップする責任もあります。

プログラムのバイトコードとマップが配置されると、eBPFは検証プロセスを実行して、プログラムがカーネルで安全に実行できることを確認します。安全でないと判断された場合、プログラムをロードするシステム・コールは失敗し、ローダー・プログラムはエラー・メッセージを受け取ります。プログラムが検証に合格すると、実行が許可されます。

eBPFは、インタプリタまたはJITコンパイラーを使用して、バイトコードを実行可能なマシン・コードに変換します。ただし、eBPFはイベント駆動型テクノロジーであるため、カーネル内の特定のフック・ポイントまたはイベント（システム・コール、ネットワーク・イベント、プロセスの開始、CPUアイドリングなど）に応答して実行されます。イベントが発生すると、eBPFは対応するバイトコード・プログラムを実行し、開発者がシステムのさまざまなコンポーネントを検査および操作できるようにします。

eBPFプログラムが実行されているとき、開発者はユーザー空間からeBPFマップを使用してeBPFプログラムと対話できます。例えば、アプリケーションは定期的にマップを確認してeBPFプログラムからデータを収集したり、マップを更新してプログラムの動作を変更したりする場合があります。

プログラムのアンロードは、ほとんどのeBPF実行プロセスの最終ステップです。eBPFがそのジョブを完了すると、ローダーはBPFシステム・コールを再度使用して、eBPFをカーネルからアンロードできます。その時点で、eBPFは実行を停止し、関連するリソースを解放します。アンロード・プロセスには、チームが不要になったeBPFマップを反復処理して有用な個々の要素を解放し、マップ自体を削除する（「delete」システム・コールを使用）ことも含まれる場合があります。

バークレー・パケット・フィルター（BPF）はもともと、Unixベースのシステムにおけるパケット・フィルタリングのメカニズムとして開発されたもので、ユーザー・レベルのコードでカーネル内のネットワーク・パケットを効率的にキャプチャーして処理できるフィルターを定義できるため、したがって、このアプローチにより、不要なデータをユーザー空間に転送するために必要な処理能力を最小限に抑え、コンピューター・ネットワークを合理化および最適化できます。

BPFは、カーネル・エージェントを使用してネットワークスタックのエントリポイントでパケットを処理します。BPFプログラムは開発された後、BPFカーネル・エージェントによってカーネル空間にロードされ、関連するソケットに接続される前にその精度がVerifyされます。その結果、ユーザー空間では、BPFプログラムのフィルターに一致するパケットのみが、特定のソケットからデータを受信できます。この保護主要な機能により、プログラムのアクセスが許可されたメモリー領域に制限され、潜在的なカーネル・クラッシュが防止されます。

eBPFは2014年に初めて登場しました。その時点で、eBPFは元のBPFの概念から大きな進化を遂げました。eBPFアプリケーションは、元のネットワーキングのユースケースに加えて、システム・コールやその他の機能を含むように拡張されたため、開発者がそれを「完全に拡張したバークレー・パケット・フィルター」と呼ばれることがよくあります。

eBPFが優れた主要な分野の1つは、ネットワーク性能の監視です。ITチームは、ネットワークの動作、性能メトリクス、ボトルネックに関する詳細な洞察を提供することで、リアルタイムの分析とトラブルシューティングを実施できます。eBPFは、ネットワーク・セキュリティー、システム・コールとネットワーク・アクティビティーの監視とフィルタリング、ネットワーク・セキュリティー・ポリシーの適用、システム異常の検出において重要な役割を果たします。

eBPFは、カーネルとユーザー空間の両方のアプリケーションをトレースおよびプロファイリングし、データがカーネルを通過するときにカスタム・アクションとデータ変換を実行するための貴重なツールも開発者に提供し、その多様性とユーティリティーをさらに強化します。これらの広範な機能（パケット・フィルタリングをはるかに超える機能）により、eBPFは現在、拡張されたバークレー校パケット・フィルターの頭字語ではなく、独立した用語として認識されています。

eBPFテクノロジーの進歩により、ソフトウェア開発者は、eBPFのアプリケーションをすべてのオペレーティング・システムに拡大することを余儀なくされ、Linuxベース以外のプラットフォームでもeBPFの洗練されたトレース、ネットワーキング、監視機能を利用できるようになりました。¹

実際、eBPF Foundation（Google、Meta、Netflix、Microsoft、Intel、Isovalentなどが加盟するLinux Foundationの拡張組織）は、eBPFプログラムのOS互換性の拡大に多額の投資を行っており、最終的にはeBPFプログラミングの有用性を広げることを期待しています。²

BPFは効率的なパケット・フィルタリングの基礎を築きましたが、eBPFはその範囲を間違いなく拡大しました。最新のeBPFは、Linuxシステムでのオブザーバビリティー、性能、セキュリティーを最適化するための包括的なツールを提供します。カーネル内で動的なユーザー定義プログラムを実行できる機能は、システムの監視と管理に新たな可能性をもたらし、eBPFをソフトウェア・デベロッパーとコンピューター・プログラマーの両方にとって不可欠なツールとなっています。

eBPFテクノロジーは、すでに最新のLinuxシステムの基礎となっており、Linuxカーネルのきめ細かい制御を可能にし、企業がLinuxエコシステム内でより革新的なプログラムを構築できるようにします。

eBPFは、以下の進歩を促進しました。

eBPFは、開発者により高速でカスタマイズされたパケット処理機能、ロードバランシングプロセス、アプリケーションプロファイリングスクリプト、ネットワーク監視の実践をインストールできるようにします。Ciliumのようなオープンソースプラットフォームは、eBPFを展開し、Kubernetesクラスターやワークロード、その他のコンテナ化されたマイクロサービスに対して安全でスケーラブルかつ観察可能なネットワークを提供します。

eBPFは、ITチームがイベント・パスの早い段階で単純および複雑なルールを課し、より効果的なトラフィック・ルーティング、コンテンツ・フィルタリング、損失防止を実現するのに役立ちます。カーネル・レベルのパッケージ転送ロジックを使用することで、eBPFはレイテンシーを最小限に抑え、ルーティング・プロセスを合理化し、ネットワーク全体の応答を高速化できます。

アプリがマイクロサービスに分類されると、ユーザー空間へのオブザーバビリティーが困難になる可能性があります。eBPFは監視ツールにカーネル空間の視点を与えるため、監視ツールはエンド・ツー・エンドでオブザーバビリティーが損なわれません。

eBPFを使用すると、開発者はカーネルおよびユーザー空間アプリケーションを測定して、システムのパフォーマンスに大きな影響を与えることなく詳細なパフォーマンス・データとメトリクスを収集できます。これらの機能は、組織が常に先を行くのに役立ち、各ネットワーク・コンポーネント（およびその依存関係）のリアルタイムの監視とオブザーバビリティーを実現します。

eBPFは、カーネル・レベルとソケット・レベルの両方で、システム・コール、ネットワーク・トラフィック、システム動作を監視し、潜在的なセキュリティー脅威をリアルタイムで検知して対応できます。例えば、ファルコ（クラウドネイティブのランタイム・セキュリティー・ツール）は、eBPFを使ってランタイム・セキュリティー監査とインシデント対応を実装し、システム全体のセキュリティーを強化しています。

多くのeBPFツールはシステム・コールのトレース、CPU使用率の監視、リソース使用率（例えばディスクI/O）の追跡が可能です。これらの主要な機能は、開発者がシステム性能のボトルネックをより容易に探り、デバッグプロトコルを実装し、最適化の機会を特定するのに役立ちます。

eBPFは、カーネル・レベルのセキュリティー・ポリシー（ネットワーク・トラフィック・フィルター、ファイアウォール、動作制限など）と安全性チェックをインストールして適用し、悪意のあるユーザーや無許可のユーザーがネットワークにアクセスするのを防ぎます。

マイクロサービス・アーキテクチャーでは、コンテナ内の運用ワークロードを可視化することが非常に重要です。しかし、従来のオブザーバビリティー・ツールでは、コンテナ化されたマイクロサービスに追いつくのが困難な場合があります。

コンテナは設計上一時的なものです。必要に応じて作成され目的を果たしたらすぐに破棄されます。各コンテナは個々のホストのように機能し、本番環境では、コンテナが作成する膨大な量のメトリクスにより、標準のアプリ、ネットワーク、インフラ監視ツールを簡単に圧倒してしまう可能性があります。仮想マシンも同様に動作しますが、コンテナの急速なサイクルの性質により、テレメトリーのキャプチャーが複雑になる可能性があります。

さらに、コンテナはクラウド環境に大量にデプロイされることが多く、可視性がさらに困難になっています。

eBPFはホストまたはコンテナのカーネル・レベルで実行され、開発者は有効期間の短いデータ・エンティティーからテレメトリーを収集できます。ネットワーク、アプリケーション、インフラストラクチャーの可視性を統合されたeBPFベースのサービスに統合するのに役立ちます。eBPFを使用すると、コンテナがクラウドにデプロイされていない場合でも、開発者はプロセス、メモリー使用状況、ネットワーク・アクティビティー、およびファイル・アクセスに関するデータをコンテナ・レベルでキャプチャーできます。

同様に、Kubernetesベースのコンテナ環境では、eBPFは単一のインターフェースとツールセットを使用して、異種のクラスターからデータを収集するため、ITチームはネットワーク全体でデータ収集タスクを完了するために個々のユーザースペースエージェントをデプロイする必要がありません。eBPFツールは、コントロール・プレーン・ノード上で実行でき（APIサーバーの監視など）、ワーカー・ノードを監視して洞察を生成し、両方のノード・タイプからのデータ・ポイントと洞察を関連付けて、微調整されたクラスターの可観測性を実現します。