要約

  • 5x9 Networksは、144コアのXeon 6780E上で1つのフォワーダーが6万4,000加入者を扱い、ACL有効・階層QoSなしで200 Mpps、500バイトのパケットで800 Gbpsを得たと報告した。1.6 Tbpsは2 CPUへのスケール結果である。
  • 16個のSmall VMから1個のBig VMへ移ることで、キャッシュ内の重複状態を減らした。性能上の機構は明確だが、別の冗長性と復旧が示されない限り、実行・変更・加入者状態の境界は大きく集中する。
  • 公開資料には状態同期、障害注入、再起動、更新、セッション損失、復旧の試験がない。運用者はスループットと障害時の挙動を別々に受け入れる必要がある。

BNGは固定回線の加入者セッションがネットワークへ入る境界にある。PPPoEやIPoEを終端し、L3転送を行い、利用者ごとのQoS、ACL、AAA、合法的傍受の機能を担う場合もある。ここで必要なのは高速なパケット処理だけではない。プロセスやサーバーを失った後も、加入者状態が整合したまま、約束した時間内に戻ることである。

5x9 NetworksのCTO兼共同創業者Branimir Rajtarは、2月11日のAPRICOT 2026 Network Operationsセッションで、19ページのGetting 1+ Tbps from an x86 serverを発表した。資料は、仮想BNGを多数の小さなフォワーダーから1つの大きなフォワーダーへ変え、SR-IOV、Intel DPDK、新しいCPU、キャッシュ、PCIe/DMA、BIOS、NIC、コードを調整した過程を示す。

これはベンダー自身の記録である。したがって数値を無視する理由にはならないが、独立検証や全てのサービス条件へ拡張する根拠にもならない。

初期のSmall VM構成は、第2世代Xeon Goldを2基使い、各CPUは18コア、フォワーダーは16個だった。5x9は、階層QoSなしで40 Mpps、ありで26 Mpps、500バイト時にそれぞれ160 Gbpsと100 Gbpsと報告する。この構成では約35%の差になる。QoS一般の固定ペナルティではない。機能条件を変えると、同じ装置の容量値が大きく変わることを示す限定的な証拠である。

その後の改善は、単に「x86だから」生じたものではない。資料は、新しいハードウェアとアプリケーションで30%、DPDK、CPU、PCIe、BIOS、NICの詳細な調整で30%、プロファイリングとコード書き換えで20%の改善を挙げる。これらを別の装置へ移せる公式として扱うべきではない。重要なのは、性能が特定の部品、配置、ドライバー対応、設定、実装に依存していることである。

5x9が主要なボトルネックとして挙げたのは、CPUキャッシュミスと待ち時間だった。多数のメモリーオブジェクトがキャッシュを使い、頻繁な書き換えがストールを起こす。CPUは必要なデータより大きなキャッシュラインを読む。そこで読み取り用と書き込み用の構造を分け、PCIe/DMAのスケジューリングとハッシュ方式を変え、ルーティングテーブルのメモリー量を90%削減したという。

ここからBig VMの判断が出る。16個のSmall VMは同じ情報を何度もキャッシュへ持っていた。Big VMはそれらを統合し、1つのNUMAドメインとCPUの全コアを使うことで、重複した作業状態をまとめた。

これは物理的に説明できる改善である。キャッシュ局所性が良くなれば、メインメモリーへの往復と待ちを減らせる。重複テーブルやプロセスも減り、必要なサーバー台数を下げられる可能性がある。ただし、依存関係そのものが消えるわけではない。

現在の単一CPU結果には、144コアのXeon 6780Eが使われる。Intelの公式仕様は108 MBのキャッシュ、最大88レーンのPCIe 5.0、サーバーモードで330 WのTDPを示す。Intelの仕様は5x9の試験を再現しないが、CPU、メモリー、PCIeレーンとスロット、NIC、電力が依然としてパケット経路の一部であることを確認できる。

5x9の数値は、1つのCPU、1つのフォワーダー、6万4,000加入者、ACL有効・階層QoSなしで200 Mpps、500バイト時に800 Gbps、メモリー32 GBである。1.6 Tbpsは2 CPUへスケールした値だ。1台のサーバーと1つのCPUは同じ単位ではなく、見出しから2基目のCPUを消してはいけない。

機能と加入者数の条件も同じ重さで読む必要がある。資料は、10万加入者を超えると性能が低下し始め、最大26万加入者をサポートすると述べる。また、全加入者に階層QoSを使うと約30%、全加入者にNATを使うと30〜40%性能が下がるという。したがって800 Gbpsは、特定のパケット長と機能条件における経路結果であり、BNGが終端できる全サービスの容量ではない。

