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
59
App Runner 実践
a2ito
0
460
Bigtable
a2ito
0
63
Chord
a2ito
0
49
Chubby
a2ito
0
66
Dynamo
a2ito
0
69
Megastore
a2ito
0
54
Monarch
a2ito
0
58
Numbers everyone should know
a2ito
0
69
Other Decks in Technology
See All in Technology
プロダクトエンジニア 360°フィードバックを実施した話
hacomono
PRO
0
140
Two Blades, One Journey: Engineering While Managing
ohbarye
3
970
デスクトップだけじゃないUbuntu
mtyshibata
0
670
偏光画像処理ライブラリを作った話
elerac
1
160
Classmethod AI Talks(CATs) #17 司会進行スライド(2025.02.19) / classmethod-ai-talks-aka-cats_moderator-slides_vol17_2025-02-19
shinyaa31
0
180
データエンジニアリング領域におけるDuckDBのユースケース
chanyou0311
7
2k
OpenID BizDay#17 KYC WG活動報告(法人) / 20250219-BizDay17-KYC-legalidentity
oidfj
0
450
コンテナサプライチェーンセキュリティ
kyohmizu
1
130
Raycast AI APIを使ってちょっと便利な拡張機能を作ってみた / created-a-handy-extension-using-the-raycast-ai-api
kawamataryo
0
190
OPENLOGI Company Profile for engineer
hr01
1
20k
「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly
i35_267
2
720
EDRの検知の仕組みと検知回避について
chayakonanaika
11
4.3k
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
91
5.9k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
10
500
The Art of Programming - Codeland 2020
erikaheidi
53
13k
The Pragmatic Product Professional
lauravandoore
32
6.4k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
We Have a Design System, Now What?
morganepeng
51
7.4k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
The Invisible Side of Design
smashingmag
299
50k
Code Review Best Practice
trishagee
67
18k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.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 を開発者に公開したことは大きなポイントだった