新しいネットワークスイッチを使うには、チップだけでなく、それを動かすソフトウェアも準備する必要があります。ところが実機が届くまで検証を始められないと、不具合の発見も後ろへずれてしまいます。
この待ち時間を減らすために、GoogleとBroadcomが紹介したのが、Alpine Virtual Switch（AVS）とTH6向けBCMSIMを組み合わせる検証環境です。ネットワークOSのSONiCと、スイッチチップの動作モデルをつなぎ、実機の到着前からソフトウェアの組み合わせを確かめます。講演では、Googleが最初のTH6実機サンプルを受け取る前に、約40件の異なる問題を特定して解決したと報告しています。［1］
実機の数に、検証の数を縛られないようにする
講演が挙げる課題は、スイッチが高価で、開発者と自動テストが同じ試験設備を共有しやすいことです。接続できる台数が限られれば、大きなネットワーク構成も試しにくくなります。新しいチップでは、そもそも実機がまだ用意できない段階から、ソフトウェアの開発が進みます。［1］
AVSは、SONiCのソフトウェア群をコンテナ化し、パケットを転送するデータプレーンの実装を差し替えられる仮想スイッチです。複数のAVSをつなぐ際には、Kubernetes上でネットワークを再現するKNE（Kubernetes Network Emulation）を使う「Aktive」が配置を受け持ちます。1台の動作と、複数台を結んだ構成を、段階を分けて検証できる形です。［1］
何を再現するかで、モデルを選ぶ
仮想スイッチといっても、実機のどこまでをソフトウェアで表すかは同じではありません。資料は、AVSに組み合わせる選択肢を三つの層に分けています。［1］
- VPPは、高速なソフトウェアのパケット処理エンジンです。チップや、その制御用SDKのモデルは持ちません。
- Luciusは、SAI（Switch Abstraction Interface）の層でスイッチの動作を表します。SAIは、SONiC側からスイッチを制御するための共通インターフェースで、LuciusはSONiCの機能を素早く確かめる用途に位置づけられています。
- BCMSIMは、チップ内部の制御情報を読み書きするレジスターの動作まで扱うデバイスモデルです。その上で、実機向けのBroadcom SDKとSAIを動かします。
SDKは、ソフトウェアからチップを扱うためのライブラリーなどをまとめたものです。BCMSIMを使うと、SONiCの機能だけでなく、SAI、SDK、チップの動作モデルへと続く組み合わせを確認できます。検証したい層に応じて、処理の速さや規模と、モデルが扱う詳細さを選ぶ考え方です。資料には、この三方式を同じ条件で測った性能比較は示されていません。［1］
仮想ポートをつなぎ、実機と設定をそろえる
今回の構成では、TH6の動作モデルと仮想ネットワークインターフェースの間に「BCMSIM vBridge」を置きます。モデル側と外側で使うメッセージを橋渡しし、パケットの送受信や、リンクが切れて戻る変化をやり取りします。CPU向けのパケットには別の仲介層があり、ポートごとの統計も観測します。［1］
もう一つ大切なのが、AVSと実機側の設定をそろえることです。資料では、SONiCのconfig_db.jsonやBroadcomのbcmsim-config.ymlを例に挙げています。同じ問題を仮想環境で追いたくても、設定が違えば、動作の違いがどこから来たのか切り分けにくくなります。モデルを用意するだけでなく、再現に必要な条件を合わせるところまでが検証環境の設計です。［1］
約40件の問題を、最初の実機より前に解決
講演で報告された約40件は、SAI・SDKとネットワークOSの設定に関する問題です。Googleが最初のTH6実機サンプルを受け取る前に特定・解決した件数であり、チップの物理的な欠陥を40件見つけた、という意味ではありません。［1］
こうした検証は、コードを取り込む前の自動テストにも組み込めます。資料では、クラウド上で数時間ごと、または重要度に応じて毎晩、AVSとTH6 BCMSIMを使う自動処理を走らせる取り組みを説明しています。変更のたびに実機の順番を待たず、ソフトウェアの不整合を早めに見つける狙いです。［1］
GoogleのAVS環境をBroadcom側の仮想マシンで立ち上げる試みも、単発の実験として報告されています。同じ環境を共有し続けられれば、問題を説明し直す往復を減らせる可能性があります。ただし、継続運用による短縮効果は、今回の資料では測定結果として示されていません。［1］
仮想環境で前倒しできる範囲を、はっきりさせる
BCMSIMは、資料ではASICの「デジタルツイン」と呼ばれています。ここで示されているのは、チップの動作モデルを使い、設計からSDK、SAI、SONiCへと検証をつなぐ仕組みです。実機の発熱、電力、信号品質、実効的な転送性能まで、すべて同じように再現できることを示すものではありません。［1］
検証のうち、実機を待たずに進められる部分を増やす。実機が届いたら、物理環境でしか確かめられない部分に向き合う。AVSとBCMSIMの組み合わせは、その順序を組み直し、ソフトウェアの問題を早い段階で減らしておくための取り組みです。
発表に登場する企業を知る
Broadcomの半導体・基盤ソフト事業と、Googleの親会社Alphabetの事業全体は、cyclewaveの企業解説にまとめています。
参考資料
［1］Google・Broadcom「Accelerate fabric validation with Alpine VS and BCMSIM」。2026 OCP APAC Summitの公開スライド。3–5ページ：検証設備の課題とAVS・Aktive、7–11ページ：モデルの層と接続・設定、12–14ページ：適用例と報告結果。公式一覧では「Accelerate cloud scale validation with AVS and TH6 BCMSIM」として掲載。
［2］Open Compute Project「2026 OCP APAC Summit」。開催日・登壇者・公開資料の案内。記事は公開スライドをもとに構成しています。
コメントを残す