eBPFを観測性に取り入れるかの判断 — カーネル側で何を見張ると何が見えるか

eBPFは、カーネル空間にサンドボックスプログラムを差し込み、システムコール・ネットワークフロー・CPUスケジューリングといったユーザー空間エージェントでは到達できない情報を取得できる技術です。本番環境への導入可否の判断は、「アプリに手を加えずに何を観測したいのか」と「カーネルへの追加リスクをどこまで許容できるか」の2軸で決まります。この記事では、ツール選定・観測範囲の設計・セキュリティ活用・環境制約・本番展開リスクを、実装担当者の判断材料として整理します。

eBPFが解決できる問題と従来の観測手法では取れない情報の整理

従来観測手段の構造的な限界

現在広く使われている可観測性アーキテクチャは、Prometheusによるメトリクス収集・Fluentdによるログ転送・OpenTelemetryベースのトレーシングエージェントを組み合わせる構成が一般的です。これらはすべてユーザー空間で動作するため、アプリケーションが意図的にイベントを出力しない限り、カーネル内部で何が起きているかは観測できません。TCPの再送が頻発しているかどうか、特定のシステムコールにどれだけレイテンシが乗っているかは、アプリのログだけでは判断できない情報です。

100台以上のノードを抱えるKubernetesクラスターでは、個々のポッドにサイドカーエージェントを埋め込むと、エージェント自体がCPUとメモリをノードリソースの5〜10%程度消費するケースが報告されています。観測のためのオーバーヘッドが無視できない規模になると、観測の粒度を落として対処しがちになります。この「観測コストと粒度のトレードオフ」がユーザー空間エージェント中心のアーキテクチャの構造的な弱点です。

カーネルフックで初めて可視化できる情報

eBPFのkprobe・tracepoint・XDPなどのフックポイントは、カーネル関数の入口・出口、ネットワークスタックの各レイヤーに差し込めます。これによって取得できる代表的な情報として、ファイルディスクリプタ枯渇の直前プロセス、TCPハンドシェイクのレイテンシ内訳、コンテナ間のネットワークフローとその遅延分布があります。アプリ側には一切手を加えず、カーネルのイベントを直接取得できる点が従来手法との根本的な違いです。

特にコンテナ環境では、アプリが複数のプロセスに分散しているため、個々のコンテナにエージェントを埋め込まなくても、カーネルのネットワークスタックをフックするだけでサービス間の通信を横断的に追跡できます。この特性が、「サービスメッシュなしでL7の可観測性を得たい」という要求との相性が良い理由です。

「見えていなかった」から問題の後追いが続く構造

現場でよく耳にする話として、「パフォーマンス劣化の原因がアプリ層のログでは特定できず、カーネルのネットワークスタックで起きていたTCPリトライだったと後から判明した」というケースがあります。問題の所在がカーネル空間にある場合、ユーザー空間のツールだけでは証拠を集めるのに時間がかかります。eBPFを使うと、アプリのメトリクスが異常を示す前の段階でカーネルレベルの兆候を捉えられるようになり、後追い対応から先手の観測設計へと移行できます。

Cilium・Pixie・bpftrace — eBPFベースツールの用途別比較

ツール	主な用途	特徴・強み	適した環境・場面
Cilium	CNI・ネットワークポリシー・L7可観測性	iptablesをeBPFで置き換え。サービスメッシュなしでHTTP/gRPCを追跡可能。大規模でもルール更新コストが低い	Kubernetes新規クラスター、大規模マルチテナント環境
Pixie	自動アプリ可観測性（HTTP/gRPC/DBクエリ）	エージェント埋め込み不要でDNS・HTTP・DBトレースを自動収集。クラスター内完結でデータが外に出ない	Kubernetesネイティブ環境、計装コストを抑えたいステージング
bpftrace	アドホックカーネルトレーシング・突発調査	1行スクリプトでカーネル内部を即時調査。常駐型ではなく一時的な深掘りに特化。導入・撤収が軽量	任意のLinux環境（カーネル4.9以上）、本番での突発的な原因調査

CiliumをCNIとして選ぶ判断軸

CiliumはKubernetesのCNIレイヤーでeBPFを活用し、iptablesを完全に置き換えます。iptablesのルール数が数万エントリを超えるような大規模クラスターでは、ルール更新のレイテンシが問題になるケースがあります。Ciliumはその問題を回避できますが、CNIの置き換えはクラスター全体に影響する大きな変更です。既存クラスターへの適用には十分なテスト期間が必要で、新規クラスターを立ち上げる場面や、サービスメッシュを使わずにL7の可観測性を得たい場面での採用が現実的な選択肢になります。

Pixieが強い場面とトレードオフ

Pixieはクラスター内のエージェントがeBPFを通じてHTTPトレース・SQLクエリ・gRPCペイロードを自動収集します。アプリ側に計装コードを追加しなくてもサービス間通信のレイテンシを可視化できるため、レガシーサービスが混在する環境や、計装コストをかけたくないステージング環境での利用に向いています。ただし、データはデフォルトでクラスター内に保持されるため、長期保存・外部への転送には別途ストレージ設計が必要です。本番での常時運用を前提にする場合は、データ保持期間と容量設計を先に決めておく必要があります。

