# Tracezip: Efficient Distributed Tracing via Trace Compression ISSTA 2025(Proc. ACM Softw. Eng., Vol. 2, No. ISSTA, Article ISSTA019, July 2025)。[[Zhuangbin Chen]]([[Sun Yat-sen University]])、Junsong Pu(BUPT）、[[Zibin Zheng]]([[Sun Yat-sen University]])。DOI: 10.1145/3728888。 ## 概要 分散トレーシングにおけるトレースデータの伝送・保持オーバーヘッドを、サンプリングではなく**圧縮**で削減する初のオンラインシステム。スパン間に存在する大域的な冗長性（反復するキー・バリューペア群）を **Span Retrieval Tree (SRT)** というプレフィックスツリー型のデータ構造でサービス側において連続的に抽出し、スパンを「パス識別子＋ローカルフィールド」の軽量表現に変換する。バックエンド側では SRT を参照して完全なスパンを復元する。SRT のリストラクチャリング、辞書ベースのマッピング圧縮、差分同期メカニズムを含む。[[OpenTelemetry]] Collector 内に約 3,000 行の Go コードで実装済みである。 ## 動機と冗長性分析 分散トレーシングのデータ量は膨大で、Google は日量約 1,000TB の生トレースを生成し、Netflix は日量 20 億リクエスト以上を処理する。既存の対処は以下の 2 系統に限られていた。 - **ヘッドベースサンプリング**: リクエスト到着時に無差別に一部(例 1%)を選択。エッジケースを見逃す。 - **テールベースサンプリング**: 全リクエストをトレースした後に異常トレースのみを保持。収集・取り込みのオーバーヘッドが消えない。 著者らは [[Train-Ticket]]（41 マイクロサービス）および gRPC・Apache Kafka・Servlet・MySQL・Redis・MongoDB の 6 アプリケーションコンポーネントで 40GB 超のトレースを収集し、冗長性を定量化した。主な知見は以下のとおり。 1. **高い冗長性**: Train-Ticket の各サービスで約 70% のキー・バリューペアが高頻度で反復する（出現 1,000 回超）。Kafka のみメッセージキュー内容の混入でランダム性が高い。 2. **属性間の構造的冗長性**: OpenTelemetry のセマンティック規約（`network.local.address`、`network.peer.address` 等）によりキー名が名前空間を共有し、バリューも類似パターンを示す。 ## 手法: Span Retrieval Tree (SRT) ### 基本構造 SRT はプレフィックスツリー型の多分岐木で、各非葉ノードがキー・バリューペアを保持する。スパン名ごとに 1 つの葉ノードが存在し、その葉にはスパン固有(非圧縮)のキー群(**ローカルフィールド**: span\_id、parent\_id、タイムスタンプ等)を格納する。あるスパンは SRT の根から葉への 1 パスとして「綴り出せる」。パスに含まれる非葉ノードのキー・バリューペア群が複数スパンで共有される**ユニバーサルフィールド**である。 圧縮時、スパンは「パス識別子(短いハッシュ)＋ローカルフィールドの値」のみに変換される。 ### アルゴリズム(Algorithm 1) 1. 未知のスパン名 → 全キー・バリューペアをチェインして SRT の根に新パスを追加。 2. 既知のスパン名 → SRT を根から葉へ走査し、不一致のキー・バリューペアが現れた時点で残りをチェインして新分岐を追加。 3. 各深さのユニークノード数がしきい値 ψ を超えるキーは葉へ移動（ローカルフィールド化）。 4. キーをユニーク値数の昇順に並べ替え、SRT を最適構造にリストラクチャリング。 ### 最適化 - **SRT リストラクチャリング**: ユニーク値数の少ないキーを上位に配置し、同一深度の同値ノードを統合。ノード数を削減。 - **辞書ベースのマッピング圧縮**: SRT 内で反復するキー/バリューを `[0-9a-zA-Z]` の短い識別子に置換。キーのトークン分割(`.` / `_` でセパレート)で属性の構造的冗長性も除去。 - **差分同期メカニズム**: SRT/辞書の変更分のみをバックエンドに送信。バックエンド側は `{識別子: パス}` の逆引きマップを保持し、パスの追加/削除のみ反映。OpenTelemetry のバッチプロセッサと連携し、バッチ送出前に SRT 同期を完了させる。 ### 実装 OpenTelemetry Collector のエクスポータ(サービス側圧縮)とレシーバ(バックエンド側復元)に実装。ハッシュによるパス探索を O(1) で実現。Go の map 型を利用。 ## 実験結果 ### オープンソースシステム | システム | 生データ(MB) | Tracezip 単体 CR | gzip CR | Tracezip+gzip CR | 改善率 | |---|---|---|---|---|---| | Train Ticket | 21.0 | 4.05 | 10.90 | 16.26 | 33.0% | | gRPC | 3.08 | 5.31 | 18.91 | 22.81 | 17.0% | | Servlet | 9.36 | 6.46 | 18.50 | 23.64 | 21.7% | | Redis | 2.01 | 6.09 | 23.93 | 30.45 | 21.4% | | Kafka | 2.47 | 3.94 | 17.27 | 18.57 | 7.0% | Kafka はメッセージキューデータの混入で圧縮率が最も低い。Train Ticket はマイクロサービス間の呼び出しグラフが複雑でビジネスロジック情報が多く、汎用圧縮の短い窓長(gzip: 32KB)では捉えきれない大域的冗長性を SRT が補完し、改善幅が最大(30〜35%)になる。 ### Alibaba 本番トレース 26.15GB の本番トレースデータ（20,000 超のマイクロサービス）で評価。lzma 単体の圧縮率 8.52 に対し、Tracezip+lzma で 13.69(1.91GB)を達成。改善率は gzip 併用で 35.1%、bzip2 併用で 43.6%、lzma 併用で 37.8%。大規模で多様なトレースほど SRT の大域圧縮が効く。 ### オーバーヘッド - **空間**: ψ=1,000 で SRT+辞書の合計 2.56MB。性能改善は 33.8%。値分布が二極化するため ψ=10,000 でも大差なし。 - **スループット**: Train Ticket で約 8 倍向上(13.78→109.68 MB/s)。JSON シリアライズがボトルネックの環境で、Tracezip がシリアライズ前にデータ量を削減するため大幅に高速化する。gzip はシリアライズ後に適用されるため、圧縮不能フィールド(ID 等)の処理で CPU を浪費しスループット改善は限定的。 - **CPU**: Tracezip の CPU 利用率は非圧縮/gzip 設定の 20〜40%。 ## 位置づけ Tracezip はトレースサンプリングと**直交**する手法であり、サンプリングとの組み合わせが可能である。ヘッドベースサンプリングのカバレッジ低下や、テールベースサンプリングの収集オーバーヘッドを回避しつつ、より多くのリクエストをトレースできる。ログ圧縮(LogShrink、Logzip 等)のオフライン手法とも補完的で、バックエンドへの効率的な伝送後に適用できる。 ## 関連 - 概念: [[分散トレーシング]] / [[テレメトリ]] - エンティティ: [[OpenTelemetry]] / [[Train-Ticket]] / [[Zhuangbin Chen]] / [[Sun Yat-sen University]] - 関連 MOC: [[SRE - MOC]] ## 出典 - [[@2025__ISSTA__Tracezip - Efficient Distributed Tracing via Trace Compression|本ページ]] - 原本: [[.raw/papers/arxiv-2502.06318.pdf]] - リポジトリ: https://github.com/OpsPAI/TraceZip