> [!abstract] 概要(Abstract の日本語訳) > 現代のインターネットシステムは多様なアプリケーション(例: DNS・Web・データベース)を組み合わせ、異なる管理ドメインにまたがり、トンネル・VPN・NAT・オーバーレイといったネットワーク機構のもとで動作する。このような複雑なシステムの診断は非常に困難である。多くの診断ツールが存在するが、それらは特定の層(例: traceroute)またはアプリケーションに特化しており、サービス動作の総合的な視点を再構成するツールはこれまでなかった。本稿では X-Trace を提案する。X-Trace は、これを採用したシステムに対してそのような総合的な視点を提供するトレーシングフレームワークである。われわれは X-Trace を複数のプロトコルおよびソフトウェアシステムに実装し、DNS 解決・3 層構成のフォトホスティングウェブサイト・オーバーレイネットワーク経由のサービスという 3 つの実際の展開シナリオでその動作を論じる。 ## 論文情報 - タイトル: X-Trace: A Pervasive Network Tracing Framework - 著者: [[Rodrigo Fonseca]]・[[George Porter]]・[[Randy H. Katz]]・Scott Shenker・[[Ion Stoica]] - 所属: Computer Science Division, University of California, Berkeley - 媒体: NSDI '07 — 4th USENIX Symposium on Networked Systems Design & Implementation - 発表年: 2007 - URL: https://www.usenix.org/conference/nsdi-07/x-trace-pervasive-network-tracing-framework - プロジェクト URL(当時): http://xtrace.cs.berkeley.edu ## 概要 X-Trace は、複数のプロトコル層・複数の管理ドメイン(AD)にまたがるネットワークタスクの因果木(task tree)を再構成するトレーシングフレームワークである。クライアントが開始したタスクに一意のタスク識別子(TaskID)を埋め込み、パス上のすべての要素がこの識別子を次のホップへ伝搬する。各要素はローカルのレポートを生成し、オフラインでタスク木を再構成する。DNS・Apache・Postgres・I3 オーバーレイネットワーク・Chord DHT への実装を通じて 6 種の障害を検知した実験結果を示す。 ## 問題設定 - **入力**: ユーザーがリクエストを開始するインターネットサービス(DNS・HTTP・オーバーレイ等の複数層・複数 AD にまたがる) - **出力**: タスクの因果木(task tree)——そのタスクに起因したネットワーク操作の全集合を有向グラフで記述したもの - **前提条件**: ネットワークプロトコルのメタデータフィールド(HTTP 拡張ヘッダ・IP オプション・EDNS0 等)に X-Trace メタデータを埋め込める仕組みが必要 - **動機**: traceroute は IP 層しか見えず、HTTP 監視ツールは DNS/ルーティング問題を診断できない。既存の層・AD をまたぐ統一診断ツールが存在しない ## 提案手法 ### アーキテクチャ概要 X-Trace は 3 設計原則に基づく。 1. **インバンドのトレースリクエスト**: メタデータを実際のデータパスに乗せる(アウトオブバンドプローブは別経路をたどる恐れがあるため不適切) 2. **アウトオブバンドのレポート収集**: トレースデータはデータパスから切り離して送る(障害時にもレポートを回収でき、データパスのレイテンシに影響しない) 3. **要求者とレポート受信者の分離**: エンドユーザーが開始しても、各 AD は独自のポリシーでレポートを収集・保持・開示できる ### X-Trace メタデータ パケットやメッセージに埋め込まれるメタデータは以下のフィールドから構成される。 | フィールド | 必須 | 内容 | |---|---|---| | Flags | 必須 | TreeInfo・Destination・Options の有無を示すビット | | TaskID | 必須 | タスクを一意に識別する 4/8/12/20 バイトの整数 | | TreeInfo(ParentID, OpID, EdgeType) | 任意 | 因果木のエッジを記述する 3 タプル | | Destination | 任意 | レポートの送付先ネットワークアドレス | | Options | 任意 | 将来の拡張用 TLV ブロック | ### 伝搬プリミティブ 2 つのプリミティブだけで因果木全体を記述する。 - `pushNext()`: 同一層の次ホップへメタデータを伝搬する。HTTP プロキシが次のサーバへリクエストを転送する際などに使用。 - `pushDown()`: 現在の層から 1 層下へメタデータを伝搬する。HTTP が TCP を、TCP が IP を呼び出す際に使用。 いずれも `current.opID → next.parentID`、`unique() → next.opID`、エッジタイプ(NEXT/DOWN)を設定する。`unique()` は乱数で実装し、1 タスク内で一意性を保証する。 ### レポートインフラ - **libxtrreport**: C/Java/PHP で提供する薄いクライアントライブラリ。UDP ソケットでローカルの報告デーモン(xtrd)に送信 - **xtrd**: スレッドプール型デーモン。報告をキューから取り出し UDP/TCP/I3/OpenDHT/ローカル DB 等の宛先へ転送 - **パケットスニファ**: libpcap で IP/TCP を受動監視し、計装不可のデバイスに代わって報告 - **オフライン再構成**: レポートの EdgeType(NEXT/DOWN)でグラフを構築してタスク木を再現 ### プロトコル対応 HTTP/SIP/Email は拡張ヘッダで即時対応、DNS は EDNS0 OPT-RR で対応、IP は IP オプション(一部 AS で除去)、SQL はコメントとして埋め込み、Chord は並列コールパスを作成して対応。 ## 新規性 | 比較対象 | 限界 | X-Trace の違い | |---|---|---| | traceroute / SNMP / Netflow | 単一プロトコル・単一層に限定 | マルチ層・マルチ AD・マルチプロトコル統合 | | Pinpoint | J2EE ミドルウェアのみ | 任意のネットワーク層を横断 | | Magpie | 専門家によるスキーマ記述が必要 | 標準的な 2 プリミティブで自動記述 | | AND/Constellation | 推論ベースの相関(確率的) | 決定論的な因果木の記録 | | ARM | トランザクション層のみ・単一組織内 | ネットワーク全層・AD 横断 | | Splunk | ログの検索ツール(因果接続の保証なし) | インバンドメタデータで因果接続を明示保証 | 特に「管理ドメイン横断」と「クロスレイヤー」の両立は従来手法にない特徴。 ## 実験設定 - **環境**: IBM Bladecenter ローカルテストベッド(1 AD 内) - **シナリオ 1(DNS+HTTP)**: カスタム .xtrace TLD、Java ブラウザ、EDNS0 対応 DNS クライアントライブラリ・再帰リゾルバ・権威 DNS サーバ 4 台、Apache ウェブサーバ - **シナリオ 2(フォトホスティング)**: Apache + PHP + Postgres、前面キャッシュ・ロードバランサ、Firefox 拡張・PHP/JavaScript 問題報告ライブラリ。約 200 アクセス/日、2 か月の実稼働 - **シナリオ 3(I3 オーバーレイ)**: I3/Chord プロトコルに X-Trace を追加、3 ノード I3 ネットワーク + SNP(Simple Number Protocol) - **性能テスト**: pushNext() のレイテンシ計測(64 ビット Intel P4 3.2 GHz)、Apache ベンチマーク(ab、10,000 リクエスト) ## 実験結果 - **pushNext() レイテンシ**: 平均 0.71 µs/576 バイトパケット(毎秒 140 万パケット超に相当) - **報告インフラのオーバーヘッド**: Apache の最大スループットが 764 req/s → 647 req/s に低下(**15% 低下**、平均レイテンシ 1.309 ms → 1.544 ms) - **報告ドロップ**: 10,000 リクエスト中 0 件 - **報告圧縮**: 10 倍の圧縮率を観測 - **障害検知**: 6 種の注入障害(PHP スクリプト異常・キャッシュ返却・ロードバランサ誤送信・受信ノードクラッシュ・ミドルボックスプロセスクラッシュ・ミドルボックスホストクラッシュ)をタスク木から正確に特定 ## 考察 - **15% スループット低下**は Postgres の報告ストアに起因する。報告ストア以外の計装オーバーヘッドはわずかで、事前の懸念より小さい - **部分展開の実用価値**: 単一プロトコルまたは単一 AD だけでも即時メリットがある。展開の広がりとともに「ネットワーク効果」が生じ価値が増す - **限界**: 1. プロトコルとデバイスの変更が必要。既存への後付けは難易度にばらつきがある 2. 部分展開では当該箇所の追跡が困難になる 3. レポートロストで偽陽性(データ欠落を障害と誤解釈)の可能性 4. 木構造前提のためランデブー型の合流を自然には捕捉できない 5. 状態破壊やオーバーロードCPUなど、経路記録だけでは根本原因に届かない事例が存在する ## 強み / 弱点・課題 **強み** - クロスレイヤー・クロス AD という当時の問題空間の「空白」を正確に定義し埋めた - 2 プリミティブ(pushDown/pushNext)という最小設計が既存システムへの適用を容易にする - 管理ドメインのポリシー独立性を設計に組み込んでいる - 部分展開でも即時価値を持つ段階展開モデルを採用 **弱点・課題** - 15% のスループット低下は本番適用の障壁になりうる(サンプリングやスコープ限定で緩和可能) - 木構造前提のため quorum 型プロトコルや収束型リクエストを捕捉できない - 展開に際してプロトコルとデバイスの変更が必要でハードルが高い - セキュリティ: リフレクション攻撃(X-Trace デスティネーションを第三者に向ける)への対処が課題 ## 関連 - 概念: [[分散トレーシング]] / [[トレースメタデータ伝搬]] / [[暗黙のコンテキスト伝搬]] - エンティティ: [[Rodrigo Fonseca]] / [[George Porter]] / [[Randy H. Katz]] / [[Ion Stoica]] / [[University of California, Berkeley]] - 後継研究: [[Jonathan Mace]] らの Canopy (SOSP 2017) / [[@2018__SoCC__Weighted Sampling of Execution Traces - Capturing More Needles and Less Hay]] / [[分散トレーシング]] 内の各研究 - 関連 MOC: [[SRE - MOC]] / [[AI Infra Telemetry - MOC]]