DeepFlow: eBPFで計装レス計測を狙うApache-2.0の可観測性基盤

計装の負担を誰から取り除くのか

DeepFlowが解こうとしているのは、マイクロサービスとAIアプリの計測において、開発者がコードに計装を書き続ける負担である。READMEはゼロコード収集という表現で、eBPFを使ってメトリクス、分散トレーシング、リクエストログ、関数プロファイリングを取得すると説明している。対象は特定言語のアプリに限らず、ゲートウェイ、サービスメッシュ、データベース、メッセージキュー、DNS、NICまで含むと記載されている。

想定読者はDevOps/SREチームである。コードを書く側ではなく、障害時に「どのサービスのどのリクエストが遅いのか」を突き止める側だ。言語ごとのSDKを入れて回る運用は、多言語構成の現場では現実的でない。そこに手を入れずに済ませる、というのがこのプロジェクトの立ち位置になる。

AgentとServerに分かれた二層構成

Community EditionはAgentとServerの2コンポーネントで構成される。READMEの記述によれば、Agentは各K8sノード、レガシーホスト、クラウドホストで動作し、そのホスト上の全アプリケーションプロセスのAutoMetricsとAutoTracingのデータ収集を担う。ServerはK8sクラスタ内で動作し、Agentの管理、タグ注入、データの取り込みとクエリサービスを提供する。

この分離は運用上の意味を持つ。ノード側のAgentは収集に専念し、メタデータの解決やタグの付与はServer側に寄る。収集対象のホストを増やすときはAgentを追加し、タグ体系やクエリの一貫性はServer側で保つ。データフローとしては、Agentがノード上のプロセスとネットワークから信号を取り出し、ServerがクラウドリソースやK8sのラベル、アノテーション、CMDBの業務属性といったメタタグを注入したうえで保存し、SQL・PromQL・OLTPの各API経由で外部に返す、という流れになる。

SmartEncodingが圧縮するのはタグであって本体ではない

READMEはSmartEncodingについて、標準化・事前エンコードされたメタタグを全可観測性データに注入し、ClickHouseのString型やLowCard方式と比べてストレージオーバーヘッドを10分の1に抑えると主張している。ここで注意したいのは、圧縮の対象がタグである点だ。カスタムタグと可観測性データは別々に保存され、タグ側はほぼ無制限の次元とカーディナリティを持てる、と説明されている。

タグのカーディナリティが膨らむとクエリ性能が落ちる、というのは時系列ストアでよく起きる問題である。DeepFlowはタグを本体データから分離することで、タグを増やしてもクエリ体験を損なわない設計にしたと読める。ただし「ClickHouse比で10倍」という数値はプロジェクト側の主張であり、この記事の範囲では独立に検証できない。導入判断では、自分のタグ設計でどの程度の削減になるかを自環境で測る必要がある。

導入手順とエディションの選択

DeepFlowにはCommunity、Enterprise、Cloudの3エディションがある。READMEによればCommunity EditionはEnterprise Editionのコアコンポーネントで構成され、開発者向けと位置づけられている。Enterpriseは組織向けでチーム協業の問題を解くとされ、CloudはSaaSでベータ段階と記載されている。

Community Editionの導入手順はREADMEからデプロイメントドキュメント（ce-install/all-in-one）へ誘導されている。リポジトリ内で完結する手順として明示されているのはソースからのビルドで、agent/build.mdが参照先になる。つまり、パッケージを入れて終わりではなく、自環境のカーネルやK8sのバージョンに合わせてAgentをビルドする経路が用意されている。動作を試すだけならCommunity Demoが公開されており、READMEにはログイン用のアカウントとパスワードが記載されている。まずインターフェースとクエリの感触を確認し、その後に自クラスタへAgentを配る順序が現実的だ。

Wasmプラグインという拡張点とその代償

既知のプロトコル解析に加えて、独自プロトコル向けにWasmプラグインがサポートされている。標準のパーサが対応していない通信を自前で解釈させたい場合の逃げ道になる。トピックにもwasmが挙がっており、拡張機構として位置づけられていることが分かる。

