テールサンプリングの統計と希少異常の捕捉

なぜサンプリングが要るのか、そしてどこで決めるのか

分散トレーシングは1リクエストの経路を多数のスパンとして記録します（/devops/distributed-tracing/）。だが高トラフィックなサービスで全トレースを保存すると、ストレージとインジェスト帯域が爆発します。秒間数十万リクエストのトレースを丸ごと貯めれば、観測のコストが本番のコストを上回りかねない。そこで一定割合だけ残すサンプリングが要ります。

問題は「いつ・何を根拠に残すか」です。ここで二つの方式が分かれます。ヘッドサンプリングはトレースの開始時に「このトレースを残すか」を決めます。テールサンプリングはトレースが完了してから、収集した全スパンを見て決めます。この一見小さな違いが、希少な異常を捕まえられるかどうかを決定づけます。

ヘッドサンプリングの仕組みと本質的限界

ヘッドサンプリングは、トレースのルートスパン生成時にサンプリング判定を下し、その決定を sampled フラグとしてコンテキストに載せて下流へ伝播します（/devops/tracing-context-propagation/）。典型は確率的サンプリングで、トレースIDのハッシュを [0,1) に正規化し、それがサンプリングレート p 未満なら残す。

ヘッドサンプリング（確率的）
  p = 0.01                       # 1%を残す
  r = hash(traceID) / 2^k        # traceIDを[0,1)へ写像（決定的）
  sampled = (r < p)              # rがp未満なら残す
  # この判定を全サービスがtraceIDから再計算 → トレース全体で一貫

ハッシュを使う巧妙さは、どのサービスも同じ traceID から同じ判定を導ける点にあります。中央調整なしにトレース全体で残す/捨てるが一致し、決定はゼロに近いコストで下せて、スパンをバッファに溜める必要もない。これがヘッドサンプリングの最大の長所です。

ところが致命的な弱点があります。判定の時点では、そのトレースがエラーになるか高遅延になるかをまだ知らない。ルートスパンが始まった瞬間に、500ms後のタイムアウトや末端サービスの例外は予見できません。つまりヘッドサンプリングは結果と無関係なランダム抽出であり、エラーや高遅延が全体の0.1%しかない希少現象なら、その異常トレースも確率 p でしか残らない。

テールサンプリングの仕組みとコスト

テールサンプリングは判断をトレース完了後まで遅らせます。コレクタは到着するスパンを traceID ごとにバッファへ蓄積し、一定の待機時間（decision wait）が過ぎてトレースが出揃ったとみなしたら、全スパンを材料に残すかを決めます。判定ルールは結果を見て書けます——「いずれかのスパンが error なら残す」「ルートの所要時間が閾値を超えたら残す」「特定の customer.tier=premium 属性を含むなら残す」。

テールサンプリング（ポリシー評価）
  buffer[traceID].append(span)              # 完了まで溜める
  on decision_timer(traceID):               # decision wait経過
    t = buffer[traceID]
    if any(s.status == ERROR for s in t):  decision = KEEP   # 異常は全部残す
    elif root_duration(t) > 1s:            decision = KEEP   # 高遅延も残す
    else:                                  decision = (rand() < p_normal)  # 正常は間引く
    emit_or_drop(t, decision); free(buffer[traceID])

これで希少異常は確率1で残り、正常だけを p_normal で間引けます。ただし代償は二つあります。

第一にメモリ。完了までスパンを保持するので、バッファ常駐量 ≒ トレース到着率 × decision wait × 1トレースの平均スパン量。decision wait を長く取るほど遅いトレースも取りこぼさないが、メモリ常駐が増えます。待機中にメモリ上限を超えれば、判定前のトレースを溢れさせる（=取りこぼし）しかなく、完全性とメモリのトレードオフが生じます。

第二に集約（アフィニティ）コスト。判定には1トレースの全スパンが1か所に揃う必要があります。複数のコレクタにスパンが分散すると判定できないので、traceID で同一コレクタへ振り分ける必要がある（consistent hashing による trace-aware なルーティング）。このスパンの寄せ集めが、ステートレスに流せるヘッドサンプリングには無い運用負荷です。

