> [!abstract] 概要 > 現代のインターネットサービスは、複雑かつ大規模な分散システムとして実装されることが多い。これらのアプリケーションは、異なるチームが異なるプログラミング言語で開発したソフトウェアモジュールの集合体であり、複数の物理施設にまたがる何千ものマシン上に展開されうる。このような環境において、システムの挙動を理解し性能問題を推論するためのツールは非常に価値が高い。本稿では、Google の本番分散システムトレーシング基盤である Dapper の設計を紹介し、低オーバーヘッド・アプリケーションレベル透過性・超大規模システムでの偏在展開という設計目標がどのように達成されたかを述べる。Dapper は Magpie や X-Trace などの他のトレーシングシステムと概念的な類似点を持つが、われわれの環境での成功に不可欠ないくつかの設計上の選択を行った。たとえばサンプリングの採用や、計装を少数の共通ライブラリに限定したことなどである。本稿の主目的は、Dapper の成功の主要な尺度がその開発・運用チームへの有用性にあることから、システムを 2 年超にわたって構築・展開・使用してきた経験を報告することである。 ## 論文情報 - **タイトル**: Dapper, a Large-Scale Distributed Systems Tracing Infrastructure - **著者**: Benjamin H. Sigelman, Luiz André Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan, Chandan Shanbhag - **所属**: Google - **媒体**: Google Technical Report dapper-2010-1 - **発表年**: 2010 年 4 月 - **DOI/URL**: https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ - **ページ数**: 14 ページ ## 概要 Dapper は、Google が 2008 年頃から本番稼働させた大規模分散システム向けのトレーシング基盤である。スレッドローカルストレージを活用したトレースコンテキスト伝搬と、RPC・スレッド制御フローライブラリへの計装の集中という 2 つの核心技術により、アプリケーション開発者がコードを変更しなくても Google 規模の分散システム全体を透過的にトレースすることを実現した。トレースを木構造のスパンとして表現し、Bigtable に格納する設計は、後のすべての分散トレーシング標準([[OpenTracing]]・[[OpenTelemetry]])の概念的基盤となった。 ## 問題設定 Google の universal search のような大規模分散サービスでは、1 ユーザーリクエストが数百のクエリサーバ・広告システム・スペルチェック・画像検索など多数のサブシステムに分散して処理される。エンジニアはどのサービスが使われているかを網羅的に把握できず、各サービスを管理するのはそれぞれ別のチームであり、さらにサービスやマシンは複数のクライアントが同時に共有している。この複雑な依存構造の中で性能問題の根本原因を特定することは、従来のツールでは困難だった。 **要件**: - **偏在展開(ubiquitous deployment)**: システムのごく一部でも監視されていないと、トレーシング基盤全体の有用性が著しく損なわれる - **継続監視(continuous monitoring)**: 異常なシステム挙動は再現不可能なことが多いため、常時 ON であることが必要 **3 設計目標**: 1. **低オーバーヘッド**: 性能影響が無視できるレベル。高度に最適化されたサービスでも展開チームがオフにしようとしない水準 2. **アプリケーションレベル透過性**: プログラマがトレーシングシステムを意識せずに済む。計装バグや漏れが偏在展開を損なわないようにするため 3. **スケーラビリティ**: 少なくとも数年間は Google の規模のサービス・クラスタに対応できること **追加目標**: トレースデータが生成後すぐ(理想的には 1 分以内)に分析可能であること。 ## 提案手法 ### アーキテクチャ Dapper のデータモデルは **トレース木(trace tree)**・**スパン(span)**・**アノテーション(annotation)** の 3 要素で構成される。 - **スパン**: トレース木の基本作業単位。スパン名・スパン ID・親 ID・タイムスタンプ付きイベント(開始・終了・RPC タイミング)を持つ。ルートスパンは親 ID を持たない。 - **トレース木**: ネストした RPC を木構造として表現。すべてのスパンは共通の 64 ビットトレース ID を共有する。 - **アノテーション**: アプリケーション開発者が任意のキー・バリューまたはテキストをスパンに付加できるオプト・イン機構。 ### 計装ポイント アプリケーションレベル透過性は、**少数の共通ライブラリへの計装集中**によって実現される: 1. **スレッドローカルストレージ**: トレースコンテキスト(トレース ID・スパン ID)をスレッドに紐付ける。制御フローがスレッドを跨ぐとき、Dapper がそのコンテキストをコールバックへコピーする 2. **コールバック・スレッドプール**: 非同期処理でも制御フローを追跡するため、Google の共通コールバック生成ライブラリを計装し、コールバックが作成者のトレースコンテキストを保持する 3. **RPC フレームワーク**: Google のすべてのプロセス間通信は単一 RPC フレームワーク上に構築されており、そこを計装してすべての RPC の前後にスパンを定義する。スパン ID・トレース ID はクライアントからサーバへ RPC ヘッダ経由で伝搬される この設計により、C++ と Java の混在環境でも言語横断的なトレースが可能になった。 ### サンプリング機構 全トレースを記録すると性能影響が顕在化するため、**2 段階サンプリング**を採用する: 1. **ランタイムサンプリング**: 実行時に一定確率でサンプリングを決定。初期実装は全プロセスで均一確率(平均 1/1024)だったが、低トラフィックサービスは重要イベントを見逃すという問題があった 2. **アダプティブサンプリング**: 均一確率でなく**単位時間あたりの目標サンプル数**でパラメタライズ。低トラフィックサービスは自動的にサンプリングレートを上げ、高トラフィックサービスは下げる 3. **コレクションサンプリング**: 中央リポジトリへの書き込みスループットを管理するため、コレクション層で追加的にサンプリング。トレース ID をハッシュして収集係数と比較し、スパン単位でなくトレース単位で採否を決定する Web サーチクラスタでの実測では、サンプリングレートが 1/16 未満だとレイテンシ・スループットへの影響が実験誤差の範囲に収まる(表 2)。1/1024 では高スループットサービスの大多数のユースケースに十分。 ### 収集パイプライン アウトオブバンド 3 段収集パイプライン: 1. スパンデータをローカルログファイルに書き込む 2. Dapper デーモンが全本番ホストからプル収集 3. 複数の地域 Dapper Bigtable リポジトリへ書き込む 収集レイテンシの中央値は 15 秒未満。インバンド収集でなくアウトオブバンドを選んだ理由: (1) トレースデータがアプリケーションデータに比べ過大になりネットワーク分析を歪める、(2) すべての RPC が完全にネストするとは限らない(中間層システムがすべてのバックエンドから応答を受け取る前にクライアントへ結果を返すことがある)。 ## 新規性 - **大規模本番展開の初報告**: 本論文は、大規模・本番稼働の分散システムトレーシング基盤を 2 年以上の実績とともに報告した最初の論文 - **アプリケーションレベル透過性の実証**: Pinpoint・Magpie・X-Trace などの先行研究では、計装には多かれ少なかれアプリケーション側の協力が必要だった。Dapper は共通 RPC・スレッドライブラリへの計装集中と、Google 環境のある程度の均質性を活かして、ほぼすべての本番プロセスが追加コードなしでトレース可能であることを実証した - **サンプリングの実用的整理**: 高スループットサービスで 1/1024 のサンプリングでも重要ユースケースに対応できることを実証し、アダプティブサンプリングによる低トラフィックサービスの問題を解決した - **プラットフォームとしての発展**: Dapper は自己完結的なトレーシングツールとして始まったが、API を公開した結果、設計者が予期しなかった多くの分析ツール・監視システムが有機的に生まれ、モニタリングプラットフォームへと発展した ## 実験設定 - **環境**: Google 本番クラスタ。2.2GHz x86 サーバ - **評価**: Web サーチクラスタを例として、異なるサンプリングレートにおけるレイテンシ(平均値、実験誤差 2.5%)・スループット(実験誤差 0.15%)の変化を計測(表 2) - **デーモン CPU 使用率**: 現実的でない重負荷ベンチマーク下で最大 0.3%/コア(表 1) - **ネットワーク負荷**: Google 本番環境ネットワークトラフィック全体の 0.01% 未満。1 スパンあたり平均 426 バイト ## 実験結果 **サンプリングレートと性能**: - 全量記録(1/1): 平均レイテンシ +16.3%、スループット −1.48% - 1/16: 平均レイテンシ +2.12%、スループット −0.08% - 1/1024: 平均レイテンシ −0.20%(誤差範囲内)、スループット −0.06% **展開状況**: - Dapper デーモンはほぼすべての Google 本番サーバにインストール済み(マシンイメージに組み込み) - 手動トレース伝搬が必要だったアプリは C++ 40 件・Java 33 件にとどまった(総数は数千) - 典型的な平日に約 200 名のエンジニアが Dapper UI を使用、週間で 750〜1000 の異なるユーザー **ユースケース実績**: - Google AdWords の Ads Review チームはレイテンシを 2 桁改善 - Universal Search のロングテールレイテンシ原因特定(クリティカルパス分析により、大半の遅いトレースが経路上でネットワーク性能低下を経験していることを発見) - サービス依存関係の自動推論(Bigtable テーブル名アノテーション + MapReduce で依存グラフを生成) - アプリケーション層のネットワーク使用量コンソール(2 週間以内に構築) ## 考察 - **高スループットサービスでの積極的サンプリングの妥当性**: 高スループットサービスで注目すべき実行パターンが一度でも現れれば、それは何千回も現れる。よってほとんどの分析に 1/1024 のサンプリングで十分である - **API 公開によるエコシステム効果**: トレースデータストアを単純なプログラミングインターフェースで開発者に開放したことにより、Dapper チームだけでは到底作れなかった多くの分析ツールが生まれた - **予期しなかったユースケース**: リソースアカウンティングシステム、機密サービスが規定の通信パターンに従っているかの検証、RPC 圧縮戦略の分析など、設計者が想定していなかった用途が生まれた ## 強み / 弱点・課題 **強み**: - RPC・スレッドライブラリのみを計装する設計により、アプリ開発者が意識しなくても機能する真のアプリケーション透過性 - アウトオブバンド収集と 2 段サンプリングで本番インパクトを最小化 - シンプルなデータモデル(スパン木 + アノテーション)が多様な分析用途を支える **弱点・課題**: - **コアレッシング効果**: バッファリングによる複数リクエストの一括処理では、単一トレース ID への帰属が困難 - **バッチワークロード**: MapReduce のようなオフラインワークロードへの対応が不十分。meaningful な作業単位(キー・シャード)をトレース ID と関連付ける必要がある - **根本原因特定の限界**: どのサービスが遅いかを特定できるが、その理由(例: 自分より先にキューに入った別のリクエストのせい)まで突き止めるには追加のアノテーションが必要 - **カーネルレベル情報との統合困難**: カーネルの詳細イベント(プロファイリング等)をユーザー空間のトレースコンテキストと紐付けることが難しい ## 関連 - ソース: 先行研究 — Pinpoint(Chen+ 2002)・Magpie(Barham+ 2004)・X-Trace(Fonseca+ 2007) - 後継ソース: [[@2021__J Grid Computing__Automated Analysis of Distributed Tracing - Challenges and Research Directions]] / [[@2022__IEEE ACCESS__A Survey on Observability of Distributed Edge & Container-Based Microservices]] / [[@2023__NSDI__Hindsight - Tracing Edge-Cases in Distributed Systems]] - エンティティ: [[Benjamin H. Sigelman]] / [[Luiz André Barroso]] / [[Mike Burrows]] / [[Pat Stephenson]] / [[Manoj Plakal]] / [[Donald Beaver]] / [[Saul Jaspan]] / [[Chandan Shanbhag]] / [[Google]] / [[OpenTracing]] / [[OpenTelemetry]] - 概念: [[分散トレーシング]] / [[トレースサンプリング]] / [[低オーバーヘッドインストルメンテーション]] / [[トレースコンテキスト]] / [[因果トレーシング]] - 関連 MOC: [[SRE - MOC]] / [[AI Infra Telemetry - MOC]] ## 出典 - Google Technical Report dapper-2010-1, April 2010(`.raw/papers/36356.pdf`) - §1 Introduction: 設計目標 3 点・universal search ユースケース・貢献のまとめ - §2 Distributed Tracing in Dapper: スパン/トレース木/アノテーションのデータモデル、計装ポイント 3 点、サンプリングと収集パイプライン - §3 Dapper Deployment Status: 展開状況・アノテーション利用統計 - §4 Managing Tracing Overhead: 表 1・2 の測定値、アダプティブサンプリング、2 段サンプリング - §5 General-Purpose Dapper Tools: Depot API・UI・DAPI 利用状況 - §6 Experiences: Ads Review・Universal Search・サービス依存関係・ネットワーク使用量・Firefighting - §7 Other Lessons Learned: 予期しなかったユースケースと限界 - §8 Related Work: Pinpoint・Magpie・X-Trace との比較