# トレースサンプリング ## 定義 トレースサンプリング（trace sampling）は、マイクロサービスシステムが生成する大量の分散トレースから、分析価値の高いトレースを選択的に保持する取り組み。大規模本番システムでは日に数百万〜数十億件のトレースが発生し、全量の保持・分析はコスト面で非現実的なため、サンプリングが不可欠となる。手法は大きく**ヘッドベースサンプリング**（トレース開始時に均一確率で採否を決定、Dapper/Jaeger/Zipkin が採用）と**バイアスサンプリング**（テールベース: トレース完了後に情報を用いて偏りのある採否を決定）に分かれる。バイアスサンプリングはさらに、トレースの多様性（エッジケース優先）に基づく手法（Sifter, Sieve, HC, SampleHST, TraceCRL）と、システムランタイム状態を加味する手法（[[TraStrainer]]）に分岐する。レトロアクティブサンプリング（Hindsight）は、トレースライフサイクルの早期段階で遅延取得を行い効率を高める別軸の発展である。(Source: [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]]) ## 横断的知見 - **Canopy(SOSP 2017)は Dapper のヘッドベースサンプリングを本番規模で運用した際の現実的妥協を初めて定量報告した**: [[@2017__SOSP__Canopy - An End-to-End Performance Tracing And Analysis System]] は Facebook の日次数十億リクエスト環境で、ヘッドベースサンプリングに加えて「コールパス 80% 打ち切り」「トレース保持ポリシーによる選択的保存」を導入した。Dapper([[@2010__Google__Dapper - A Large-Scale Distributed Systems Tracing Infrastructure]])が 1/1024 の均一サンプリングで全量の代表性を主張したのに対し、Canopy は深いコールパスの切り捨てというトポロジ次元の情報損失を許容する設計判断を取った。この「深さ方向の打ち切り」は後の Hindsight が指摘する「ヘッドベースサンプリングはエッジケースを見逃す」問題の別形態であり、Mint のトポロジ構造活用型圧縮と対照的——Canopy は深い構造を捨て、Mint は構造を保持して圧縮する。(Source: [[@2017__SOSP__Canopy - An End-to-End Performance Tracing And Analysis System]], [[@2010__Google__Dapper - A Large-Scale Distributed Systems Tracing Infrastructure]]) - **レトロアクティブサンプリングはテールサンプリングの「メモリ vs 品質」トレードオフを根本的に変える**: テールサンプリングは全スパンをメモリにバッファリングしてから採否を決定するため、品質は高いがメモリ・CPU・ネットワークコストが高い。[[Retroactive Sampling]]はサンプリング判断用の最小属性（33 バイト）のみ中央へ送り、生スパンはエッジのオンディスク FIFO に積む。結果としてテールサンプリング比でメモリ・CPU・ネットワーク転送量を 60–70% 削減しつつ、テールベースの品質（全スパン情報に基づく判断）を維持する。(Source: [[VictoriaMetrics-KubeCon-EU-2026-Sampling|@2026__VictoriaMetrics Blog__KubeCon EU 2026 Retroactive Sampling]]) - **ディスクオフロードの成否は I/O パターンが決定する**: OpenTelemetry コミュニティが提案した Pebble（KVストア）ベースのディスク型テールサンプリングはメモリを 81% 削減するが CPU を 649% 増加させる。一方、レトロアクティブサンプリングの FIFO 設計は逐次アクセスでランダム I/O を避け、CPU コストも削減する。ディスクへのオフロードはアクセスパターンの設計次第で成否が分かれる。(Source: [[VictoriaMetrics-KubeCon-EU-2026-Sampling|@2026__VictoriaMetrics Blog__KubeCon EU 2026 Retroactive Sampling]]) ## 未解決の問い - サンプリング品質が下流分析（RCA）の精度を直接支配することが TraStrainer で示されたが、サンプラーと RCA 手法をエンドツーエンドで共同最適化する研究はあるか。現状はサンプリングと分析が分離したパイプラインである - TraStrainer はテールベースサンプリングのみを実装。レトロアクティブサンプリング（Hindsight）にシステムランタイム状態を組み合わせた場合の効率・品質のトレードオフは未検証 - システムランタイム状態の「異常度」を DLinear で評価しているが、メトリクスの分布ドリフトや季節性の変化に対するロバスト性は限定的に検証されたのみ - テスト済みの障害タイプは 7 種に限られる。より複雑な障害シナリオ（カスケード障害、部分的劣化）での有効性は未確認 - [[テレメトリ]] の「情報を絞る」課題との接続: サンプリングは計装層と分析層の間に位置するデータ削減の仕組みだが、計装層での削減（[[特徴量削減]]）や分析層での削減（LLM エージェントへのテレメトリ絞り込み）とどう協調すべきか ## 関連 - ソース: [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]] / [[VictoriaMetrics-KubeCon-EU-2026-Sampling|@2026__VictoriaMetrics Blog__KubeCon EU 2026 Retroactive Sampling]] - 概念: [[分散トレーシング]] / [[テレメトリ]] / [[根本原因分析]] / [[AIOps]] / [[特徴量削減]] / [[Scaling Telemetry Workloads]] / [[Retroactive Sampling]] - エンティティ: [[TraStrainer]] / [[VictoriaMetrics]] / [[VictoriaTraces]] / [[OpenTelemetry]] / [[Canopy]] / [[Dapper]] - 関連 MOC: [[SRE - MOC]] / [[LLM4SRE - MOC]] ## 出典 - [[@2024__FSE__TraStrainer - Adaptive Sampling for Distributed Traces with System Runtime State]]（§2.1 サンプリング手法の分類、§8 関連研究の体系化、§5 実験評価でサンプリング品質と下流 RCA 精度の関係を実証）