# SONiCで構築・運用する生成AI向けパブリッククラウドネットワーク Navigation: [[index]] | [[SONiC]] | [[SAKURA Internet]] ## 概要 SAKURA Internet株式会社の黒澤潔裕氏が、SONiC Workshop Japan 2025(2025年5月16日)で発表したスライド。生成AI向けGPUクラウドサービス「高火力」の基盤構築において、Clos topologyとSONiCを採用したネットワーク設計・自動化・運用の知見を共有する。短納期(立ち上げ4か月・OS更新3か月)を少数精鋭の内製チームで実現した経緯、ホワイトボックススイッチの特性を活かした検証手法、SONiC特有の構成管理・品質保証の課題を扱う。 ## 主要メッセージ - 生成AI需要の急拡大に対応し、2000基超のGPUを持つデータセンターに800GPU規模の新クラスタを増設した(p.7)。経済産業省「クラウドプログラム」の助成を受け、H100・H200・B200と段階的にGPU調達を進めている(p.6)。 - ネットワークは性質の異なる4種(GPU Interconnect・Storage Network・Service・Management)に分離し、GPU ServerからGPU InterconnectへNIC 8本×400Gbpsで接続する(p.11)。GPU Interconnect/Storage Networkは8 Spine × 8 Rail 2 PodsのClos topologyで、Rail-Optimized構成(GPU番号とLeaf番号を固定対応)を取る。Spine-Leaf間は800GBASE-SR8、Leaf-GPU Server間・GPU Server-Storage間は400GBASE-DR4を用いる(p.12)。 - TopologyはChassis Networkでなく Clos Networkを選択した。決め手はベンダーダイバーシティ(ベンダーロックインの回避)と新規設計の訴求で、Scaleoutの柔軟さも利点として挙げるが、管理対象の増大(Switch/SFP/Cable)とRouting設計の複雑化(EVPN/VXLAN/BGP)をトレードオフとして許容した(p.13)。 - Multi-Tenancy実現(EVPN/VXLAN・Anycast Gateway・VRFによるOverlay)、管理コスト削減(IPv6 link-local・BGP+BFDによるUnderlay)、大容量traffic対応(RoCEv2のECN/PFC+DLB、Tomahawk5採用の800Gbps/Port×64構成)を要件の柱とした(p.14)。 - 初期検証の段階から自動化を前提に設計し、Ansible→ONIE→ZTP→Ansible→Ansibleの5段階パイプライン(資源配置→OSインストール→最小設定→config投入→Service in)を確立した(p.15)。 - 立ち上げPhase(4か月)では限られた検証環境・負荷再現の難しさ・管理対象の増加・運用コマンドの不足に直面し、運用Phase(3か月)では監視の高精度化・冪等性の実現・開発プロセスの複雑性という課題に対応した(p.17)。 - ホワイトボックススイッチの特性を活かし、特性別の検証項目洗い出し→GNS3による仮想検証(Trident3チップ)→実機によるGPUにfocusした10日間集中検証(Tomahawk5・Edge-core)という3段階の高速検証サイクルを確立した(p.18)。 - SONiCの運用コマンド不足に対し、Linux/Pythonで自社スクリプト(`sakura-neighbor`・`sakura-config-compare`等)を開発し、LLDP/BGP情報の整理やSONiC設定の差分比較を効率化した(p.19)。 - 監視はSNMPポーリング(RoCEメトリクス非対応)からPrometheusベースの内製実装(show commandをPython scriptでパース→Exporters、node exporter・sonic exporterによるHTTP Request)へ刷新した(p.20)。 - 新規OS導入を機に、config置き換え+Container再生成(冪等性0・通信断あり)だったBeforeから、jsondiff差分生成→Dry run(構文チェック)→Apply(設定適用)の3段構成による冪等性を担保したAfterへ自動化ツールを刷新した(p.21)。 - OS依存の構成管理課題として、Config抽象度の低さ(MACアドレス・Interface Lane設定など全96ポート分のHW依存変数)と、メーカーSONiC特有のYANGスキーマ未整備(SNMP_MANAGEMENT_ADDRESS・RDMA設定でapply patch時に構文チェック緩和が必要、RDMA新規追加時はCPU100%となるため初回はreplace&rebootで回避)を挙げる(p.22)。 - SONiC独特の品質保証の難しさとして、コミュニティSONiCをメーカーが拡張する性質上、一貫したBug trackが難しい3パターン(コミュニティのbugを継承・拡張時の不具合・vendorとcommunityのFix時間差)を提示し、業界全体での議論を呼びかけた(p.23、発表者注記により本パターンはフィクション)。 - 総括として、迅速な立ち上げとサーバー基盤アセット(Ansible/Prometheus/Python)の流用、GitHubとviによる学習コストの低さを Good Point に、一定以上のリテラシー要求・ハードウェア意識による開発コスト高・自動化必須という前提・未成熟機能の存在を Bad Point に挙げた(p.25)。 ## 視覚的に重要な図表 **p.1 タイトルスライド** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-001.png]] 「SONiCで構築・運用する生成AI向けパブリッククラウドネットワーク」、さくらインターネット株式会社 黒澤潔裕による発表。 **p.4 自己紹介** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-004.png]] 黒澤潔裕(KUROSAWA Kiyohiro)、クラウド事業本部クラウドサービス部所属。GPU基盤関連のネットワーク設計と自動化を担当し、実際はSONiC/Ansible職人と自称する。2024年9月にさくらインターネット入社、前職では通信事業者でCGN/N6・SGI用Clos/Routerの設計、コンテンツ事業者で3000台サーバーの7人運用を経験。 **p.11 構成の概要** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-011.png]] 性質の異なる4つのネットワーク(GPU Interconnect・Storage Network・Service・Management)をGPU Serverから分離して設置する構成図。GPU InterconnectとStorage NetworkはlosslessでNIC 8本×400Gbps/2本×400Gbpsを収容し、ServiceとManagementはlossyで他DC/Internet接続と監視・Operationを担う。 **p.12 GPU Interconnect/Storage Network構成** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-012.png]] 8 Spine × 8 Rail 2 PodsのClos topologyによるRail-Optimized構成図。Spine-Leaf間は800GBASE-SR8(multi mode)、Leaf-GPU Server間・GPU Server-Storage間は400GBASE-DR4(single mode)で接続する。 **p.13 Topologyの選択** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-013.png]] Clos NetworkとChassis Networkの構成図・Pros/Cons比較。Clos NetworkはScaleoutの柔軟さとベンダー選択肢の広さを取り、管理対象増大とRouting設計の複雑化を許容する判断を示す。 **p.15 自動化を前提とした設計** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-015.png]] Ansible→ONIE→ZTP→Ansible→Ansibleの5段階自動化パイプライン図。①資源配置(DHCP設定・OS image・ztp.json等)→②OS install→③最小設定(user・mgmt port・iptables)→④config投入(config_db.json・frr.conf・exporter)→⑤Service in(迂回解除)の流れを示す。 **p.18 限られた検証環境** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-018.png]] 特性別検証項目の洗い出し表→GNS3(Trident3)による仮想先行検証→実機Tomahawk5/Edge-coreによるGPU focus検証(DLB・ECN/PFC・800G transceiver・自動化ツール試験を10日間集中検証)という3段階フロー。 **p.20 監視の高精度化** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-020.png]] 従来のSNMPポーリング監視(RoCEメトリクス非対応)と、Prometheusベースの内製監視基盤(Python scriptがshow commandをパースしExportersへ渡す、node exporter・sonic exporter併用)の比較図。 **p.21 冪等性の実現** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-021.png]] Before(Shell script config commandと設定置き換えでContainer再生成が発生し冪等性0・通信断)とAfter(jsondiff差分ファイル生成→Dry run構文チェック→Apply設定適用の3段構成)の比較図。 **p.23 開発プロセスの複雑性** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-023.png]] vendorとcommunityのバグ追跡ずれを示す3パターン(Case1: communityのbugを継承、Case2: 拡張時の不具合、Case3: Fixの時間差でFix前にRelease)の模式図。発表者注記により、この節の具体的事例はフィクションとして提示されている。 **p.25 SONiCを入れてみて、結局どうだった?** ![[_attachments/sonic-workshop-2025-sonic-gen-ai-public-cloud/page-025.png]] Good Point(迅速な立ち上げ、サーバー基盤アセット流用、GitHubとviが最高の教材)とBad Point(一定以上のリテラシー要求、Hardware意識のコスト高、自動化必須、未成熟な機能)の総括表。 ## 概念・実体への接続 - [[SONiC]] — 本発表全体の対象NOS。Clos topology・自動化パイプライン・冪等性実装の事例を追加。 - [[SAKURA Internet]] — 「高火力」GPUクラウド基盤の構築事例として、[[SAKURAONE]]とは別のワークロード(パブリッククラウド向けGPUクラスタ)の知見を追加。 - [[黒澤潔裕]] — 発表者。新規entity。 - [[Clos Network]] — Clos vs Chassisのベンダーダイバーシティ観点の比較知見を追加。 - [[Rail-Optimizedトポロジ]] — Spine 8台×Rail 2 Pods 8台という具体的規模の実装事例を追加。 - [[べき等性]] — jsondiff+dry run+applyによるネットワーク機器config冪等性実装の事例を追加。 ## 限界・不確実点 - スライド中の具体的な数値(GPU調達基数の内訳、Oversubscription比等)は、決算説明資料からの抜粋部分(p.6-7)を除き詳細な公開値としては明記されていない。 - p.23「開発プロセスの複雑性」の3ケースは、発表者自身が「この話はフィクションです」と注記しており、実際の障害事例そのものではなく一般化された問題提起として扱う。 - transcript(音声・動画)は取得していない。口頭でのみ補足された可能性のある情報(Q&A等)は本ページに反映していない。 - 黒澤氏の所属・肩書き・経歴の詳細はp.4の自己紹介スライドのみを根拠とし、外部の公式プロフィールでの裏取りは行っていない。