Dapper 2021.6.11 @a2ito

Publication Dapper, a Large-Scale Distributed Sytems Tracing Infrastructure Benjamin H. Sigelman, Luiz Andr´e Barroso, Mike Burrows, Pat Stephenson, Manoj Plakal, Donald Beaver, Saul Jaspan, Chandan Shanbhag Google Technical Report dapper-2010-1, April 2010

Dapper ● Google社内の分散トレーシングツール ● Dapper論文をベースにして作られたOSSたち ○ zipkin - by Twitter ○ jaeger - by Uber

Summary of contributions ● 分散システムのトレーシングに関する基本的な考え方は既存の論文と同様 ○ Pinpoint, Magpie, X-Trace ● プロダクション環境で何年も運用してきて何を経験し、どのようにプロダクトをイ ンクリメントしてきたか ● アプリケーション透過性 ○ ソフトウェアスタックの十分に低いレベルに限定される

Dapperの分散トレーシング ● 分散されたシステムのトレーシングでは、各サーバで 実行されたすべての実行情報を記録する必要がある ● トレースはすべての呼び出しと返却タイミングを記録 するもの ● Dapper trace は RPCをネストした tree 構造で構成さ れる

Trace trees and spans ● Dapper trace tree は、ノードは基本的なユニッ トである span である ● span id と parent id ● 全 span はtrace id に紐づく ● 全IDはユニークな 64bit integer

Span詳細 ● 2つ目の Helper.Call の各イベント ● fooというannotationを挿入 ● clock skew に注意 ○ クライアントはサーバーがリクエストを受信 する前に常にリクエストを送信し、サー バーの応答についてはその逆である

実装のポイント ● a trace context ○ span属性コンテナ ● C++/Java の RPC framework

Annotations ● 開発者はトレースにアノテーションを挿 入できる ○ 任意のコンテンツ ● key-value 形式もサポート

Trace collection ● 各spanは一度ローカルに保存され、その後中 央(googleだから、Bigtable)に送られる ● 中央値は15秒未満。98パーセンタイルは2分未 満。（数時間掛かるものもある） ● GoogleのエンジニアはリポジトリにAPI経由でも アクセス可能 ○ DAPI

Out-of-band trace collection ● out-of-band にロギングとトレーシングされる ● in-band collection では実現できない（RPCレスポンスヘッダを用いた実装） ○ アプリケーションのネットワークダイナミクスに影響が大きい ○ RPCがフルにネストしている前提になる

Dapper Runtime Library ● Dapper RPC ○ スパンの作成、サンプリング、ローカルディスクへのロギングなど ● アプリに含まれるので、修正が困難 ● C++ 1000行未満 ● Java 800行未満 ● key-value annotations 用には 500行のコードを加えている

トレース収集のオーバーヘッド ● Dapperデーモンプロセスのトレース収集のCPU使用率は極めて少ない ○ （1コアの）0.3%以上使われることはない ○ kernel のスケジューラにおいて priority を可能な限り小さくしている ● ネットワークリソースも非常にライト ○ 各スパンは平均426バイト ○ Google のプロダクション環境において 0.01% 未満になるように抑えている

プロダクションワークロードへの影響 ● サンプリングレートを変えながら本番ワークロード （Web search cluster）への影響を観察 ○ スループット影響は大きくないが、レイテンシへの影響が大きい ● 経験的には、high-volume なサービスは 1/1024 あれば十分

Dapper Depot API, DAPI ● トレースデータは regional Dapper repositories (Depots) に格納される ● Depot API, DAPI を使ってアクセスする ○ Access by trace id ○ Bulk access ■ MapReduce向け ○ Indexed access ■ よく使われるアクセスパターンに基づく ● 最もチャレンジング ■ 元々はホストマシンorサービス名だったが、最終的にはホストマシン、サービス名、タイム スタンプの複合インデックスとした

DAPI usage within Google ● DAPI使用分類 ○ Webアプリ ■ 3個 ○ コマンドラインツール ■ 8個 ○ on-off ツール ■ 15-20個 ○ それら以外はよくわからない

Dapper user interface

Dapper user interface サービスとタイムウィ ンドウを指定 +コストメトリック

Dapper user interface 実行パターン毎のパ フォーマンスサマリ ソートも可

Dapper user interface 特定の実行パターン の可視化（2で選択し たもの）

Dapper user interface パターンEの分布

Dapper user interface パターンEにおける各 サービスの振る舞い

Experiences Layered and Shared Storage Systems ● Google における多くのストレージシステムは、複数のレイヤで構成されており、 多くのユーザでシェアされている ● Bigtable は Chubby と GFS を両方使用している ○ Bigtable cell からのGFSトラフィックは、単一ユーザ or複数のユーザで使用されている可能性が あるが、GFSレベルでは、これら2つの異なる使用パターンの違いはわからない ● Dapper UIは、実行パターンをグループ化できるため、ユーザをランク付けでき る

Other Lessons Learned ● Google 社内利用での学び ○ Coalescing effects ■ トレースの処理単位を集約 ○ Tracing batch workloads ■ MapReduce のようなバッチワークロードにも有効 ■ バッチ用には意味のある単位に紐付ける　シャード IDなど ○ Finding a root cause ■ annotation を利用して、キューなどの具体的な情報を追加 ○ Logging kernel-level information ■ カーネルパラメータのスナップショットをスパンに紐付ける ■ 調査中とのこと

まとめ ● Googleの本番分散システムトレースプラットフォーム Dapper ● ほとんどすべてのGoogleのシステムに導入されており、アプリケーションレベル の変更を必要とせず、パフォーマンスに目立った影響を与えることなく、最大の ワークロードの大部分を追跡可能 ● Dapper trace repositories を開発者に公開したことは大きなポイントだった