ただし、これはゼロコードという売り文句の外側にある作業である。プラグインを書く以上、プロトコルの仕様を理解した人が必要になり、その保守も発生する。ゼロコードで済む範囲と、Wasmを書かないと届かない範囲は分けて考えるべきだ。前者だけで要件が満たせるなら導入価値は高いが、後者に踏み込むなら自作パーサを維持するコストを先に見積もることになる。

eBPFであることの制約と、向かない場面

eBPFはカーネル側の機能に依存する。READMEは収集の仕組みとしてeBPFを挙げているが、対応カーネルのバージョン範囲や、権限・セキュリティポリシーによって何が取れなくなるかについては、この記事で参照できる材料の中では確認できない。ここは導入前に自環境で確かめるべき空白である。

もう一つの制約は構成そのものだ。Agentを各ノードに常駐させ、Serverをクラスタ内で動かす前提なので、単一ホストの小規模アプリや、ノードに特権的なエージェントを置けない環境では過剰になる。プロファイリングについてREADMEは1%未満のコストと記載しているが、これもプロジェクト側の記載であって、ワークロードによって変わる類の数値である。CPU集約的な処理が中心のノードでは、導入後に自分で測る以外に確かめる方法はない。

PrometheusやOpenTelemetryとの役割の違い

比較対象として分かりやすいのはOpenTelemetryだ。OpenTelemetryはベンダー中立なAPIを提供し、アプリケーション側にSDKを組み込んでテレメトリを送出する。計装はアプリのコードと設定に属する。DeepFlowはこの逆で、アプリを変更せずカーネル側から信号を取り出す。READMEも謝辞でOpenTelemetryに触れており、対立するものではなく、DeepFlowがPrometheus、OpenTelemetry、SkyWalking、Pyroscopeのストレージバックエンドとして動作すると説明している。

つまり両者は置き換えの関係になりにくい。既にOpenTelemetryで計装済みのアプリがあるなら、そのデータの保存先としてDeepFlowを使い、計装されていない周辺の通信やインフラ層はeBPF側で拾う、という併用が設計の意図に沿う。逆に、アプリ内の詳細なビジネスロジックの計測が主目的なら、SDKを入れるOpenTelemetry側のアプローチのほうが素直である。

ライセンスと保守コストの見取り

ライセンスはApache-2.0で、リポジトリのバッジにも表示されている。Apache-2.0は商用利用を含む広い利用を許す条項を持つが、具体的な義務や特許条項の解釈は法務の領域であり、ここで助言はしない。Enterprise EditionとCloudが別に存在する以上、Community Editionで足りる範囲と、有償版でしか埋まらない範囲があることは前提として押さえておきたい。

保守の観点では、リリースが継続している点が材料になる。直近ではv7.2.0が2026年8月13日、v7.2.1が2026年8月27日、その前がv7.1で2026年3月25日となっており、マイナー更新が数か月間隔で続いている。Agentを各ノードに配る構成では、この更新をどう配るかが運用コストの中心になる。Server側のAPIとAgent側の互換性がどの範囲で保たれるかは、この記事で参照できる材料からは判断できない。アップグレード手順をドキュメントで確認し、検証環境でAgentとServerのバージョン差を試してから本番に広げる、という手順が現実的な線になる。

編集部の結論

採用を検討すべきなのは、既存コードに手を入れずにK8sとレガシーホストの通信を横断的に可視化したいDevOps/SREチームである。逆に、単一ホスト上の小規模なアプリだけを対象にする場合や、カーネル側の制約を調整できない環境では、Agentを各ノードに常駐させる構成自体が過剰になる。最初に確認すべきは、対象ノードのカーネルがeBPFによるフックに対応しているか、そしてagent/build.mdに記載されたビルド手順で自環境のAgentを再現できるかである。

公式情報源

1. deepflowio/deepflow on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases