Slide 1

Slide 1 text

Dapper 2021.6.11 @a2ito

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Dapper user interface

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Dapper user interface パターンEの分布

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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