ゼロ計装オブザーバビリティ：eBPFがSidecarフリートを置き換えた方法
Engineering Team
67%のKubernetesチームがeBPFオブザーバビリティに切り替え
CNCF 2026年次調査によると、67%のKubernetesチームがオブザーバビリティの少なくとも1つの柱（メトリクス、トレース、またはログ）にeBPFベースのツールを使用しています——2024年の29%、2025年の41%から増加。この移行はもはや段階的ではなく、殺到です。
理由はシンプルです：従来のsidecarベースのオブザーバビリティ（Envoyプロキシ、OpenTelemetry Collectorサイドカー、Datadogエージェント）は膨大なリソースを消費し、すべてのリクエストにレイテンシを追加し、計装にはコード変更やコンテナ修正が必要でした。eBPFはカーネルからすべてを行います——アプリケーション変更はゼロです。
eBPFとは何か、なぜ重要なのか
eBPF（extended Berkeley Packet Filter）は、カーネルソースコードの変更やカーネルモジュールのロードなしに、サンドボックスプログラムをLinuxカーネル内で実行できる技術です。元々ネットワークパケットフィルタリング用に設計されたeBPFは、汎用カーネルプログラマビリティフレームワークに進化しました。
仕組み
- 小さなプログラムを書く——CまたはRustで（または高レベルフレームワークを使用）
- カーネルフックポイントにアタッチ——システムコール、ネットワークイベント、トレースポイント、関数エントリ/エグジット
- カーネルのeBPF検証器がプログラムの安全性を確認（無限ループなし、範囲外アクセスなし、有界実行）
- JITコンパイラがeBPFバイトコードをネイティブマシン命令に変換
- プログラムが実行——フックポイントでほぼネイティブのパフォーマンスで
オブザーバビリティにおいて、これはすべてのHTTPリクエスト、DNSルックアップ、TCP接続、ファイルシステム操作、プロセス実行を傍受できることを意味します——アプリケーションコードの修正なし、sidecarの注入なし、podの再起動なし。
// HTTPリクエストを追跡するシンプルなeBPFプログラム
SEC("kprobe/tcp_v4_connect")
int trace_connect(struct pt_regs *ctx) {
struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
u32 pid = bpf_get_current_pid_tgid() >> 32;
u16 dport = sk->__sk_common.skc_dport;
u32 daddr = sk->__sk_common.skc_daddr;
struct event_t event = {
.pid = pid,
.dport = ntohs(dport),
.daddr = daddr,
.timestamp = bpf_ktime_get_ns(),
};
bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
&event, sizeof(event));
return 0;
}
なぜオブザーバビリティに重要なのか
従来のオブザーバビリティには計装が必要です。このアプローチには3つの根本的な問題があります：
- リソースオーバーヘッド——各sidecarがCPUとメモリを消費。Envoy sidecarを持つ500 podクラスターでは、sidecar自体がクラスター総リソースの30-40%を消費する可能性。
- カバレッジギャップ——計装したものしか観察できない。サードパーティバイナリ、カーネルレベルイベント、ネットワークインフラはブラインドスポットのまま。
- メンテナンス負担——すべての言語、フレームワーク、ランタイムに固有の計装ライブラリが必要。
eBPFは3つすべてを解決します：カーネルで実行（アプリケーションオーバーヘッドゼロ）、カーネルが見るすべてを見る（ギャップなし）、アプリケーションの言語やフレームワークに関係なく動作。
2026年のeBPFオブザーバビリティスタック
Cilium + Hubble：ネットワークオブザーバビリティ
CiliumはKubernetesの事実上のCNI。Hubbleは以下を提供：
- L3/L4フロー可視性——pod間のすべてのTCP/UDP接続
- L7プロトコルパーシング——HTTP、gRPC、Kafka、DNS、PostgreSQL（アプリ変更不要）
- ネットワークポリシー監査——リアルタイムでトラフィックを許可/拒否するポリシーの確認
- サービス依存関係マッピング——観察されたトラフィックパターンに基づくサービスグラフの自動生成
Pixie：アプリケーションパフォーマンスモニタリング
Pixie（CNCFサンドボックスプロジェクト）はeBPFでゼロ計装APMを提供：
- 自動プロトコルトレーシング——HTTP/1.1、HTTP/2、gRPC、PostgreSQL、MySQL、Redis、Kafka、DNS
- 継続的CPUプロファイリング——eBPFスタックトレースからのフレームグラフ
- ダイナミックロギング——再デプロイなしで実行中アプリにトレースポイントを追加
- フルボディリクエスト/レスポンスキャプチャ——実際のHTTPヘッダー、SQLクエリ、gRPCペイロードを確認
Tetragon：ランタイムセキュリティと監査
Tetragon（Isovalent/Cilium製）はeBPFベースのセキュリティオブザーバビリティツール：
- プロセス実行追跡——すべてのexec、fork、exitイベント
- ファイルアクセス監視——読み取り、書き込み、権限変更の追跡
- ネットワーク接続監査——プロセスコンテキスト付きですべてのアウトバウンド接続をログ
- セキュリティポリシー適用——リアルタイムで不審な活動をブロック
Grafana Beyla：自動計装
Grafana BeylaはeBPFベースの自動計装エージェント：
- カーネルレベルでHTTP、gRPC、SQL、Redisリクエストを検出
- トレースコンテキスト伝播付きのOpenTelemetryスパンを送出
- Grafana Cloud、Tempo、Mimir、任意のOpenTelemetryバックエンドと統合
パフォーマンス：重要な数字
500 pod本番Kubernetesクラスターからの実世界ベンチマーク：
メモリ使用量比較
| コンポーネント | Sidecarアプローチ | eBPFアプローチ | 節約 |
|---|---|---|---|
| Envoy sidecar（500 pod） | 50 GB | 0（Cilium CNI） | 50 GB |
| OTel Collector sidecar（500 pod） | 15 GB | 0（Beyla DaemonSet） | 15 GB |
| Ciliumエージェント（20ノード） | N/A | 8 GB | -8 GB |
| Beylaエージェント（20ノード） | N/A | 2 GB | -2 GB |
| 合計 | 75 GB | 12 GB | 84%削減 |
CPUオーバーヘッド
| 指標 | Sidecarアプローチ | eBPFアプローチ |
|---|---|---|
| リクエストあたりの追加レイテンシ | 1-5ms | <0.1ms |
| ノードあたりのCPUオーバーヘッド | 8-12% | <1% |
| テールレイテンシ影響（p99） | +15-30ms | <1ms |
移行ガイド：SidecarからeBPFへ
フェーズ1：Sidecarと並行してeBPFツールをデプロイ（第1-2週）
- CiliumをCNIとしてインストール
- Hubbleをネットワークオブザーバビリティ用にデプロイ
- BeylaをDaemonSetとしてデプロイ
- sidecarとeBPFオブザーバビリティを並行運用
フェーズ2：検証とチューニング（第3-4週）
- eBPFツールが同じシグナルをキャプチャすることを確認
- Beylaのプロトコル検出を調整
- 既存のsidecarダッシュボードをミラーリング
フェーズ3：Sidecarの段階的削除（第5-8週）
- 非クリティカルなサービスから開始
- データ品質の回帰を監視
- 高度なトラフィック管理が不要なサービスからEnvoy sidecarを削除
フェーズ4：完全なeBPFスタック（第9-12週）
- 残りのsidecarを削除
- Tetragonをランタイムセキュリティ用にデプロイ
- eBPF由来のシグナルにアラートを統合
- 解放されたリソースを回収
よくある質問
eBPFオブザーバビリティはKubernetes以外のワークロードでも動作しますか？
はい。eBPFはLinuxカーネルレベルで動作するため、コンテナ、VM、ベアメタル、systemdサービスなどあらゆるワークロードで動作します。
eBPFは分散トレーシングを置き換えられますか？
多くのチームにとってはい。ただし、eBPFトレースはリクエスト/レスポンス境界に限定されます。関数内のカスタムビジネスロジックのトレースにはSDK計装が依然として必要です。
暗号化トラフィック（TLS）はどうですか？
eBPFツールはTLSライブラリ関数（OpenSSLのSSL_readやSSL_writeなど）にアタッチすることでTLSトラフィックをトレースできます。
eBPFは安全ですか？バグのあるeBPFプログラムがカーネルをクラッシュさせますか？
いいえ。eBPF検証器がロード前にすべてのプログラムをチェックします。バグのあるプログラムはロードに失敗しますが、カーネルをクラッシュさせることはありません。
eBPFは高スループットサービス（100K+リクエスト/秒）にどう対応しますか？
eBPFはカーネル内集約とサンプリングで高スループットに対応します。