DPDKとSR-IOVは高速化の機構を説明する。DPDKのPoll Mode Driverは送受信ディスクリプターへ直接アクセスし、通常のパケット割り込みではなくポーリングを使い、従来のカーネル・ネットワークスタックを迂回する。SR-IOVは1つのPCIe物理デバイスから複数のVirtual Functionを公開する。この二つはデータ経路を変えるが、加入者状態をどこへ複製するか、フォワーダーが終了した後に何が起きるか、NICやVFをセッション損失なしで交換できるか、別サーバーがどう引き継ぐかを決めない。

CUPSにも限界がある。制御プレーンとユーザープレーンを分ければ、ポリシーやセッション制御とパケット転送を別の要素にできる。しかし、コントローラーが動いていることは、1つのBig VM、CPU、PCIe経路、NIC、サーバーを失ってもデータプレーンが続く証拠ではない。

公開されたAPRICOT資料には、冗長構成図、状態同期方式、N+1の予備量がない。フォワーダー、VF、NIC、CPU、サーバーの障害注入、再起動時間、更新とロールバック、セッション損失と復旧、混合パケット長と全機能の試験、顧客の本番結果もない。

これは、そのような機能が実装されていないという証拠ではない。Big VMが危険だという証拠でもない。公開記録が測っているのは性能経路であり、拡大した障害・変更領域ではない、という境界である。

Small VMではキャッシュ重複のコストを払う一方、1プロセスが扱う加入者集合を小さくできる場合がある。Big VMでは作業状態が効率化される一方、より多くのセッションが同じソフトウェア、CPU、保守単位へ入る。複数のBig VM、別サーバー、状態複製があれば影響を限定できるが、資料はその層を示していない。

この欠落が権限を分ける。5x9はコード、測定、試験条件、製品主張を管理する。IntelとNICベンダーはシリコン、ファームウェア、DPDK互換性、認定組合せを管理する。導入する通信事業者は、構成、予備容量、機能条件、変更時間、加入者サービスの受入基準を決める。APRICOTは発表を公開するが、プラットフォームを認証しない。

費用も同じ境界へ落ちる。事業者は新しいCPU、対応NIC、PCIe能力を持つサーバー、調整、ライセンス、反復試験、障害時の予備容量を買う。稼働サーバーを減らせばスペース、電力、運用費を下げられる可能性はある。資料には総費用や実測電力がなく、同じ状態と負荷を受け取れる待機系を、アイドルだからという理由で経済計算から外すことはできない。

加入者は集中の反対側を負担する。大きなフォワーダーが限定時間で交換され、状態が整合するなら、より安価で柔軟なサービスを受けられる。そうでなければ、1プロセスまたは1サーバーの事象が多数のセッションを相関させる可能性がある。実際に障害が起きたと主張するのではなく、二つの結果を分ける試験を求めている。

反実仮想はBig VMを捨てることではない。2つ以上のBig VMとサーバーにN+1の余力と状態同期を用意し、パケット長、IPv4/IPv6、ACL、階層QoS、NAT、AAA、制御プレーン負荷を宣言して試す。フォワーダーを停止し、VFやNICを失わせ、VMを再起動し、CPUやサーバーを落とし、更新とロールバックを行う。リセットしたセッション数、復旧時間、待機系で維持できた定常スループットを記録する。

加入者の少ないエッジでは、キャッシュ効率より小さな障害領域を優先してSmall VMを残せる。5x9自身もその使い分けを示す。ASICやホワイトボックスも、同じサービス条件と障害記録を使うなら比較できる。

ASNとプレフィックスは、この受入境界の外側にある。外部のルーティング主体と到達性は示せるが、その経路の内側にあるBNGが、変更中も加入者状態、階層QoS、NATを維持できるとは証明しない。RIRや会議が内部容量を代わりに認定する権限もない。

5x9の成果は、ソフトウェアが物理制約を消したことではない。キャッシュライン、メモリーオブジェクト、NUMA、PCIe、NIC、コードの中に制約を見つけ、移動させたことだ。次に測るべき境界も具体的である。1つのフォワーダー、1つの状態領域、それを支えるハードウェアだ。

キャッシュ効率と復旧可能性は別々に受け入れる。800 Gbpsと2 CPUの1.6 Tbpsは、条件を保ったまま読めば有用なベンダー結果である。同じ構成が約束した障害と変更を通過したとき、初めてその経路は利用可能なBNG容量になる。

情報源