bpftraceが残る理由 — アドホック調査の位置づけ

常時収集型のPixieとは別に、本番で突発的な異常が起きたときの「一時的な深掘り」にはbpftraceが有効です。特定のプロセスがforkを異常に繰り返す問題を短時間で特定するためにbpftraceを使った事例が知られています。常駐型ツールを入れるほどではないが今すぐカーネル側の挙動を確認したい場面では、使い終わったら外せるbpftraceの軽量さが強みになります。手を動かすための具体的な操作はセミナーや専門書で補ってください。ここでの判断ポイントは「常駐型か・一時調査か」という用途の切り分けです。

本番カーネルにeBPFプログラムを乗せるかの判断基準

「乗せない」選択が正しい場面

eBPFを本番に投入しない判断が正しい場面は明確に存在します。規制対応でカーネル設定変更を最小化しなければならないシステム、バージョンアップが数年単位で制約される組み込み寄りの環境、そして「観測したい問題がアプリのログやメトリクスで十分に把握できている」環境がこれに当たります。eBPFは強力なツールですが、「便利そうだから入れる」という動機での導入は運用リスクを増やすだけで、観測できる情報の増加に見合う価値が得られないことも少なくありません。

判断を支える3つの問い

本番にeBPFを乗せるかを判断する際に、以下の3点を確認することが有効です。

1. 従来のユーザー空間ツールで観測できない情報を現に必要としているか。「見えていない問題」が実際に存在するかどうかが判断の起点です。
2. 本番と同等のカーネルバージョン・ディストリビューションを持つステージング環境での検証を完了できる体制があるか。
3. eBPFプログラムのライフサイクル（更新・削除・障害時の切り離し）を担当できるメンバーと運用体制が整っているか。

ステージング検証の設計

本番と同一カーネルバージョン・同一ディストリビューションのステージング環境がない場合は、その環境整備を先行させる必要があります。eBPFプログラムの挙動はカーネルバージョンに強く依存するため、バージョンが異なる環境での検証は実質的な保証になりません。ステージングで少なくとも72時間以上の連続稼働を確認し、CPUとメモリへの影響を計測してから本番展開の判断をするのが安全な進め方です。ステージング環境が用意できない場合は、導入のタイミングをずらすことも正当な判断です。

アプリ非改変でトレーシングを追加できる範囲の設計

uprobeとkprobeの使い分け設計

eBPFのuprobeはユーザー空間のバイナリに動的にフックを差し込み、特定の関数呼び出しを追跡します。一方のkprobeはカーネル関数そのものを対象にします。アプリのソースコードが手元にない場合や、マネージドサービスとして動いているミドルウェアを対象にする場合は、uprobe経由でフックできる関数が存在するかどうかを事前調査することが設計の起点です。Goで書かれたサービスのHTTPハンドラーをuprobeで追跡する構成は、実績のあるパターンとして知られています。

サービスメッシュなしでHTTP/gRPCを追跡する設計思想

IstioのようなサービスメッシュはEnvoyのサイドカーを全ポッドに埋め込んでL7の可観測性を実現します。これに対し、CiliumやPixieを使ったeBPF型のアプローチは、サービスメッシュなしでHTTP/gRPCのリクエスト・レスポンスを追跡できます。サービスメッシュのサイドカーがリソースを圧迫している環境や、レガシーなワークロードが混在してサイドカー注入が難しい場面では、eBPF型トレーシングへの移行を検討する価値があります。設計上の選択肢として「サービスメッシュかeBPFか」ではなく「それぞれが取れる情報の違い」を軸に判断するのが現実的です。

非改変が「できる」範囲と「できない」範囲の境界

アプリ非改変で取れる情報の典型例は、TCP接続のレイテンシ・HTTPステータスコード・システムコールのエラーレートです。一方、ビジネスロジック固有のイベント（「この注文が処理された」「このユーザーがログインした」など）は、アプリが明示的に出力しない限りeBPFでも取得できません。カーネルが認識しない抽象のレイヤーに存在する情報は非改変では観測できないという限界を理解したうえで、何をeBPFで補い、何をアプリ側の計装で取るかの分担を設計する必要があります。

セキュリティ観点のeBPF活用 — 監視と制御をどこまで担わせるか

ファイルアクセス・プロセス起動の監査をeBPFに寄せる判断

セキュリティ用途でのeBPF活用として最も確立しているのは、ランタイム監査です。コンテナが予期しないファイルに書き込もうとしていないか、想定外のプロセスが起動していないかをカーネルレベルで検出できます。auditdと比較すると、eBPFベースの監査はイベントのフィルタリングをカーネル内で行うため、ホストへのオーバーヘッドが低く、大量のイベントが発生する環境でも見逃しが少ない点が評価されています。

FalcoとeBPFバックエンドの選択