バイアス付き抽出の統計：偏った標本から正しいレートを出す

テールサンプリングは「異常を高確率、正常を低確率で残す」バイアス付き抽出（biased / stratified sampling）です。便利ですが、素朴に保存済みデータを数えると統計が壊れます。エラーを100%、正常を1%で残した標本でエラー率を計算すると、エラーが過剰代表され、実際よりはるかに高いエラー率に見えてしまう。

正しく扱う鍵は、各トレースに残存確率の逆数の重みを与えることです。これは標本調査の Horvitz–Thompson 推定 に当たります。トレース i の残存確率を p_i とすると、その重みは w_i = 1 / p_i。母集団の総数や総量は、残った標本の重み付き和で不偏推定できます。

Horvitz-Thompson（残存確率の逆数で重み付け）
  各トレースに残存確率 p_i を記録（例 error=1.0, normal=0.01）
  重み w_i = 1 / p_i

  母集団のエラー総数の推定:
    Σ_{残ったerrorトレース} w_i        # error は p=1 なので w=1 → そのまま件数
  母集団の総リクエスト数の推定:
    Σ_{残った全トレース} w_i           # normal は w=100 で薄めた分を埋め戻す

  エラー率の推定 = (errorの重み付き和) / (全体の重み付き和)

直観はこうです。1%だけ残した正常トレース1本は「自分の背後に捨てられた99本がいる」とみなし、重み100で数える。100%残したエラーは重み1のまま。こうして間引きで歪んだ標本を、母集団スケールへ復元できる。重みを使えば偏った標本からでもエラー率・スループット・レイテンシ分布を不偏に再構成できます。逆に重みを記録し損ねると後から復元不能になるため、サンプリング側は各トレースに残存確率（または重み）を必ず付与して保存しなければなりません。

OpenTelemetry での実装位置と組み合わせ

OpenTelemetry では、ヘッドサンプリングは SDK 内の Sampler（TraceIdRatioBased や ParentBased）で生成側に、テールサンプリングは Collector の tailsamplingprocessor で収集側に置かれます（/devops/opentelemetry-internals/）。両者は排他ではなく併用が現実的です。SDK 側で明らかに不要な高頻度トレース（ヘルスチェック等）を軽くヘッドで落として帯域を削り、残りを Collector のテールで「異常を必ず残す」精緻な判定にかける、という二段構え。

ただし併用には落とし穴があります。ヘッドで捨てたトレースはテールに届かないので、ヘッド側でうっかり異常になり得るトレースまで間引くと、テールが幾ら賢くても復元できない。だから上流のヘッドは「結果に無関係で安全に捨てられるもの」に限定し、結果依存の重要度判定はすべてテールに委ねるのが原則です。

まとめ

• サンプリングはトレース単位で一貫して行う。スパンを部分的に捨てると因果が切れて無価値になる。
• ヘッドサンプリングは開始時に traceID から確率判定するため軽量・ステートレスだが、その時点で結果が未確定なので希少な異常（エラー・高遅延）を取りこぼす。
• テールサンプリングは完了まで全スパンを溜めてから重要度で残すので異常を確率1で捕捉できる。代償は decision wait 分のメモリ常駐と、traceID を同一コレクタへ寄せる集約コスト。
• decision wait は完全性とメモリのトレードオフを決める。短いと遅れて来るスパンを取りこぼし、長いとメモリが膨らむ。
• 異常優先の保存はバイアス付き抽出。各トレースに残存確率を記録し、その**逆数で重み付け（Horvitz-Thompson）**すれば、偏った標本から母集団のレートを不偏推定できる。重みを記録し損ねると復元不能。
• 実装は SDK のヘッドと Collector のテールを併用するのが現実的。ただしヘッドで結果依存の異常を間引かないこと——テールでは取り戻せない。