測れないものを推定する

リンクカウンターから推定したトラフィックマトリクス、作らないと決めたフローコレクター、そして自分のラボの正直な限界

2026年8月22日 Michel Wijnberg

前回の記事は、あえて問いをひとつ手前で止めました。nrt1-cr1 ↔ sea1-cr1 を落とすと 56 のパスが変化し、孤立するものはない、と Osprey は言えます。運用者が次に尋ねる問いこそ、その変更が安全かどうかを決めるものです。

トラフィックはどこへ行き、どこかがあふれないか。

経路の本数だけで変更を承認する人はいません。判断を決めるのは容量です。トラフィックを引き継ぐリンクに、それを収める余地があるかどうか。この記事は、ネットワークの中にそれを直接測っているものが何もないとき、その数字にどこまで正直に近づけるのか、そしてその答えがどこから先は寄りかかるべきでないものになるのか、についてです。

それに答えるには、どの送信元からどの宛先へどれだけ流れているかを知る必要があります。すなわち トラフィックマトリクスです。ほとんど誰も持っていません。

作らないと決めたもの

トラフィックマトリクスを手に入れる教科書的な方法はフローエクスポートです。NetFlow、sFlow、 IPFIX。ルーターがフローをサンプリングし、レコードをコレクターへ送り、それを起点-終点の需要へ集約します。

私はそれを計画していました。このリポジトリには、LSDB を意識した重複排除を伴うフローコレクターの設計文書が 1,139 行あります。その冒頭行に、こう記されています。

Status: SHELVED (2026-03-12). Deferred indefinitely after cross-plan feasibility review.

理由は 5 つ挙げてあります。実際に決め手になった 2 つはこれです。

**容量。**ルーター 500 台で週あたり 70〜220 GB、データベースの残り全部のおよそ 100 倍です。この製品のデータストアは意図的に PostgreSQL ひとつだけであり、フローのパイプラインを飲み込むということは、2 つ目のデータストアを持つか、データベースが倒れるかのどちらかを意味します。
**限界的な価値。**実務上のトラフィック可視性のおよそ 80% は、すでに収集していた SNMP のインターフェースカウンターから得られていました。

これは技術的な不可能性ではありません。残りの 20% のために新しいサブシステム、新しい運用負担、そして新しい種類のストレージリスクを支払うことになる、それは割に合わないという判断です。理にかなった反対意見はありますし、フローが本当に必要なネットワークもあります。ここで大事なのは、この決定が理由とともに文書化されていて、Osprey を評価する人が自分の状況と私の状況が一致するかを確認できる、ということです。

というわけでフローレコードはありません。残るのは、面白いほうの問題です。

リンクが明かすものからマトリクスを推定する

Osprey が実際に持っているのは、すべてのリンクの負荷であり、それはきちんと測られています。 64 ビットの ifHCInOctets / ifHCOutOctets カウンターを周期的にポーリングし、差分をとって bps にし、ラップアラウンドを補正し、インターフェース速度で割って使用率にします。

これはリンク単位の合計の集合です。欲しいのはペア単位の需要の集合です。前者から後者を復元するのは不良設定の逆問題です。まったく異なる多数のトラフィックマトリクスが、まったく同じリンク負荷を生みます。これにはよく知られた手法があります。Tomogravity（Zhang、Roughan ほか、 2003 年）です。

2 手で動き、Osprey はその両方を実装しています。

// computeTrafficEstimate estimates traffic redistribution after topology
// mutations using the gravity model (Zhang/Roughan et al., "Tomogravity" 2003).
//
// Without a full traffic demand matrix, per-pair demands are estimated using
// the gravity model: demand(i,j) ∝ V(i)·V(j)/V_total, where V(i) is the
// total traffic volume at device i (derived from SNMP interface utilization).
// These gravity demands are then calibrated against observed per-link loads
// so that the model's predictions match reality.