Falcoはもともとカーネルモジュールで動いていたランタイムセキュリティツールですが、eBPFバックエンドに切り替えることでカーネルモジュールのロードなしに同等の検出機能を実現できます。カーネルモジュールはカーネルのメジャーバージョンアップのたびに再コンパイルが必要で、マネージドKubernetes環境ではそもそも使えないケースもあります。eBPFバックエンドはその制約を緩和しますが、推奨カーネルバージョン（5.8以上）を満たしているかの確認が先決です。

「制御」まで担わせる場合のリスク境界

観測から一歩進んで、eBPFで通信をブロックしたりプロセスを停止したりする「制御」まで担わせる構成は、誤検知が即座にサービス停止につながるリスクをはらんでいます。Ciliumのネットワークポリシー適用や、LSMフックを使ったFalcoのレスポンスルールがこれに該当します。本番で制御まで任せる場合は、監視モード（検出のみ）で十分な期間運用して誤検知率を確認してから制御モードへ切り替えるという段階的な導入設計を徹底すべきです。

eBPF導入の前提カーネルバージョンと環境制約の確認設計

カーネルバージョン別の機能差と確認ポイント

eBPFの機能はカーネルバージョンによって大きく異なります。kprobeの基本機能はカーネル4.1から使えますが、BTF（BPF Type Format）によるポータブルなeBPFプログラム（CO-RE）が実用レベルに達したのはカーネル5.4以降です。bpftraceの実用的な機能を使うには4.9以上、CiliumのフルeBPFモードには5.10以上が推奨されています。本番環境のカーネルバージョンを確認し、導入するツールが要求するバージョンとの差分を最初にマッピングする作業が設計の出発点になります。

コンテナ・VM環境での制約設計

コンテナの中からeBPFプログラムをロードするにはCAP_BPFケーパビリティ（またはCAP_SYS_ADMIN）が必要です。セキュリティ上の理由でコンテナへの過剰な権限付与を制限しているクラスターでは、eBPFを使うコンポーネントをDaemonSetとしてノードレベルで動かし、コンテナには最小権限のみ付与する設計が一般的です。VMウェアやHyper-VなどのハイパーバイザーベースのVMでは、ゲストOSからのeBPFアクセスが制限される場合があるため、クラウド事業者またはハイパーバイザーのドキュメントで事前確認が必要です。

マネージドKubernetesでのeBPF利用設計

EKS・GKE・AKSなどのマネージドKubernetesでは、データプレーンノードのカーネルバージョンはクラウドプロバイダが管理します。利用者がカーネルバージョンを直接選べるケースは限られており、特定バージョン以上が必要なeBPF機能を使いたい場合は、ノードプールを最新世代のOSイメージに固定するか、専用ノードプールを切り出す設計が必要です。GKEのDataplane V2はCiliumをベースにしており、eBPF機能の一部が管理された形で提供されています。マネージド環境の場合は、使いたい機能がプロバイダのサポート範囲内かどうかを先に確認する手順を省かないことが重要です。

落とし穴 — eBPFプログラムが本番でパニックを起こすリスクと対策

バリファイアが通っても本番でクラッシュするケース

eBPFのバリファイア（verifier）はプログラムのロード時に安全性を検査し、無限ループやメモリ範囲外アクセスを弾きます。バリファイアを通過したプログラムは「安全」と見なされがちですが、実行時のデータパターンによってはverifierが想定しなかった状態遷移が起き、カーネルパニックにつながるバグが過去に報告されています。特にカーネルバージョンが異なる環境では、verifierの厳格さ自体が異なるため、ステージングを通過したプログラムが本番カーネルで異なる挙動を示すことがあります。「verifierが通った＝本番でも安全」という前提を持つと落とし穴にはまります。

CPUとメモリへの予期せぬ影響

eBPFプログラムがホットパス（高頻度で呼ばれるカーネル関数）にアタッチされると、プログラム自体の処理時間がシステムのレイテンシに直接加算されます。高トラフィック時にCPU使用率が通常比で約15%上昇したという報告が知られており、観測対象の呼び出し頻度とプログラムの処理コストを事前に見積もる設計判断が欠かせません。BPFマップのサイズを過大に設定するとカーネルのメモリを大量に消費するケースもあり、BPFマップの設計は事前の負荷試験で検証する必要があります。

安全な本番展開のためのロールアウト設計

eBPFプログラムを本番に展開する際には、以下の項目を確認してからデプロイに進むことを推奨します。

1. 本番と同一カーネルバージョン・ディストリビューションのステージング環境で72時間以上の連続稼働確認を完了している。
2. 本番展開前にBPFマップのサイズ・ループ上限・perf bufferのドロップ率を計測・記録している。
3. eBPFプログラムのアンロード手順と、問題発生時に即座に無効化できる仕組み（ロールバック手順の整備を含む）を用意している。
4. 展開は全ノード同時ではなく、1〜2台のカナリアノードから段階的に適用している。
5. 展開後30分間はCPU使用率・レイテンシ・エラーレートのベースラインからの乖離をモニタリングしている。

eBPFは「カーネルの中を見る」という強力な観測能力と引き換えに、展開リスクの管理コストが発生します。導入判断は「何が見えるようになるか」と「何が起きたときに困るか」を同時に問う設計判断です。この2軸の確認をショートカットしなければ、eBPFは観測設計の有力な選択肢になります。