トレースのスパンモデルと因果再構成

スパンとは何か：区間としての作業単位

分散トレーシングの最小単位は**スパン（span）です。スパンは1つの作業区間を表し、最低限の構成要素は決まっています。trace_id（同じリクエストに属する全スパンで共通）、span_id（このスパン固有のID）、parent_id（親スパンのID。根なら空）、開始時刻、終了時刻、そして名前と属性です。終了時刻から開始時刻を引いた値がそのスパンの所要時間（duration）**になります。

ここで誤解されがちなのは、スパンは「ログの一行」ではなく時間軸を持つ区間だという点です。点ではなく線分なので、スパン同士は「包含する／重なる／前後する」という関係を取りうる。トレースとは、この線分群を parent_id の参照で結んだ有向グラフにほかなりません。木構造で描かれることが多いのは、多くのスパンが親をちょうど1つだけ持つからですが、後述するようにファンインでは木に収まりません。

因果を運ぶのはコンテキスト伝播だけ

スパンが繋がる条件は、子が trace_id と「親の span_id」を知っていることです。これを実現するのが**コンテキスト伝播（context propagation）**で、プロセス内ではスレッドローカル等で、プロセス間ではHTTPヘッダ（W3C Trace Context の traceparent）やメッセージ属性で運ばれます。詳細はトレースコンテキスト伝播の仕組みに譲りますが、核心は次の一点です。

伝播が途切れた瞬間に因果も途切れる。 ヘッダを引き継がないプロキシ、コンテキストを捨てるスレッドプール、伝播を実装していないライブラリ境界——どれか1つでも欠けると、下流のスパンは親を見失い、parent_id が空のまま新しい根として記録されます。結果、本来1本だったトレースが複数の断片に割れる。これは「サンプリングで欠けた」のではなく「因果の鎖が物理的に切れた」状態で、後から繋ぎ直す手段はありません。

正しい伝播:
  service-A  [span_id=a1, parent=∅, trace=T] --traceparent--> HTTP
  service-B  [span_id=b1, parent=a1, trace=T]   # T と a1 を受信して繋がる

伝播の欠落:
  service-A  [span_id=a1, parent=∅, trace=T] --(ヘッダ落ち)--> HTTP
  service-B  [span_id=b9, parent=∅, trace=U]   # 新しい根。T とは別トレース扱い

child-of と follows-from：従属の2種類

スパン関係には2つの意味があり、ここを混同すると分析が壊れます。

child-of では、親スパンの時間区間は子スパンの区間を包含します。親は子の返事を待つので、子の所要時間は親の所要時間の一部です。一方 follows-from では、親は子の起動だけして自分は終了してよい。子は親より後に・親とは無関係に走るため、親の区間が子を包含するとは限らず、しばしば親の終了後に子が始まります。

この区別を取り違えると何が起きるか。fire-and-forget を child-of として記録すると、ツールは「親は子を待っている」と解釈し、本来は非同期で隠れていた子の時間を親の待ち時間に二重計上してしまう。逆に同期呼び出しを follows-from にすると、クリティカルパス上にあるはずの遅延が経路から外れて見落とされます。OpenTelemetry ではこれを SpanKind（CLIENT/SERVER/PRODUCER/CONSUMER/INTERNAL）と Link で表現します。実装上の詳細はOpenTelemetryの内部構造を参照してください。

非同期・ファンアウト・キューで因果が難しくなる理由

同期RPCだけの世界なら因果は素直です。難しくなるのは、親子が時間的にも空間的にもずれる場合です。

ファンアウト（fan-out）。 1つの親が N 個の子を並行起動する。各子は独立した child-of で、すべて親の区間に含まれます。問題は集約側で、N 個の結果を待ち合わせる処理です。親の所要時間に効くのは合計でも平均でもなく、最も遅く返ってきた子だけ。N が大きいほど、どれか1つが裾の遅延を引く確率が上がり、全体が引きずられます（テール遅延の合流）。

ファンイン（fan-in）。 逆に、複数の親に起因する処理が1点に合流する場合、そのスパンは親を複数持ちます。parent_id は1つしか書けないため、純粋な木では表現できません。OpenTelemetry はここでLinkを使い、「主たる親」を parent_id に、それ以外の起因を Link 配列に記録します。バッチ処理がその典型です。

メッセージキュー。 producer が投入してから consumer が取り出すまでに、秒〜分の時間差が空きます。両者は別プロセス・別時刻なので child-of ではなく follows-from（Link）で結ぶのが正しい。さらに consumer 側のスパンを producer の trace_id に属させるべきか、新しいトレースを起こして Link で繋ぐべきかという設計判断が生じます。前者は end-to-end の因果が1トレースで追える利点、後者はキュー滞留がトレース全体の所要時間を不当に膨らませない利点があります。キューの配信意味論そのものはメッセージキューの配信保証で扱います。

クリティカルパス抽出の原理

トレースが手に入っても、どこを速くすれば全体が速くなるかは自明ではありません。並行に走るスパンは何本あっても、最も遅い1本しか全体時間に効かないからです。ここで効くのが**クリティカルパス（critical path）**の抽出です。

クリティカルパスとは、根スパンの所要時間を構成する区間のうち、待ちで隠れず実時間として効いている部分を、根から葉へ繋いだ経路です。直感的には「ここを1ミリ秒削れば、全体も1ミリ秒縮む」区間の連なりです。原理はこうです。

ある親スパンの区間 [t_start, t_end] を、子スパンで埋めていく:
  - child-of の子で、親の待ち時間を実際に占有している区間を選ぶ
  - 並行する子が複数あれば、その時間帯で最後に終わる子だけがクリティカル
  - 子の中も再帰的に同じ規則で分解する
  - どの子にも覆われない区間（親自身のCPU処理）もクリティカルに含める

要点は2つあります。第一に、ファンアウトでは最遅の子のみがクリティカルで、他の子をいくら最適化しても全体は1秒も縮みません。第二に、follows-from（非同期後続）は親の完了を待たせないので、原則クリティカルパスに乗りません。だからこそ child-of と follows-from の正しい区別が、そのまま分析の正しさに直結します。これはhappens-before と因果順序で論じる「真の依存」と「見かけの並行」を、実時間軸の上で具体化したものと言えます。

まとめ

スパンモデルの正しさは、結局「因果を正しく表現できているか」に尽きます。表現を誤れば、どれだけ高機能なバックエンドでも嘘の遅延分析を返します。

• スパンは開始・終了時刻と parent_id を持つ区間で、トレースは参照辺で組む有向グラフ。木に見えるのは多くのスパンが親を1つだけ持つから。
• 因果を保証するのはコンテキスト伝播だけ。traceparent の引き継ぎが1箇所でも切れると、下流は新しい根になりトレースが断片化する。後から繋ぎ直せない。
• child-of は同期従属（親が待つ）、follows-from は非同期後続（親は待たない）。取り違えると待ち時間を二重計上したり、逆に実遅延を見落とす。
• ファンイン・バッチ・キューでは親が複数になり木に収まらないためLink で DAG として表す。木しか描けない可視化は因果を落とす。
• クリティカルパスは実時間として効く区間の連なり。ファンアウトでは最遅の子だけ、follows-from は原則乗らない。ここを正しく抽出してはじめて最適化の投資先が決まる。