AI Factory as a Serviceを実現するということは、GPUを単に積み上げれば良いという話しではありません。オンデマンドで高性能かつ分離された環境をプロビジョニングできるインテリジェントでプログラマブルなネットワークファブリックが必要です。Midokuraでは、HedgehogとSONiCを導入しています。ベアメタル環境と仮想マシン環境をまたぐVPC（Virtual Private Cloud）を自動的に生成しつつ、ファブリック全体を完全なレイヤ3構成でスケーラブルに保つことができるからです。
プログラマブルなファブリックを構築した理由
従来のクラウド環境では、Open vSwitchなどのソフトウェアオーバーレイをホスト側で実行してテナントを分離するのが一般的です。しかし、GPUを多く搭載したベアメタルサーバー環境では、この方法は通用しません。
- ホスト自体がテナントに所属している可能性
- ホスト内でのネットワーク仮想化による深刻なレイテンシの発生
- RDMA（RoCEv2）や高スループットなワークロードでは、一貫したQoSと損失ゼロの通信が求められる
こうした課題を踏まえ、ネットワーク仮想化の処理をホスト側からファブリック側へ移行しました。スイッチやスマートNIC（BlueFieldやConnectX-7）がハードウェアレベルでテナント分離を行い、Hedgehogがネットワーク全体のスイッチを制御します。
完全なレイヤ3構成のファブリック — すべてのリンクがルーティングされ、スパニングツリーやVLANトランクは不要。
- VXLANによるレイヤ2/3オーバーレイ — ルーティングされたファブリック上で各テナントのVPCを定義。
- VTEP（VXLAN Tunnel Endpoint）はリーフスイッチ上に実装。
- OpenStackで新しいテナントやネットワークを作成すると、Hedgehogが対応するVPC（VXLAN + ルーティングインスタンス）を自動生成。
Step-by-step flow: from tenant to fabric
テナントからファブリックまでの処理フロー
1. OpenStackでテナントネットワークを作成
ユーザーがOpenStack（HorizonまたはAPI経由）でネットワークを作成すると、Hedgehogと連携したNeutronプラグインがファブリックのインテントをHedgehogに送信します。
{
“tenant_id”: “abc123”,
“vpc_name”: “tenant-net-01”,
“vxlan_vni”: 5001,
“subnet”: “10.42.0.0/16”
}
2. HedgehogコントローラがVPCを作成
Hedgehogが上記インテントを宣言的なSONiC構成に変換します。
- テナントサブネットに対応するVXLAN VNI（5001）を作成
- テナントのインスタンスをホストする予定のリーフごとにVTEPを割り当て
- リーフ間接続用のルートターゲットを設定
- RDMA向けのQoS/PFCテンプレートを適用
概念的なポリシー構成例（抜粋）
vpc:
name: tenant-net-01
vni: 5001
subnet: 10.42.0.0/16
vteps:
– leaf1
– leaf3
qos_profile: “rdma_lossless”
3. インスタンス（VMまたはベアメタル）の起動
VMまたはベアメタルインスタンスが起動すると、以下が行われます。
- OpenStackがインスタンスのポートバインディング情報をHedgehogにコールバック
- Hedgehogがホストに接続するリーフスイッチのポートを設定
VMの場合、ホストで作成されるvNIC（VFIOまたはSR-IOV経由）はVLANタグ付きです。VLANタグがテナントネットワークを識別します。
ベアメタルの場合は、BlueField DPUまたはTop-of-RackスイッチがVLANを分類します。
リーフスイッチでは、VLANタグによって適切なVPC／VXLAN VNIが選択され、スイッチがトラフィックをテナントのVXLANオーバーレイへカプセル化して転送します。
4. L3ファブリック上でのルーティング
リーフ間の通信はすべてIPルーティングで行われます。VXLANトンネルは各VTEPで終端します。これにより、各VPCは独自の制御プレーンを持つ完全なルーティングオーバーレイネットワークとして機能します。
SONiC設定例（概念）
Hedgehogがスイッチにプッシュする簡単な設定例です。
{
“VLAN”: {
“Vlan5001”: {
“vlanid”: “5001”
}
},
“VXLAN_TUNNEL”: {
“Vtep5001”: {
“src_ip”: “192.168.1.10”,
“dst_ip”: “192.168.1.11”,
“vni”: “5001”
}
},
“VLAN_MEMBER”: {
“Ethernet8|Vlan5001”: {
“tagging_mode”: “tagged”
}
},
“INTERFACE”: {
“Vlan5001”: {
“ip_prefix”: “10.42.0.1/24”
}
}
}
Hedgehogは上記コマンドをgNMIまたはRESTを介してプッシュし、構成の検証と疎通状況を監視します。
このモデルが有効な理由
- スケーラブルなL3ファブリック：すべてのリンクがルーティングされており、ラックを追加してもL2ドメインは広がりません。
- VPC抽象化：テナントごとに独立したIP空間を提供します。
- 自動化の一元化：VMとベアメタルの両方を同じプロセスで管理します。
- 低レイテンシ：ホスト上のソフトウェアオーバーレイを排除し、スイッチASICでトラフィックをカプセル化します。
- セキュリティ：スイッチでVLAN/VNIマッピングを行い、スプーフィングを防止します。
- シンプルな連携：OpenStackがインテントを定義し、HedgehogとSONiCが構成に反映します。
ベアメタルとVMの違い
| モード | VLANのタグ付け位置 | 分離の実現方法 | NICバインディング |
| ベアメタル | BlueField DPU または ToR スイッチ | PU とスイッチ ACLを使用 | PF パススルー |
| VM | ハイパーバイザー内で VFIO / SR-IOV vNIC にタグ付け | リーフスイッチによる VPC 選択 | Neutron ポート経由で VF をマッピング |
どちらのモードも同じVXLANオーバーレイで終端するため、VMとベアメタルが混在するハイブリッドワークロードを同一VPC内で構成できます（例：VMで処理を行い、GPUベアメタルで学習を実施）。
運用上のポイント
- 冪等性の確保が重要です。Hedgehogはスイッチの状態を定期的に照合し、構成を宣言的に維持します。
- テレメトリの統合：Hedgehogはインターフェイス、VXLAN、ECNカウンタを収集し、損失のない通信動作であるか確認します。
- 事前検証：新しいVPCをデプロイする前に、Hedgehogがリーフ間でpingおよびルートチェックを行い、VXLANの疎通性を確認します。
今後の展開
今後は、次の機能拡張を計画しています。
- マルチサイトファブリック：複数のデータセンター間でHedgehogが連携し、EVPNルートリフレクションに対応します。
- テナント単位のQoSポリシー：VPC作成時にHedgehogが自動で適用します。
まとめ
Hedgehogの宣言的な自動化と、SONiCのオープンなネットワークOSを組み合わせることで、次のようなファブリックを実現しています。
- すべてをルーティングし、スパニングツリーやフラットVLANを排除しています。
- OpenStackのテナント定義から、ハードウェアレベルで分離されたVPCを自動的に作成しています。
- VMとベアメタルの両方に対応しています。
- レイテンシを予測できる状態に維持し、一元管理しています。
この仕組みにより、Midokuraはパブリッククラウドの柔軟さとプライベートクラスタの高い安定性を両立し、AI Factoryのテナントが求める理想的な環境を実現しています。