# @2026__VictoriaMetrics Blog__KubeCon EU 2026 Retroactive Sampling VictoriaMetrics が KubeCon EU 2026 で発表した分散トレースのサンプリング最適化手法の解説記事。著者は[[Zhu Jiekun]]。[[OpenTelemetry]] エコシステム向けの**レトロアクティブサンプリング(retroactive sampling)**プロトタイプを紹介し、従来の[[トレースサンプリング|テールサンプリング]]と比較したベンチマーク結果を報告する。最終的にプロトタイプを OpenTelemetry Collector の新しいプロセッサとして寄贈し、[[VictoriaTraces]]（[[VictoriaMetrics]] 独自エージェント `vtagent`）に 2026 年下半期に統合する計画である。 ## 問題設定 ### 分散トレーシングの基礎 分散トレーシングはマイクロサービス間のリクエストフローをスパン(span)の木構造として可視化する。高スループット本番システムは GB/s 規模のトレースを生成し、帯域・CPU・メモリ・ストレージに大きな負荷をかける。 ### テールサンプリングのリソース課題 テールサンプリングはトレース完了後に全スパンを見て採否を決定できるため品質は高いが、以下の課題がある。 - **メモリ**: スパンを trace_id 単位でバッファリングする必要があり、ネットワーク遅延・不安定性に対応するために大きなウィンドウが必要 - **CPU・ロードバランシング**: 1 つのトレースの全スパンを同一コレクタに集める必要があるため、デーモンセット型エージェントまたはロードバランサが必須 - **ネットワーク帯域**: トレースの 100% をエクスポートした後にほとんどを破棄するため、クラウド間・リージョン間では大量のエグレスコストが発生する ## 提案手法: レトロアクティブサンプリング ### 基本アーキテクチャ 中央コレクタへ送る属性を最小化し、エッジエージェント側で生スパンをバッファリング。採択決定後に必要なスパンだけを取得する。 1. エージェントがサンプリング判断に必要な最小属性のみ抽出して中央コレクタへ送信（`trace_id` + `start_time` + `end_time` + `status_code` = **33 バイト**、フルスパン 1 KB+ と比較） 2. コレクタが全属性を分析してサンプリング判断を行う 3. コレクタが判断結果をエージェントへ伝達 4. エージェントがバッファ内のスパンを照合し、非採択スパンを破棄、採択スパンをストレージへ転送 ### オンディスク FIFO キューによるバッファリング最適化 メモリバッファをディスクの FIFO キューに置き換え、メモリ圧力をエッジへ転嫁せずに解消する。 1. キー属性を抽出してコレクタへ送信 2. スパンのバッチをバイナリ形式にマーシャリングし、タイムスタンプ付きブロックとして FIFO キューへ書き込み 3. バックグラウンドワーカーがタイムスタンプヘッダを読みながら FIFO を逐次消費 4. 設定した保持期間（例: 1 分）を超えたスパンに対し、採択された trace_id を照合して非採択は破棄、採択はストレージへ転送 インメモリの trace_id ルックアップテーブルを維持することで照合は高速に行い、FIFO への逐次アクセスで最適なディスク性能を確保する。 ## ベンチマーク結果 [[OpenTelemetry Demo]] を用いて 15,000〜30,000 スパン/秒の負荷を再生し、3 シナリオを比較。 | シナリオ | 設定 | |--------|------| | サンプリングなし（ベースライン） | エージェントがバッチ処理・エクスポートのみ | | テールサンプリング | OpenTelemetry Collector を中間に挿入 | | レトロアクティブサンプリング | カスタムサンプリングサーバ + レトロアクティブプロセッサ | **レトロアクティブサンプリングの改善幅（テールサンプリング比）:** | 指標 | 削減率 | |------|--------| | 圧縮後ネットワーク転送量 | **70%** | | CPU 使用率 | **60–70%** | | メモリ使用量 | **60–70%** | | ディスク使用量 | 1.7 GB（テールサンプリングの 4 GB メモリと比較） | ## 議論 ### 変形: ローカル + レトロアクティブサンプリング サンプリング判断を 2 種に分類できる。 1. **集約必須型**: 複数スパンの情報が必要（例: トレース全体のレイテンシ）→ 中央コレクタへ送信 2. **非集約型**: ローカル判断可能（例: エンドポイント値によるサンプリング）→ エージェントがローカルで判断し、採択 trace_id のみ伝達（1 バイトで表現可能） ### 比較: Pebble ベースのディスク型テールサンプリング OpenTelemetry コミュニティが提案したインメモリテールサンプリングを Pebble（KVストア）でディスクオフロードする手法との比較。 | 手法 | メモリ変化 | CPU 変化 | |------|----------|--------| | Pebble ベースのディスク型テールサンプリング | **81% 削減** | **649% 増加** | | レトロアクティブサンプリング（FIFO） | 60–70% 削減 | 60–70% 削減 | Pebble はランダム I/O が頻発するため CPU コストが急増する。レトロアクティブサンプリングの FIFO 設計はこの欠点を回避する。 ## 今後の計画 - プロトタイプを OpenTelemetry Collector の新プロセッサとして寄贈予定 - [[VictoriaTraces]] の `vtagent` に 2026 年下半期に OSS として統合予定 ## 起源 本手法の起源は NSDI 2023 論文 "The Benefit of Hindsight: Tracing Edge-Cases in Distributed Systems"（Lei Zhang ほか）。 ## 関連 - エンティティ: [[VictoriaMetrics]] / [[VictoriaTraces]] / [[OpenTelemetry]] / [[OpenTelemetry Demo]] / [[Zhu Jiekun]] - 概念: [[Retroactive Sampling]] / [[トレースサンプリング]] / [[分散トレーシング]] / [[Scaling Telemetry Workloads]]