フルフィードの実費
見積もるのではなく、本番スキーマにフルテーブルを載せて測った。その計測が自分の既定値を一つ葬った。
Michel Wijnberg
「フルテーブルに耐えられますか」は、あらゆる BGP 製品が受ける質問であり、数字で答える製品は ほとんどありません。正直な理由は、その答えを出すのが気まずいからです。本物のテーブルを本物の スキーマに載せて、見にいかねばなりません。
この記事はそれです。フルの IPv4 テーブル、78,538 のオリジン AS からの 1,071,538 本の ベストパス を、ラボと同じ PostgreSQL メジャーバージョン上の本番スキーマへ投入しました。 以下の数字はすべてその計測であって、そのモデルではありません。
そして計測がもたらす最も有用なもの、つまり「あなたに反論すること」も含まれています。以下の 数字の一つは、すでに Osprey の既定値として出荷済みでしたが、計測はそれが通常のトラフィック より下 にあることを示しました。以来、4 倍に引き上げられています。
単位はセッションであってルーターではない
いちばんよくあるサイジングの誤りであり、まず片づけておく価値があります。
フルテーブルの上流を 4 本持つルーターは、1 本の BMP 接続で 4 つのピア を報告します。 上流 1 本のルーターのちょうど 4 倍の費用がかかります。機器数でサイジングすると、まさにあなたの マルチホーム係数のぶんだけ過小になります。つまり、あなたがネットワークを作った目的そのものの ぶんだけです。
フルテーブル 1 つあたりの費用
サイズは PostgreSQL 自身が報告するリレーションサイズで、MB や GB という表記にもかかわらず 1024 進です。行あたりの数値はそこから導いています。したがって 412「MB」は 412 MiB です。 1,071,538 行 × 403 バイトで 411.8 MiB であり、10 進で読んだときの 432 MB ではありません。
| 単位 | 費用 | スコープ |
|---|---|---|
bgp_rib_entry (9 個のインデックス込み) | 412 MB (403 B/行) | 監視ピアセッションあたり |
bgp_best_path (4 個のインデックス込み) | 327 MB (319 B/行) | AS およびルーティングドメインあたり |
bgp_rib_entry_history (3 個のインデックス込み) | 区間あたり 376 B | 記録された遷移あたり |
| BMP のピア別プレフィックス集合、Go ヒープ | 53 MiB (52 B/プレフィックス) | 監視ピアセッションあたり |
| エンジンの RIB デバウンスバッファ (既定上限) | 267 MiB (560 B/エントリ) | エンジンあたり、フィード数に依存しない |
この表から二つ取り出しておきます。
インデックスがフットプリントのわずかに半分超を占めます。 bgp_rib_entry のセッション
あたり内訳: 主キー 82 MB、peer_prefix 42 MB、prefix_gist 32 MB、prefix 23 MB、
origin_as 8.9 MB、staleness 7.5 MB、next_hop 7.3 MB。名前を挙げる価値があるのはこの
7 つで、残り 2 つはより小さく論点を動かしません。この 7 つだけで合計 412 MB のうち 203 MB を
占め、主キー単独で全体の 5 分の 1 です。この規模のテーブルでインデックスをもう 1 本足すのは
ただかと考えたことがあるなら、ここでいちばん安いものでもセッションあたり 7.3 MB かかります。
この計測は、誰も気づいていなかった欠陥も見つけました。idx_bgp_rib_peer_lastseen は
staleness インデックスと バイト単位で同一 だったのです。7.5 MB と、すべての RIB 行での
btree 書き込み 1 回分を払って、何も買っていませんでした。削除しました。この種のことは、
サイズを並べて置くまで見えません。
1 行 403 バイトはコミュニティ込みの値です。 現実的な 6 個のコミュニティ文字列を含んで います。コミュニティのない経路は約 55 バイト安くなります。どちらの数字か言わずに安いほうを 引用すれば、誰かが何かをデプロイする前から、あなたのサイジングガイドは 14% 楽観的です。
試算した構成
| 構成 | ライブ DB | BMP ヒープ |
|---|---|---|
| ボーダールーター 1 台、上流 2 本 | 1.15 GB | 107 MiB |
| ボーダールーター 2 台、各上流 2 本 | 1.98 GB | 213 MiB |
| ルーター 4 台 × 上流 2 本 | 3.6 GB | 426 MiB |
| ルートリフレクタのフィード、フルテーブル 20 セッション | 8.6 GB | 1.04 GiB |
これらはライブ状態の数字です。履歴は別勘定であり、面白くなるのは履歴のほうです。
チャーンはスナップショットからは読み取れない
テーブルは、それを保持する費用を教えてくれます。記録する 費用については何も教えてくれま せん。それはテーブルがどれだけ頻繁に変わるかに依存し、スナップショットには時間軸がないからです。
そこでチャーンは公開 MRT アーカイブから測りました。RIPE RIS コレクタ rrc00、2026-08-10、 1 日に散らした 1 時間の窓 4 つ、98 の異なるピアセッションにわたる 680 万件の UPDATE メッセージ。標本には Osprey の 30 秒デバウンスを適用しています。属性ハッシュによる抑制は 意図的にモデル化していないので、これらは実際に記録される量の上限です。
ここでいう 区間 とは、デバウンス後に永続化された状態遷移 1 件です。生の BGP UPDATE では ありません (1 通で多数のプレフィックスを運べます)。プレフィックスイベントでもありません (デバウンスが既存の区間に畳み込みうるからです)。
| セッションあたり | 1 日あたり記録区間 | 履歴ストレージ |
|---|---|---|
| 中央値 | 413,000 | 155 MB/日 → 90 日で 14 GB |
| p90 | 840,000 | 316 MB/日 → 90 日で 28 GB |
| 観測された最重 | 8,300,000 | 3.1 GB/日 → 90 日で 281 GB |
デバウンスは本当に仕事をしています。30 秒窓ごとに (セッション, プレフィックス) あたり 1 レコード に畳み込み、生のプレフィックスイベントの 45.6% を除去します。フルテーブル対象でこれを切ると 履歴の請求額はおよそ 1.8 倍になり、その代わりに得られるのは窓の内側で起きた遷移へのより細かい 可視性です。DFZ フィードでは、それはほぼ全部、1 行ずつ保存したくないと願っていた類の詳細です。
自分が読む側なら欲しい但し書きを二つ。rrc00 は RIPE の マルチホップ コレクタで、そのピアは 典型的な IXP ローカルのトランジットセッションより騒がしいので、これらは悲観的な値として扱って ください。そして中央値よりばらつきのほうがはるかに重要です。最重のセッションは中央値の 20 倍 です。p90 でサイジングし、テールでアラームを出し、中央値を容量計画として売りつけられ ないようにしてください。
間違っていた数字
Osprey には履歴記録のサーキットブレーカがあります。ある対象が storm_ceiling_per_hour を
超える区間を生成すると、その時間の残りは記録が抑制され、フラップするセッションが無人のまま
ディスクを埋めないようにします。
出荷時の既定値は 1 時間あたり 250,000 でした。
これを計測の隣に置いてみます。rrc00 標本のなかで最も重い単一の実セッションは、1 時間あたり 約 346,000 区間 で走っています。上の表の 1 日 830 万件がそれです。暴走ではありません。 フラップループでもありません。実在のコレクタ上の実在のピアが、ごく普通の月曜日に出した値です。
既定値は、通常運用によって、ひとりでに作動していました。 しかも抑制ブレーカの故障モードは 静かなほうです。何も落ちず、大きな警報も鳴らず、ただ履歴が完全でなくなり、その欠落は探しに いって初めて見えます。
既定値はいま 1 時間あたり 1,000,000 で、直感ではなく同じ計測から導いています。p90 の チャーンはセッションあたり毎時およそ 35,000 区間なので、上の最大構成、すなわちフルテーブル 20 セッションのルートリフレクタフィードは p90 で毎時 70 万前後です。新しい上限はそれを余裕を もって上回り、最重の単一実セッションも上回りつつ、本物の暴走が出す量よりはるかに下にあります。 テーブルをフラップループで再生するセッションはこの何倍も出すので、ブレーカは依然として落ちます。
同じ計測が明らかにしていることで、含みにせず言っておきたいことがあります。騒がしいセッションを 多数集約する対象は、正当に上限を超えうるということです。rrc00 の 98 セッション合計はおよそ 1 日 5,000 万区間、毎時 200 万ほどで、新しい上限を余裕で超えます。Osprey をそういうものに 向ければブレーカは作動しますし、それが正しい振る舞いです。
二つの数字が矛盾して見えるので、はっきり述べておく価値があります。この上限は暴走ガードで あって容量計画ではありません。 対象ごとに設定され、私たちがサイジングする最大構成の通常運用 が出す量より上、テーブルをループ再生するセッションが出す量より下に置かれています。正当にそれを 超える集約対象は、一つの対象を超えて成長したのであって、製品を超えたのではありません。
だからこそ、作動はログに書くだけでなく記録されます。上限が働くと、その時間の残りについて履歴は 不完全になり、その欠落は問い合わせ可能なブラインドスポット台帳に書き込まれます。黙って監視を やめる監視システムは、声を上げてやめるものより悪く、両者を分けるのは欠落が一級のレコードで あるかどうかだけです。
これが教えてくれないこと
上のすべてはバイトの話です。フルテーブルが PostgreSQL でどれだけ占めるか、BMP サーバーが Go ヒープに何を持つか、履歴がどれだけ速く積もるか。これは一つの軸であり、サイジングの問いには いくつもの軸があります。
ここでは測っておらず、したがって主張もしていないもの:
- CPU。取り込み時も問い合わせ時も。
- セッション確立後、最初に有用な答えが出るまでの時間。運用者が実際に体感する数字です。
- メッセージ経路。BMP サーバーとデータベースのあいだで、テーブルが収束するあいだにバスと ライブ WebSocket 状態が何を費やすか。
- クエリ遅延。この規模のテーブルに対する、フットプリントとは別の話としての遅延。
これらは別々の計測であり、私はまだ行っていません。自信ありげなストレージ数値を出し、残りも同じ ように伸びると読者に仮定させることで、そうでないことをそっとほのめかすサイジングガイドは、 この記事が反対しているまさにそのことをやっています。
間違っていた既定値をなぜ公表するのか
代替案が、ある特定の意味でより悪いからです。
見積もりから作られたサイジングガイドは反証不能です。誰にも検査できないので誰も誤りを見つけず、 誤りはそのまま出荷されます。今回それが見つかったのは、数字が本物のテーブルを載せ本物の更新を 再生して作られたからであり、本物の更新ストリームは設定ファイルが何を妥当と考えているかなど 気にしないからです。
計測には約 1 日かかりました。重複インデックスを 1 本、4 倍ずれた既定値を 1 つ見つけ、そして 「フルテーブルに耐えられますか」に対するこの製品初の誠実な答えを出しました。すなわち: 耐えられ ます。ライブ状態でセッションあたり 412 MB とヒープ 53 MiB、履歴は 90 日で 14 GB から 281 GB のどこか、ピアの騒がしさ次第で完全に決まります。最後のこのレンジこそが本当の答えであり、その 中点ではありません。
要点
この記事のすべての数字は出荷済みスキーマの計測であり、そのうち一つは出荷済みコードに反論しま した。
それが、自分の製品について考えるのではなく測るべき理由です。考えることが雑だからではなく、 考えて選んだ既定値には、それが誤りだったとあなたに告げる手段がないからです。本物のテーブルは それを 1 日でやります。
これがこのシリーズの最終回です。次回はそのすべての下から始めます。レコーダーが他人のプロトコル に、その一部にならずに加わる方法を、正面玄関ごとに一つずつ。