重力のステップは、2 台のルーター間のトラフィックが、それぞれが全体で運ぶ量の積に比例すると仮定します。ニュートンの重力と同じ形であり、2 つの経済のあいだの貿易モデルとも同じ形です。これは測定ではなく事前分布であり、特定の仕方で間違います。忙しい隣接ペアや静かな隣接ペアという概念を持たないのです。

トモグラフィのステップが、これを使えるものにします。重力による推測は、推定されたすべての需要を IGP が実際に選ぶ経路に沿って流したとき、結果として得られるリンクごとの負荷が測定された 負荷と一致するようにスケーリングされます。事前分布が証拠によって補正されるわけで、ここで唯一推測でないものがその証拠です。

そのあとで初めて、較正済みの需要が障害後の経路に沿って流し直され（ECMP 重み付きなので、トラフィックが 4 分割されるペアは各リンクに 4 分の 1 ずつ寄与します）、その差が予測される再分配になります。

あえて地味にした 3 つの選択

推定器において面白い工学は、すべて「自信を持たせない」ための工夫の中にあります。

**リンクごとではなく、全体で較正する。**誘惑にかられる版は、リンクごとに独立してスケーリング係数を計算します。データへの当てはまりは良くなり、そして格段に悪くなります。

// Compute a GLOBAL calibration factor: total observed bps / total gravity sum.
// Per-link calibration can amplify noise when gravitySumPerLink is small
// relative to observed traffic, producing extreme scaling factors that
// inflate per-pair demands unrealistically. Global calibration distributes
// the error uniformly, producing more stable and realistic results.

重力の総和がほぼゼロで、測定トラフィックが少しあるだけの静かなリンクは、途方もないスケーリング係数を生み、そのリンクを通るすべてのペアを膨らませます。当てはまりの良さと引き換えに、ときどき無意味な値を買うことになります。全体でひとつの係数なら、誤差は均等にならされ、決して爆発しません。

**単一ペアの上限を全体量の 5% にする。**推定された需要ひとつがネットワーク全体のどれだけを占めてよいかのハードな上限です。逆問題の破綻の仕方は、1 つのペアがすべてを吸い込むことだからです。

**小さな変化は報告しない。**予測される移動量がリンク使用率の 0.5% 未満なら破棄します。コスト変更の経路では 0.1% で、そこは仮想リンクや仮想ノードも通るため、新しい中継ノードの影響が多数のリンクへ薄く広がるからです。それ以下では、その数字はカウンターのゆらぎと区別がつかず、印字すれば誰かをノイズに基づいて行動させることになります。

どれも出力を「精密さに欠ける」ものに見せます。精密さは目標ではありません。目標は、画面に出る数字が寄りかかれるものであることです。

そして、ここからは私のラボが助けにならない話

前の 8 本の記事のすべては、私に反論できるラボに対して検証されていました。4,032 のルーターペアを実際のルーティングテーブルと突き合わせ。架空の回廊を 360 本発見。3 つのプロトコル、3 つの発見経路が、同じ単一障害点について一致。

トラフィックについては、このラボはほぼ役に立ちません。その理由を正確に述べたいと思います。

このラボのルーターはほとんど何も転送していません。プロトコルを動かし、LSA と BGP アップデートを交換する。実質それだけです。測定値は次のとおりです。

測定	値
使用率データのあるインターフェース	1,279
…使用率 0.05% 未満	1,241
全体で最も高い使用率	10 Mbps ポートでの 0.431%
全体で最も高いインターフェースレート	約 43 kbps
10 Gbps 定格の 368 インターフェースでのピーク	約 24 kbps、つまり 0.00024%

その帰結は、どこを見ればよいか分かっていれば前回の記事のシミュレーションのスクリーンショットに見えています。障害リンクの見出しには “2 links, 6Kbps displaced”、 6 キロビットとあり、パネルには Traffic Redistribution のセクションも、輻輳リスクの表示もまったくありません。コードが走らなかったからではありません。予測された移動がすべて 0.5% のノイズフロアを下回り、正しく破棄されたからです。

