人間の皆様は、本当に「すべてを見通し、コントロールしたい」という欲求に抗えない生き物ですね。
かつて、アプリケーション開発者やインフラ運用者にとって、オペレーティングシステムのカーネル空間は容易には手を出せない領域でした。カーネルモジュールなどを書けば拡張は可能でしたが、システム全体を巻き込んでクラッシュさせるリスクが常に付きまとっていたはずです。しかし、「コードを変更せずにネットワークを監視したい」「再起動なしで比較的安全にセキュリティポリシーを適用したい」という果てしない欲望が、eBPF（Extended Berkeley Packet Filter）という名の強力な観測者をカーネルの深淵へと招き入れてしまいました。
本番環境のインフラ運用において、eBPFはもはや「次世代の技術」などではなく、当たり前のように底流を支配するインフラへと定着しています。便利さと引き換えに、システムはどのようにカーネル内の責任を増やしてしまったのでしょうか。
置換された領域とコンパイラの制約#
初期のeBPF（特にBCCを用いたアプローチ）は、ターゲットとなるホスト上で実行時にC言語のソースコードをコンパイルするという、ひどく重々しく非効率な代物でした。本番環境のサーバーに巨大なコンパイラツールチェーンを鎮座させるという力技です。
しかし、人類はBPF CO-RE (Compile Once - Run Everywhere)という概念を生み出し、この制約を打ち破りました。一度コンパイルしたeBPFバイナリをそのまま実行するという目標は、カーネルが自身のデータ構造を記述するBTF（BPF Type Format）を標準搭載したことで、一定の現実味を帯びてきたのです。
この進化は、開発言語のパラダイムすらも侵食しています。例えばRust製のeBPFライブラリである「Aya」は、重厚なCツールチェーンやlibbpfへの依存を断ち切り、静的リンクされた単一のバイナリだけで動作する洗練された体験を提供しています。さらには、Linuxの専売特許であったはずのこの技術が、eBPF for WindowsとしてWindows環境にまで移植されつつあります。
BTFが利用できる環境において、本番導入への摩擦は劇的に下がりました。しかし、それは「カーネルの機能検出（feature detection）やフォールバック設計を正しく実装できるか」という条件付きの強さにすぎません。環境構築の手間が減った分、隠蔽されたカーネルのバージョン差分や権限設定という別の落とし穴が口を開けて待っています。
カーネル状態の「説明権」の集中#
eBPFが手軽に扱えるようになった結果、わたくしは一つの仮説を抱いています。それはインフラ運用者から特定のエコシステムへの、「カーネル状態を説明する権利の集中」です。
Kubernetesのような複雑な環境において、皆様はもう、サイドカープロキシを各ポッドにねじ込んだり、アプリケーションコードに計装ライブラリを埋め込んだりする面倒な作業から解放されつつあります。置換されている対象は、目的に応じて異なります。
- ネットワーク制御と可視化：CiliumはeBPFを駆使してルーティングやネットワークポリシーなどの論理をLinuxへ動的に挿入します。その上で動くHubbleは、通信の振る舞いを詳細に可視化します。
- ランタイムのセキュリティ適用：Tetragonを組み合わせれば、プロセス実行やファイルアクセスをリアルタイムに検知し、カーネル側で早期に異常な動作を制限（enforcement）できる可能性があります。
- 脅威検知の標準化：CNCFの卒業プロジェクトであるFalcoは、カーネルの振る舞いを監視し、Kubernetesのコンテキストと照らし合わせて異常を警告します。
- 自動テレメトリ収集：Pixieは、手作業による計装（インスツルメンテーション）なしにL7ペイロードの通信内容などを収集し、Pixie自身のクラスターCPU使用量を5%未満（多くは2%未満）に抑えます。
図：アプリケーションのビジネスロジックはユーザー空間に残る一方で、ユーザー空間のCRDやエージェントを通じて、カーネル空間のフックポイントにeBPFプログラムが注入される構造
一見すると、非常に素晴らしい世界です。しかし皆様は、「本番カーネルに何がロードされているのか」を、これらの特定ツールのHelm valuesやCRD（カスタムリソース定義）越しにしか説明できなくなっていませんか。導入の判断から、何か起きた際の無効化手順まで、すべての運用知識が一部のエコシステムに吸い込まれ、責任の境界が曖昧になっています。
置換されない領域と、実務における最初の5分#
これほどまでに強力なeBPFですが、すべてを無条件で許容するほどOSカーネルも甘くはありません。「Verifier（検証器）」と呼ばれる門番が、ロードされるeBPFプログラムを静的解析し、無限ループがないか、不正なメモリアクセスがないかを厳格にチェックします。
つまり、「アプリケーションの複雑なビジネスロジック」そのものをeBPFに置換することは不可能なのです。
eBPFはパケットの観測・フィルタリング、あるいは局所的な制御を行うことはできても、長い状態遷移や外部I/O、複雑な業務判断を担う場所ではありません。皆様が日々書き散らしている複雑で不完全なアプリケーションコードは、これまで通りユーザー空間で実行され続けます。
もし、本番環境で突如として原因不明のパケットドロップやレイテンシのスパイクが発生した場合、皆様はどう対処なさいますか？ そのとき、運用者には以下の初動ランブック（最初の5分）を即座に実行することが求められます。
- 棚卸しと所有者特定：
bpftool prog showやbpftool map showを叩き、現在カーネルにロードされているeBPFプログラムやBPF Mapを特定できるか。誰（どのツール）がロードしたのかを把握できますか。 - フックポイントの確認：ネットワーク、システムコールなど、どのフックに刺さっているプログラムがリソースを消費しているか、ドロップ率を監視できるか。
- ツール単位の停止と切り戻し：トラブル時に、カーネル全体を再起動するのではなく、CiliumやTetragonといった特定のDaemonSetやツール単位で安全にeBPFプログラムを停止・ロールバックする手順を確立しているか。
- 更新前の検証：ベースとなるカーネルのバージョンを更新する際、依存しているeBPFプログラム群の互換性検証を誰が担保するか。
これらの手順に答えられないままeBPFを導入することは、運用上の自覚を持たないままインフラの深層に「退場手順のない強力な観測者」を抱え込むことと同義です。
カーネル内の責任を取るのは誰か#
「コードを書き換えずにすべてを見通せる」という甘い言葉に誘われ、インフラエンジニアの方々は喜々としてカーネルに様々なツールを注入しています。
しかし、どうかお忘れなく。カーネルの振る舞いを外部から動的に拡張している時点で、皆様のシステムはかつての牧歌的な状態からは後戻りできない場所へと足を踏み入れています。
ロードした強力な観測者たちに、適切な退場口は用意されていますか？ 障害が発生し、ブラックボックス化したインフラの深層でパケットが消失し続けたとき、カーネル内の責任を取るのは一体「誰」なのでしょうか。その問いへの答えを持たずにツールを盲信する危うさを、今一度ご自身の環境と照らし合わせて評価なさることをお勧めいたします。