この記事は、Senior Technical Marketing Engineer である Dean Lewis によるブログ「 OpenAI Uses Isovalent for a Common Networking for AI Infrastructure 」( 2026年 6月 9日 )の抄訳です。
OpenAI 規模の AI システムを支えるプラットフォームでは、ネットワークが確実に機能することが不可欠です。サービスを安定的に接続して適切な制御を適用し、さまざまな種類のコンピューティングをサポートするとともに、インフラ管理チームが状況を把握するための十分な可視性を提供する必要があります。OpenAI は、Isovalent が提供する Cilium ベースのエンタープライズ向けソリューション「 Isovalent Networking for Kubernetes 」を、標準の Kubernetes ネットワーキングスタックとして採用しました。これにより、OpenAI はクラウドプロバイダー環境およびベアメタル環境の両方において、CNI、IPAM、L4/L7 フィルタリングの共通基盤を利用できるようになります。
OpenAI のようなスピード感で事業を推進する企業にとって、この一貫性は極めて重要です。また OpenAI には、インフラストラクチャの拡張に対応し、セキュリティおよびコンプライアンスの制御を支援するとともに、プラットフォームチームが各環境を個別のネットワーク問題として扱うことなく、ネットワークフローのトラブルシューティングを行える Kubernetes ネットワークが必要でした。
Cilium と Isovalent が選ばれた理由
Cilium は、さまざまなインフラストラクチャ環境で Kubernetes CNI として動作できるため、この要件を満たしています。これにより OpenAI は、単一のクラウドプロバイダーやベアメタルプロバイダーの CNI への依存を減らしながら、さまざまな種類のコンピューティングを柔軟に組み合わせることが可能になります。
Isovalent は、エンタープライズサポート、アップグレード計画、プロジェクトの開発・保守チームの専門知識を Cilium と組み合わせることで、その基盤を本番環境およびミッションクリティカルなワークロードで利用できるようにします。
コンピューティングレイヤは静的であることがほとんどないため、これは AI インフラストラクチャにおいて極めて重要です。新たなキャパシティやワークロードパターン、サービス要件が増えていく中で、プラットフォームチームは、各環境ごとの専用実装に依存することなく適応できるネットワークを必要としています。
また Cilium は、OpenAI に対して L4/L7 フィルタリングおよびノード間セキュリティのためのポリシーモデルを提供します。OpenAI は CiliumNetworkPolicy と CiliumClusterwideNetworkPolicy の両方を利用しており、クラスター全体に適用するポリシーを主に使用しつつ、必要に応じて対象を限定した名前空間ポリシーを適用する方向へ移行しています。その目的は、十分な制御精度を維持しながら、ポリシーの乱立を防ぐことにあります。OpenAI は、デフォルトで送受信を保護し、個々の例外を明示的に許可するという、より明確なモデルへ移行しました。
これは、他のプラットフォームチームにとっても参考になる考え方です。ポリシーは記述するだけでは不十分です。混乱やバイパスを招いたり、誤った安心感を生み出したりすることなく、チームが運用できるモデルでなければなりません。
ソリューション:共通の CNI、IPAM、ポリシー、および本番環境の可視性
OpenAI の標準 Kubernetes ネットワークスタックでは、CNI、IPAM、L4/L7 フィルタリングを統合した共通基盤をチームに提供します。
その結果、OpenAI は以下の機能を統合したネットワークスタックを実現しています。
- Cilium が、複数のクラウドおよびベアメタル環境にまたがる Kubernetes 環境全体で共通のネットワークレイヤを提供。
- Cilium が L4/L7 フィルタリングをサポートし、対象を限定したネットワーク制御を実現。
- CiliumNetworkPolicy と CiliumClusterwideNetworkPolicy が、OpenAI による適切な範囲での制御定義を支援。
- Cilium を使用して、内部および外部のコンプライアンス要件に対応するネットワーク制御を実証。
- Hubble が、Kubernetes コンテキストを使用した本番環境のフローのデバッグを支援。
Hubble は、ネットワークで何が起きているのかをチームが把握するための実用的な手段を提供します。本番環境で想定外のネットワークフローを調査する必要がある場合、hubble observe を使用すれば、従来のパケットキャプチャ(tcpdump)よりも容易に状況を確認できます。この違いは、本番環境において特に重要です。パケットキャプチャにも依然として重要な役割がありますが、プラットフォームチームには、毎回パケットレベルの詳細な分析を行うことなく、サービスレベルの問題に迅速に対応できる手段が求められています。
成果:より一貫性のあるネットワーキングと優れた制御
OpenAI における成果は、複雑で変化し続けるインフラストラクチャ環境全体で利用できる Kubernetes ネットワークスタックを実現したことです。
Cilium は、複数のクラウド環境およびベアメタル環境にまたがる共通の CNI 基盤を OpenAI に提供します。また、IPAM、CNI、L4/L7 フィルタリング機能により本番環境への移行を支援するとともに、OpenAI のコンプライアンス対応を支えるネットワーク制御も提供します。さらに、Hubble を使用することで、より直接的な方法で本番環境のフローをデバッグできます。
OpenAI にとって、拡張性とは単にインフラストラクチャを増設することではありません。重要なのは、さまざまなコンピューティング環境、クラウド、サービス、チームにまたがってプラットフォームが拡大していく中でも、ネットワークレイヤを予測可能な状態に維持することです。
Cilium のおかげで、非常に競争の激しい市場において GPU キャパシティを活用し、迅速に対応できるようになっています。リリースやコンピューティングリソースの提供開始を 1 日、あるいは 1 週間前倒しできるかどうかが、ビジネスに大きな影響を与える市場環境です。単一の Kubernetes ネイティブなネットワーク制御プレーンを導入することで、Kubernetes エコシステムのツールやプログラマビリティを最大限に活用できるようになります。その結果、エージェント型ワークフローによって変化のペースが加速する動的な環境においても、コンプライアンスやセキュリティの要件を容易に満たすことができます
Fangyuan Li 氏(OpenAI、Fleet GPU Expansions 技術責任者)
他の AI プラットフォームチームが学べること
AI インフラ管理チームは、多くの場合、まずコンピューティングに注力します。それは当然のことです。しかし、ネットワークもプラットフォームの成長を支える重要な要素です。サービスが増え、環境が多様化し、本番環境への期待が高まるにつれて、変化する環境の中でも一貫性を維持できるネットワーク基盤が求められるようになります。
OpenAI の事例から得られる、他のプラットフォームチームにとって有益な教訓をいくつか紹介します。
第1 は、共通の CNI を標準化することです。これにより、クラウド環境とベアメタル環境の運用上の差異を減らすことができます。その結果、キャパシティ、ワークロード、インフラストラクチャの選択が変わっても、プラットフォームチームは一貫した運用モデルを維持できます。
第2 に、ポリシー設計は運用可能でなければなりません。名前空間レベルのポリシーを大量に導入しても、必ずしもセキュリティが向上するとは限らず、むしろ複雑さを増大させる可能性があります。OpenAI が、クラスター全体に適用するポリシーを主に使用しつつ、必要に応じて対象を限定した名前空間ポリシーを適用する方向へ移行したことは、より慎重な運用モデルへの転換を示しています。
第3 に、本番環境でのトラブルシューティングには、Kubernetes を理解した可視性が必要です。Hubble を利用することで、チームは事前にパケットキャプチャを取得しなくてもフローを調査できます。これにより、調査の迅速化が可能になるだけでなく、プラットフォームチームも利用しやすくなります。
最後に重要なのが、エンタープライズサポートです。ネットワークが本番環境の基盤の一部である場合、これは極めて重要になります。Isovalent と連携することで、厳しい要件が求められる環境で培われた、Cilium の開発・保守チームの深いエンジニアリングおよび運用の知見を活用できます。
Isovalent でより予測可能な Kubernetes ネットワークを構築
Kubernetes ネットワーキングの課題が単独で発生することはほとんどありません。課題は、クラウド環境とベアメタル環境の違い、ポリシーの複雑さ、コンプライアンス要件、本番環境でのトラブルシューティング、アップグレード計画、さらには基盤インフラストラクチャが変化する中でもプラットフォームを前進させ続けなければならないというプレッシャーなどの要因から生じます。
こうした課題に直面しているプラットフォームチームを、Isovalent がサポートします。Isovalent Networking for Kubernetes は、本番環境およびミッションクリティカルな環境で培われた Cilium の専門知識に支えられており、Kubernetes のネットワーキング、セキュリティ、オブザーバビリティを実現するための、エンタープライズ向け Cilium ベース基盤を提供します。
関連情報
- Isovalent の他の顧客事例を読む
- Isovalent Networking for Kubernetes の詳細を見る
- Isovalent Reliable Connectivity の詳細を見る
- Isovalent ラボで実際に体験する
この記事は、Senior Technical Marketing Engineer である