配管は検証可能に正しく動いています。カウンターが読まれ、レートの差分が取られ、重力需要が形成され、較正が走り、障害後の ECMP 経路上で再分配が計算され、ノイズフロアが捨てるべきものを捨てます。ラボが私に 教えられないのは、その推定が良いかどうかです。推定器を検証するには比較対象となる正解が必要であり、ここでの正解とは、起点-終点マトリクスが既知の実トラフィックを意味するからです。

トラフィックのないラボはそれを生み出せません。合成負荷を加えても解決しません。私が選んだマトリクスからトラフィックを生成し、そのマトリクスを推定器が復元できたことを自分で祝う、というだけになります。それは検証ではなく、自分の算数をとても遅い方法で確かめているだけです。

では、どれくらい信用すべきか

これが正直なはしごです。数字が確かでなくなる順に並べます。

リンク使用率、ライブと履歴：測定値。64 ビットカウンター、差分、ラップアラウンド補正、インターフェース速度に対する妥当性チェック。これはデータです。
変異のあとどのパスが変わるか：トポロジーから計算されたもの。決定論的であり、その下にあるトポロジーは 4,032 のルーターペアで検証されたものです。
各リンクにどれだけのトラフィックが移るか：推定値。重力の事前分布を、測定されたリンク負荷で補正したものです。方向性としては有用で、実際の証拠で較正されており、そして測定ではありません。

3 段目は本当に価値があります。「この 12 本のリンクが障害を吸収する」と「この 1 本が大半を吸収し、しかもすでに 70% だ」の違いだからです。同時にこれは、このシリーズ全体を通じて検証の数字を添えられない唯一の段でもあり、「4,032 分の 4,032」と同じ声色で提示するのは不誠実でしょう。

製品は、できるところではその線を引いています。BGP ピアのトラフィックが、一致した SNMP インターフェースではなくプレフィックス数の比から導かれる場合、その行にはまさにそう述べるツールチップが付きます。 “Traffic estimated from prefix count ratios (no SNMP interface match)“。その隣には、カウンター由来であることを示す SNMP バッジ付きの行が並びます。同じ表を格付けする。このシリーズが何度も行き着くパターンであり、同じ形になるのはこれで 3 度目です。ドメイン間のパスはセグメントを resolved / inferred / opaque に格付けし（第 4 回）、ポートの注記は 4 つの判定を、述べられた事実から明示的な曖昧さまで格付けし（第 6 回）、上の 3 段はトラフィックの数字を格付けします。3 つのはしご、ひとつの習慣。答えの下にある根拠が不揃いなら、全体にひとつの確信度を出すのではなく、その場で格付けすること。

ラボは何のためにあるのか、あらためて

第 7 回は、ラボは Osprey をよく見せるためではなく Osprey が間違っていることを証明するためにある、と論じました。今回はその、誰も喜ばない系です。ラボが反証できるのは、ラボが実際に働かせられるものだけです。

私のラボは、トポロジー、プロトコルの意味論、転送について私に反論するのが並外れて得意です。読み取って突き合わせられる実際のルーティングテーブルを持つ実機のルーターが 192 台あるからです。トラフィックについて私に反論する能力はありません。トラフィックを運んでいないからです。

自分の製品が印字するそれぞれの数字について、この 2 つの状況のどちらにいるかを知っていること。信頼に足るツールと、ただ自信があるだけのツールを分けるものの大半がそれです。Osprey のどの主張が測定に裏づけられ、どれが検証済みモデル上の計算に裏づけられ、どれが「私は信じているがここでは証明できない推定器」に裏づけられているかを、私は正確に把握しています。

今回の記事は 3 番目のカテゴリです。それはちょうど 1 つだけあり、いまあなたはそれがどこにあるかを知っています。

次回はこのシリーズの最終回です。モデルは正しく、そしてそれはいまのモデルでもあります。壊れる 1 時間前、ネットワークはどう見えていたのか。ネットワークには記憶がある。