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
サンプリングは統計学である: 数理的根拠に基づき、オブザーバビリティのコストと精度を両立する
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
ymotongpoo
July 12, 2026
150
4
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
サンプリングは統計学である: 数理的根拠に基づき、オブザーバビリティのコストと精度を両立する
SRE NEXT 2026での登壇資料です
https://sre-next.dev/2026/schedule/#slot090
ymotongpoo
July 12, 2026
More Decks by ymotongpoo
See All by ymotongpoo
Loadbalancing exporter internals
ymotongpoo
2
170
サンプリングは「作る」のか「使う」のか? 分散トレースのコストと運用を両立する実践的戦略 / Why you need the tail sampling and why you don't want it
ymotongpoo
4
290
生成AI時代の開発と運用 / Dev and Ops in Gen AI era
ymotongpoo
9
4.8k
生成AI時代にこそ求められるSRE / SRE for Gen AI era
ymotongpoo
12
11k
プロファイルとAIエージェントによる効率的なデバッグ / Effective debugging with profiler and AI assistant
ymotongpoo
1
1.9k
Goのビルドシステムの変遷 / The history of Go's build system
ymotongpoo
15
12k
今日から始めるpprof / Pprof workshop for beginners
ymotongpoo
8
9.7k
Amazon CloudWatchのメトリクスインターバルについて / Metrics interval matters
ymotongpoo
6
570
生成AI時代のSRE / SRE in Gen AI era
ymotongpoo
1
280
Featured
See All Featured
How to Ace a Technical Interview
jacobian
281
24k
How to Talk to Developers About Accessibility
jct
2
280
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.3k
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
410
The Language of Interfaces
destraynor
162
27k
First, design no harm
axbom
PRO
2
1.2k
It's Worth the Effort
3n
188
29k
Designing for Timeless Needs
cassininazir
1
270
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
75k
Agile that works and the tools we love
rasmusluckow
331
22k
Paper Plane (Part 1)
katiecoart
PRO
0
9.5k
4 Signs Your Business is Dying
shpigford
187
22k
Transcript
SRE NEXT 2026 July 11th, 2026 at 1135am Track A
Staff Developer Advocate, Grafana Labs 山口能迪 サンプリングは統計学である 数理的根拠に基づき、オブザーバビリティのコストと精度を両立する
山口 能迪(やまぐちよしふみ) Staff Developer Advocate Grafana Labs 専門領域 • オブザーバビリティ
• SRE @ymotongpoo
None
今日話すこと • なぜサンプリングは難しい意思決定なのか • サンプリングを統計学として捉える • サンプリングされたデータをどう読むべきか • いつ避け、いつ許容できるか •
まとめ
本セッションの対象範囲 前提: 分散トレースのサンプリング • 本セッションの内容はログにも共通する話 • ただコストとしては分散トレースの話が多いのでそこに絞る • 実装・仕様に関してはオープンソースやオープン標準を中心に話す ◦
OSS: OpenTelemetry ◦ 標準: W3C Trace Context
なぜサンプリングは難しい意 思決定なのか
「データを捨てて大丈夫か」という不安 これらの疑問に答えられるか • P99レイテンシーは信用できるのか • エラー率の監視精度は落ちないか • インシデント時の根本原因が辿れなくならないか • 不安のための全量保持を正当化できるか
Subheading goes here 「とりあえず 1% で」 Lorem ipsum dolor sit
amet, consectetur adipiscing elit sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
サンプリングはやむを得ない手段 全量保持ができればあらゆる解析が可能 仕方なくサンプリング 制約 なんとなくでボタンを押さないためには 数理的根拠が必要
何を、どの精度で知りたいのか
サンプリングを 統計学として捉える
標本誤差を直感的に理解する 味見=サンプリング 鍋全体の味を知りたい • 最も正確に知るには全部食べる • それは本末転倒なので味見 どの精度で知りたいのか
標本サイズが精度を決める 95%信頼区間 : 標本比率(例: エラー率) : 標本サイズ 1.96 : 95%信頼水準の係数 100回標本を作成して標本比率を
計算したら95%の確率で母比率 ±1.96σの間に入る
計算例 1,000 req/s でエラー率 1% のとき • 1秒窓だと不安定 • 5分窓にすると標本は300倍
サンプリング率 標本/秒 95% CI 100% 1,000 ±0.62pp 50% 500 ±0.87pp 10% 100 ±1.95pp 1% 10 ±6.17pp 10%サンプリングでも 5分窓なら30,000標本得られる
必要な精度から逆算する サンプリング率の決定=結果 サンプリング率決定の手順 1. 許容できる誤差を決める 2. 必要な標本数が決まる 3. 必要なサンプリング率が決まる :
標本比率(例: エラー率) : 許容誤差 1.96 : 95%信頼水準の係数 → 次のスライドで計算例
計算例 エラー率 1%、許容誤差 0.5pp の場合 つまり必要なサンプル数は 1522 1,000req/sで5分窓なら、必要なサンプリング率は 0.5%
じゃあ許容誤差は どうやって決めるのか?
SLO から逆算する エラーバジェットが許容誤差を決める 概ねエラーバジェットの1/2 〜 1/4 が目安 例: 成功率のSLO 99.9%の場合
1%サンプリングだと SLO違反検知に不足 ①エラーバジェット 0.1% ②許容誤差 0.05pp ③必要サンプル数 ④1000req/sで5分窓 必要なサンプリング率
平均、エラー率、 P99の推定の難しさ 指標の性質 集約窓を広げれば精度改善 • 平均値: 中心極限定理で安定 • エラー率(比率): 信頼区間を計算可能
10件の標本でP99を語ること自体が無意味 • P50/P99: テイルの標本数に依存 • 低頻度イベント: 確率的に補足不可 扱いやすい 難しい
サンプリングされたデータを どう読むべきか
データの読み方を変える サンプリング後は「推定値」 サンプリングしたら観測値ではない • 10%サンプリング後の標本10,000は実態10,000リクエストではない • count() や rate() をそのまま計算すると実態の1/10
• 均一サンプリングであれば比率(エラー率など)は不変 • しかし動的サンプリング では前提が崩れる
Adjusted Count(重みによる調整) 各スパンは母集団の何件を代表するか サンプリング率 で残ったスパンの重みは となる • 10%サンプリング→重み 10 • 2%サンプリング→重み 50
動的サンプリングではスパンごとに重みが異なるので、集計時にこの重みを掛 けて母集団を復元する → 統計学で Horvitz-Thompson推定量 と呼ばれる
不均一サンプリングでの考慮事項 エラー100% + 正常系 5% のエラー率を考える よくある設計: エラーは全量保持、正常系は5% • 単純集計するとエラー率が実態より大幅に大きく見える
• 正常系1件 = 母集団20件、エラー1件 = 母集団1件 重み付けなしの count() は誤ったSLIを返す → Horvitz-Thompson推定量で重み付けすることで母集団に近い復元
サンプリング後の値を正しく読むための設計 「推定値として読める状態」を設計する 補正には各スパンの最終的な保持確率が必要だが、多段サンプリングで確率 情報が失われがち 必要な設計は2つ 1. 保持確率をパイプライン全体で伝搬・保持する → 個々のトレースから量的な影響を推測する場合 2.
SLIはそもそもサンプリング前に作る → 事前にわかっているメトリクス App SDK ヘッド サンプリング OTel Collector 確率的 サンプリング Backend Tempo × 50% × 20% = 10%
probabilistic sampler プロセッサー Consistent Probability Sampling W3C Trace Context の
tracestate ヘッダーで rv と th を伝搬・保持 • rv (random value): トレースIDから導出されるトレース全体で不変な値 • th (threshold): 保持確率を表現、前段までの閾値を表す絶対値 これにより格段が互いの設定を知らない多段サンプリングでも整合性が保たれる バックエンドは th から adjusted_count を算出 App SDK ヘッド サンプリング OTel Collector 確率的 サンプリング Backend Tempo ot=rv:0.37;th=2 th=2 → 50%保持 ot=rv:0.37;th=4 th=4 → 25%保持 adjusted_count = 4(保持率25%) 注: 便宜上otヘッダの中身を読みやすくしている。 実際は56ビットで表現されている。
probabilistic sampler プロセッサー Consistent Probability Sampling の注意点 最初から最後まで全コンポーネントが対応する必要あり App SDK
ヘッド サンプリング OTel Collector 確率的 サンプリング Backend Tempo otヘッダーなし 50%保持 何パーセントに調整 していいか不明
spanmetricsコネクター メトリクスとトレースの責務分離 サンプリングする前に全量スパンからRED指標を⽣成 メトリクスは全量からの計算で正確なので重み考慮しなくてよい App SDK 全量スパン送信 OTel Collector spanmetrics
tail_sampling Mimir Tempo サンプリング済 全量メトリクス
許容可否の判断
サンプリング可否のチェックリスト サンプリンクの判断のフレームワーク • 低頻度かつ重大 (不正利用、決済失敗) • 母数が少なく標本数を確保できない • 完全な因果関係が調査に必須 •
規制や監査で完全性が必要 • ⼗分なトラフィック(数百 req/s 以上) • ⽬的が全体傾向の把握 • spanmetricsで集約値は全量保証 • 必要精度が事前に⾒積もれる 避けるべきケース 許容できるケース
まとめ サンプリング率は結果 「なんとなく 1%」から「説明できる 1%」へ 1. そもそも、このデータは捨てて良いのか 2. この指標を、どの時間窓で、どの精度で 知りたいのか
3. そのために必要な標本数はいくつか 4. その標本数を確保するには、どのサンプリング率 が必要か
参考文献 https://amzn.to/4ftOIRw https://amzn.to/3SMdzaB