Dapper

Transcript

1. Dapper 2021.6.11 @a2ito
2. 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
3. Dapper • Google社内の分散トレーシングツール • Dapper論文をベースにして作られたOSSたち ◦ zipkin - by Twitter ◦ jaeger - by Uber
4. Summary of contributions • 分散システムのトレーシングに関する基本的な考え方は既存の論文と同様 ◦ Pinpoint, Magpie, X-Trace • プロダクション環境で何年も運用してきて何を経験し、どのようにプロダクトをイ ンクリメントしてきたか • アプリケーション透過性 ◦ ソフトウェアスタックの十分に低いレベルに限定される
5. Dapperの分散トレーシング • 分散されたシステムのトレーシングでは、各サーバで 実行されたすべての実行情報を記録する必要がある • トレースはすべての呼び出しと返却タイミングを記録 するもの • Dapper trace は RPCをネストした tree 構造で構成さ れる
6. Trace trees and spans • Dapper trace tree は、ノードは基本的なユニッ トである span である • span id と parent id • 全 span はtrace id に紐づく • 全IDはユニークな 64bit integer
7. Span詳細 • 2つ目の Helper.Call の各イベント • fooというannotationを挿入 • clock skew に注意 ◦ クライアントはサーバーがリクエストを受信 する前に常にリクエストを送信し、サー バーの応答についてはその逆である
8. 実装のポイント • a trace context ◦ span属性コンテナ • C++/Java の RPC framework
9. Annotations • 開発者はトレースにアノテーションを挿 入できる ◦ 任意のコンテンツ • key-value 形式もサポート
10. Trace collection • 各spanは一度ローカルに保存され、その後中 央(googleだから、Bigtable)に送られる • 中央値は15秒未満。98パーセンタイルは2分未 満。（数時間掛かるものもある） • GoogleのエンジニアはリポジトリにAPI経由でも アクセス可能 ◦ DAPI
11. Out-of-band trace collection • out-of-band にロギングとトレーシングされる • in-band collection では実現できない（RPCレスポンスヘッダを用いた実装） ◦ アプリケーションのネットワークダイナミクスに影響が大きい ◦ RPCがフルにネストしている前提になる
12. Dapper Runtime Library • Dapper RPC ◦ スパンの作成、サンプリング、ローカルディスクへのロギングなど • アプリに含まれるので、修正が困難 • C++ 1000行未満 • Java 800行未満 • key-value annotations 用には 500行のコードを加えている
13. トレース収集のオーバーヘッド • Dapperデーモンプロセスのトレース収集のCPU使用率は極めて少ない ◦ （1コアの）0.3%以上使われることはない ◦ kernel のスケジューラにおいて priority を可能な限り小さくしている • ネットワークリソースも非常にライト ◦ 各スパンは平均426バイト ◦ Google のプロダクション環境において 0.01% 未満になるように抑えている
14. プロダクションワークロードへの影響 • サンプリングレートを変えながら本番ワークロード （Web search cluster）への影響を観察 ◦ スループット影響は大きくないが、レイテンシへの影響が大きい • 経験的には、high-volume なサービスは 1/1024 あれば十分
15. Dapper Depot API, DAPI • トレースデータは regional Dapper repositories (Depots) に格納される • Depot API, DAPI を使ってアクセスする ◦ Access by trace id ◦ Bulk access ▪ MapReduce向け ◦ Indexed access ▪ よく使われるアクセスパターンに基づく • 最もチャレンジング ▪ 元々はホストマシンorサービス名だったが、最終的にはホストマシン、サービス名、タイム スタンプの複合インデックスとした
16. DAPI usage within Google • DAPI使用分類 ◦ Webアプリ ▪ 3個 ◦ コマンドラインツール ▪ 8個 ◦ on-off ツール ▪ 15-20個 ◦ それら以外はよくわからない
17. Dapper user interface
18. Dapper user interface サービスとタイムウィ ンドウを指定 +コストメトリック
19. Dapper user interface 実行パターン毎のパ フォーマンスサマリ ソートも可
20. Dapper user interface 特定の実行パターン の可視化（2で選択し たもの）
21. Dapper user interface パターンEの分布
22. Dapper user interface パターンEにおける各 サービスの振る舞い
23. Experiences Layered and Shared Storage Systems • Google における多くのストレージシステムは、複数のレイヤで構成されており、 多くのユーザでシェアされている • Bigtable は Chubby と GFS を両方使用している ◦ Bigtable cell からのGFSトラフィックは、単一ユーザ or複数のユーザで使用されている可能性が あるが、GFSレベルでは、これら2つの異なる使用パターンの違いはわからない • Dapper UIは、実行パターンをグループ化できるため、ユーザをランク付けでき る
24. Other Lessons Learned • Google 社内利用での学び ◦ Coalescing effects ▪ トレースの処理単位を集約 ◦ Tracing batch workloads ▪ MapReduce のようなバッチワークロードにも有効 ▪ バッチ用には意味のある単位に紐付ける　シャード IDなど ◦ Finding a root cause ▪ annotation を利用して、キューなどの具体的な情報を追加 ◦ Logging kernel-level information ▪ カーネルパラメータのスナップショットをスパンに紐付ける ▪ 調査中とのこと
25. まとめ • Googleの本番分散システムトレースプラットフォーム Dapper • ほとんどすべてのGoogleのシステムに導入されており、アプリケーションレベル の変更を必要とせず、パフォーマンスに目立った影響を与えることなく、最大の ワークロードの大部分を追跡可能 • Dapper trace repositories を開発者に公開したことは大きなポイントだった