Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Dapper
Search
a2-ito
May 17, 2022
Technology
0
52
Dapper
a2-ito
May 17, 2022
Tweet
Share
More Decks by a2-ito
See All by a2-ito
Organizations と Identity Center を Terraform で管理しよう
a2ito
0
62
App Runner 実践
a2ito
0
470
Bigtable
a2ito
0
63
Chord
a2ito
0
50
Chubby
a2ito
0
66
Dynamo
a2ito
0
69
Megastore
a2ito
0
54
Monarch
a2ito
0
59
Numbers everyone should know
a2ito
0
69
Other Decks in Technology
See All in Technology
Apache Iceberg Case Study in LY Corporation
lycorptech_jp
PRO
0
320
入門 PEAK Threat Hunting @SECCON
odorusatoshi
0
150
OPENLOGI Company Profile for engineer
hr01
1
20k
Visualize, Visualize, Visualize and rclone
tomoaki0705
9
83k
Active Directory攻防
cryptopeg
PRO
8
5.5k
MIMEと文字コードの闇
hirachan
2
1.4k
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
daiksy
14
5k
Two Blades, One Journey: Engineering While Managing
ohbarye
4
2k
OCI Success Journey OCIの何が評価されてる?疑問に答える事例セミナー(2025年2月実施)
oracle4engineer
PRO
2
150
Aurora PostgreSQLがCloudWatch Logsに 出力するログの課金を削減してみる #jawsdays2025
non97
1
200
スキルだけでは満たせない、 “組織全体に”なじむオンボーディング/Onboarding that fits “throughout the organization” and cannot be satisfied by skills alone
bitkey
0
180
株式会社Awarefy(アウェアファイ)会社説明資料 / Awarefy-Company-Deck
awarefy
3
11k
Featured
See All Featured
How GitHub (no longer) Works
holman
314
140k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Raft: Consensus for Rubyists
vanstee
137
6.8k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Code Review Best Practice
trishagee
67
18k
Unsuck your backbone
ammeep
669
57k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
Producing Creativity
orderedlist
PRO
344
40k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
175
52k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Transcript
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 を開発者に公開したことは大きなポイントだった