独自のeBPFセンサーを書かなかった理由
Beylaはすでにカーネルレベルのトレーシングという難しく、地味で、終わりのない部分を解決しています。それを作り直すことは、取り戻せない唯一のもの — 時間 — を犠牲にすることでした。
2026年6月23日 · 6分で読了
ランタイムエージェントは、アプリケーションに一切触れずに、サービスがどれだけ速く応答し、どれくらいの頻度で失敗するかを知る必要があります。 これはピッチデッキに書くには簡単な一文です。しかし、SDKもサイドカーも再起動もなしに、稼働中のプロセスからそれを取り出すのは全く別の問題であり、 エージェントを作り始めた最初の数週間、私たちはそれを自前で解決するつもりでいました。
計画は紙の上ではシンプルでした: TLSトラフィック用にSSL_write/SSL_readにuprobeを仕込み、 それ以外の通信にはtcp_sendmsgにkprobeを仕込み、HTTPとgRPCのフレーミングを小さなeBPFプログラムで解析し、 観測対象のプロセスに気づかれることなくRED指標(rate、errors、duration)を出力する — というものです。 シンプルなGo製HTTPサーバーに対するプルーフオブコンセプトは1週間もかからずに動きました。ところが、実際のSpring Bootサービスに向けた途端に壊れました。
実際に壊れる場所
eBPFのverifierで壊れるわけではありません — この部分は本当によく設計されていて、ループしたりクラッシュしたりしうるプログラムは、 実行されるずっと前にカーネルに拒否されます。壊れるのはユーザースペースとの境界、つまり誰もカンファレンストークで語らない部分です: uprobeのオフセットは、ライブラリの正確なビルドの関数として決まります。Ubuntu 22.04上のOpenSSL 3.0.2におけるSSL_writeのオフセットは、同じディストリビューションで6か月後のOpenSSL 3.0.13のオフセットとは異なり、 Alpineのmuslリンクビルドではまた別の数値になり、JVMがシステムのプロバイダーではなく組み込みプロバイダー経由で独自のTLSを行っている場合には さらに別の数値になります。これを言語ランタイムごと、コンテナベースイメージごと、クライアントが動かしているマイナーバージョンごとに掛け合わせると、 自分たちが制御できないカーネルに対して継続的な再導出とテストベンチが必要な、巨大なオフセット表が出来上がります。
これはリサーチの問題ではありません。永久に続くメンテナンスの問題であり、リリースしたら終わるものでもありません — OpenSSLのマイナーリリースひとつひとつが潜在的なリグレッションであり、それに気づくのは自分たちのCIではなく顧客からのSlackメッセージ経由になります。
代わりにBeylaを選んだ理由
Beyla(Grafana LabsのeBPF計装プロジェクト)は、私たちがクライアントごとに1つずつ発見していくことになるであろう同じ環境で、 カーネルとライブラリのドリフトを追いかけることをフルタイムの仕事にしている人々のコミュニティによって、 そのメンテナンス負担をすでにオープンな形で背負っています。観測対象のアプリケーションにコードを一切追加することなく、 サービスごとのRED指標 — リクエストレート、エラー率、p50/p99のレイテンシ — を提供してくれます。 おかげで、私たちは自分たちのeBPF予算を本当に自分たちのものである部分に費やす余裕ができました: procnetという独自のコレクターで、/proc/<pid>/net/tcpを読み取ってライブのTCP接続を コンテナにマッピングします — カーネル内でレイヤー7プロトコルを解析するよりもずっと狭く、ずっと安定した領域です。
この選択の正直なコストは、現在エージェントが1つではなく2つのコンテナとして配布されていることです — 私たちのコンテナと、 Beylaのコンテナで、どちらもホスト上で高い権限を持ちます。これは現在積極的に取り組んでいる摩擦ではあります (Beylaをエージェントバイナリの子プロセスとしてsupervisedな形でパッケージ化することが次のステップです)が、 動く標的に勝たなければならないエンジニアリングの賭けではなく、解決すべきUXの課題です。 私たちは、作っていないものを作ったかのように見せるよりも、この摩擦を正直に示すことを選びます。
最終的にたどり着いたルール
本当に自分たちの製品であるものを作る。私たちにとってそれはグラフです: 「orders service」というエンティティに、 Dockerfileから見ても、動いているコンテナから見ても、TCP接続から見ても同じアイデンティティを与えるエンティティ解決と、 ある依存関係が本物かどうかを判断する相関ロジックです。カーネルABIの境界にあるeBPFを、クライアントが動かしうるあらゆる言語、 あらゆるコンテナベースイメージにわたって扱うことは、すでに他の人々のフルタイムの仕事です — そして彼らはそれが得意です。
