# Network-Centric Distributed Tracing with DeepFlow ## 論文情報 - **著者**: Junxian Shen(清華大学・[[Yunshan Networks]])、Han Zhang(清華大学・Zhongguancun Laboratory、責任著者)、Yang Xiang([[Yunshan Networks]])ほか - **掲載**: ACM SIGCOMM 2023、2023 年 9 月 10 日、ニューヨーク - **DOI**: https://doi.org/10.1145/3603269.3604823 - **所属機関**: [[Tsinghua University]](清華大学 Institute for Network Sciences and Cyberspace・コンピュータサイエンス学科)、[[Yunshan Networks]](雲杉网络)、Zhongguancun Laboratory ## 概要(アブストラクト日本語訳) マイクロサービスは複雑化の一途をたどり、従来の性能監視ソリューションに新たな課題を突きつけている。一方ではマイクロサービスの急速な進化が既存の分散トレースフレームワークの利用・保守に大きな負担を強いており、他方では複雑なインフラがネットワーク性能問題の発生確率を高め、ネットワーク側に多くの盲点を生じさせている。本論文では、マイクロサービスのトラブルシューティングに向けたネットワーク中心の分散トレースフレームワーク [[DeepFlow]] を紹介する。DeepFlow はネットワーク中心のトレースプレーンと暗黙のコンテキスト伝搬によりすぐに使えるトレース(アウトオブボックストレース)を提供する。さらに、ネットワークインフラの盲点を排除し、低コストでネットワークメトリクスを取得し、異なるコンポーネント・レイヤー間の相関を強化できる。DeepFlow が無視できるオーバーヘッドでマイクロサービスの性能異常を特定できることを分析的・経験的に実証した。DeepFlow はすでに 26 社超で 71 件超の重大な性能異常を特定しており、数百人の個人開発者に利用されている。本番環境での評価では、ユーザーの計装作業を数時間節約し、トラブルシューティング時間を数時間から数分へと短縮できることが示された。 ## 問題設定 ### 背景 大規模オンラインサービスはモノリシックを離れ、マイクロサービスアーキテクチャに移行した。デカップリングによるスケーラビリティ・柔軟性・可用性の向上の反面、コンポーネント間インタラクションの複雑性が増し、性能デバッグが困難になった。 ### 課題 1. **既存の侵入型フレームワークの非効率**: 多言語・多バージョンカーネルの本番環境では、開発者が各コンポーネントに数十行の計装コードを手書きする必要があり、1 コンポーネントあたり数時間〜数日かかることがある。 2. **ネットワーク情報の欠落**: 既存のトレースフレームワークはネットワークインフラを無視し、アプリケーション層のトレースのみを記録する。26 社の顧客調査で、ネットワークインフラが性能問題の 47.3% の根本原因であることが判明した。 ### 新たな要件 26 社の顧客インタビューから 4 種のシナリオ(クロス部門デバッグ・オンラインゲーム運営・インフラサービス開発・アジャイル開発)を抽出し、利便性・移植性・安定性・カバレッジ・相関の 5 軸の要件を定義した。既存の侵入型/非侵入型フレームワークはいずれもこれらをすべて満たすことができない。 ### eBPF による機会 eBPF(extended Berkeley Packet Filter)はカーネル仮想マシンとして動作し、BPF プログラムをアプリの修正なしにオンザフライでロードできる。BTF(BPF Type Format)によりカーネルバージョンをまたいで移植可能であり、kprobe・トレースポイント・uprobe のような各種フックに接続できる。eBPF 検証器により安全性も保証される。 ## 提案手法: DeepFlow DeepFlow はエージェントとサーバーの 2 コンポーネント構成。エージェントはコンテナノード/VM/物理マシンに配置されトレースデータを取得する。サーバーはクラスタレベルでスパンをデータベースに格納し、クエリ時にトレースに組み立てる。 ### 設計 1: ネットワーク中心のトレースプレーン システムコールの ABI(アプリケーション・バイナリ・インターフェース)をインストルメンテーションポイントとして選択する。イングレス(recvmsg, recvmmsg, readv, read, recvfrom)とイグレス(sendmsg, sendmmsg, writev, write, sendto)の 10 種の ABI をフックし、ブロッキング/ノンブロッキング・同期/非同期の全通信シナリオをカバーする。これにより言語・カーネルバージョンを問わず単一のフレームワークで対応できる(狭腰モデル)。 ### 設計 2: カーネル内フックベース計装 kprobe とトレースポイントを利用し、システムコールのカーネル入口・出口でトレースデータを自動収集する。uprobe/uretprobe を追加的なインストルメンテーション拡張に利用する(例: TLS 暗号化前のオリジナルペイロード取得)。すべて自動実行でコード変更ゼロ。 ### 設計 3: 暗黙のコンテキスト伝搬 既存手法(明示的コンテキスト伝搬)はトレース ID・スパン ID をパケットのヘッダ/ペイロードに明示的に挿入する。DeepFlow は「コンテキスト伝搬に必要な情報がネットワーク関連データにすでに含まれている」という洞察に基づき、メッセージを変更しない。 - **スパン構築**: メッセージデータ生成 → プロトコル推論 → セッション集約の 3 フェーズ - **トレースアセンブル**: スレッド ID・時刻情報によるコンポーネント内関連付け、TCP シーケンスによるコンポーネント間関連付け、X-Request-ID によるクロスレッド関連付け、サードパーティ(OpenTelemetry 等)スパン統合の 4 手法を反復的に統合(アルゴリズム 1) ### 設計 4: タグベース相関とスマートエンコーディング Kubernetes リソースタグ(ノード/サービス/ポッド)、自己定義ラベル(バージョン/コミット ID)、クラウドリソースタグ(リージョン/AZ/VPC)をスパンに注入し、メトリクスとトレースを接続する。タグ注入をタグ収集フェーズとスマートエンコードフェーズに分割し、VPC/IP を Int 形式で中間保持することで計算・転送・ストレージのオーバーヘッドを大幅に削減する。 ## 実験設定 - **テストベッド**: Intel Xeon E5-2620 v3(2.40 GHz、12 物理コア)3 ノード Kubernetes クラスタ、RAM 128 GB、Ubuntu 20.04、カーネル 5.4.0 - **対象アプリ**: Spring Boot デモ(Jaeger デモ)、Istio Bookinfo アプリケーション - **比較対象**: Zipkin、Jaeger ## 実験結果 ### 計装オーバーヘッド 事前定義済み ABI へのレイテンシ追加: 277〜889 ns(ABI は入口フックと出口フックの両方をトリガー、DeepFlow の追加は各システムコールあたり最大 588 ns)。TLS uprobe などの拡張フックは最大 423 ns 追加(フック自体の内在コスト 6,153 ns に対し)。 ### スマートエンコーディングの効果 直接挿入比で CPU 4.31×、メモリ 1.97×、ディスク 3.9× を節約。低カーディナリティエンコーディング比でもストレージ 1.94×、メモリ 2.14×、CPU 7.79× を節約。 ### エンドツーエンド性能 - Spring Boot デモ: オーバーヘッド 7%(DeepFlow)、4%(Jaeger)——ただし DeepFlow は 1 トレースあたり 18 スパンを生成するのに対し Jaeger は 4 スパン - Istio Bookinfo: DeepFlow 4.5%(Zipkin は 3%)——DeepFlow は 38 スパン/トレース、Zipkin は 6 スパン ### クエリ遅延 単一トレース照会: 約 1 秒。15 分スパンリスト検索: 約 0.06 秒。 ### 本番実績 2 年間稼働、26 社超で 71 件超の重大性能異常を特定。Fortune Global 500 企業 10 社へのインタビューで、DeepFlow 導入前は 60% のユーザーが 1 コンポーネントの計装に数時間〜数日かけていたことを確認。 ## 考察 ### 主要な発見 - ネットワークインフラがマイクロサービス性能問題の 47.3% を占める。この事実が既存の「アプリ層だけをトレースする」フレームワークの根本的な盲点を示している - 非侵入型 + ネットワーク中心という組み合わせは eBPF なしでは実現困難であった。BTF によるカーネルバージョン間移植性が「1 フレームワークで全環境対応」を可能にした - 暗黙のコンテキスト伝搬は、TCP シーケンスがネットワーク転送で不変であることを利用しており、ネットワーク中心の計装があって初めて成立する ### 限界 - 現在の実装はメッセージキューのような 1 対多/多対多の通信パターン(ストリーミング・メッセージサブスクリプション)を対象外とする - クロスレッドコンポーネント内関連付けはメモリコピーやパラメータ転送など捕捉困難なケースを完全に処理できない(HAProxy・Envoy・Nginx の X-Request-ID に依存) - ゲートウェイのカバレッジにはトップオブラックスイッチのトラフィックミラーリングが必要 ## 強み・弱点・課題 **強み**: - ゼロコード計装: 既存サービスの再起動・修正・再コンパイル不要 - ネットワークカバレッジ: 物理ホストからサービスメッシュまでエンドツーエンドのトレース - 低オーバーヘッド: 7% 以下(スパン数は既存ツールの 4〜10 倍) - OSSおよびCNCF景観参加: Apache-2.0 ライセンスで公開 **弱点・課題**: - ストリーミング・パブサブモデルの非対応 - クロスレッド関連付けの不完全性(プロキシ依存) - TLS 非対応の閉鎖ソースコンポーネントはペイロード解析が制限される ## 関連 - プロダクト: [[DeepFlow]] / [[OpenTelemetry]] - 概念: [[分散トレーシング]] / [[eBPF]] / [[動的インストルメンテーション]] / [[テレメトリ]] / [[Fault Localization]] / [[根本原因分析]] / [[トレースサンプリング]] - 組織: [[Tsinghua University]] / [[Yunshan Networks]] - 人物: [[Junxian Shen]] / [[Han Zhang (DeepFlow)]] / [[Mingwei Xu]] - 関連 MOC: [[structures/分散深層学習 - MOC]] / [[structures/LLM4SRE - MOC]] ## 出典 - 本文全体 (ACM SIGCOMM '23, September 10, 2023, DOI: 10.1145/3603269.3604823)