CNCFホワイトペーパー：データストレージがスケールするクラウドネイティブAIの主要ボトルネックに

CNCF TAG Infrastructureは「Data Storage in Cloud Native AI」と題したホワイトペーパーを公開した——特定のベンダーによるスポンサーなしにコミュニティが著した文書だ。プロジェクトの社内作業名「Data On Kubernetes – Data Analytics and AI/ML Workloads」の方が実際のフォーカスをより正確に表現している：AIワークロードがKubernetesを流れるとき、データストレージはどのように振る舞うのか？

この文書が示す答えは楽観的ではない。標準的なマイクロサービス向けに最適化された従来のストレージアーキテクチャは、並列化・高性能なGPUハードウェアインフラに大量のデータセットを供給するという課題に直面すると、深刻な制限を露呈する。

3つの基本的なボトルネックとは何か？

この文書は、クラウドネイティブAIインフラが規模で機能するために解決しなければならない3つのシステム的な障壁を特定している。

スモールファイル問題はおそらく最も要求が厳しい。トレーニング用データセットには定期的に数百万の小さなファイルが含まれる——画像、音声クリップ、テキスト文書。各ファイルに個別のメタデータ操作が必要だ。数百万のそのような操作の集合がストレージのメタデータサーバーに莫大な負荷をかけ、GPUノードが計算する代わりにデータを待つという結果になる。GPU使用率が下がり、コストが上がり、生産性が停滞する。

コンピュートとストレージの分離のボトルネックが2番目のシステム的な課題だ。コンピュートとストレージリソースの分離はクラウドネイティブ環境の基本的なアーキテクチャ原則であり、標準的なワークロードでは概ね良好に機能する。しかしAIトレーニングと推論では、リモートデータへのアクセスごとに生じるAPIオーバーヘッドが、高価なアクセラレータの使用率低下として可視的なパフォーマンスペナルティとして積み重なる。

各フェーズの可変要件が3番目のボトルネックで、今回は組織的な性格を持つ：トレーニング、推論、エージェントAIはストレージに対して根本的に異なる要件プロファイルを持っており、単一のアプローチでは3つのフェーズすべてを最適に提供できない。

異なるニーズを持つAIライフサイクルの3フェーズ

このホワイトペーパーはクラウドネイティブAIストレージを、それぞれが独立したアーキテクチャ上の考慮を必要とする3つのフェーズを中心に構成している。

トレーニングフェーズは主に高いスループットを求める。システムは大量のデータをGPUクラスターに継続的かつ逐次的に配信でき、中断後のトレーニング再開を可能にするチェックポイントを効率的に管理できなければならない。Apache Parquetフォーマットはカラム型読み取りと圧縮によりここで優位に立つ。

推論フェーズはレイテンシを重視する。リクエストはバースト状に来る——トラフィックは均一ではない——そしてモデルは素早く利用可能でなければならない。KVキャッシングと高速なモデルロードが重要になる。Apache Icebergはテーブルフォーマットとしてタイムトラベルとスキーマ進化をもたらし、モデルのバージョン管理に役立つ。

エージェントAIが最も複雑な要件を示す。反復的な推論ループを実行するエージェントには、セッション内のアクティブなコンテキスト向けの短期メモリとセッション間で持続する知識向けの長期メモリの組み合わせが必要だ。さらに、保存・取得可能でなければならないアーティファクト——中間結果、参照、計画ステップ——を生成する。ここでベクターデータベースが重要となり、Milvusがスケールでの効率的なベクター検索のためのオープンソースソリューションとして特別な注目を受ける。

主要技術とCNCFプロジェクト

この文書は特定されたボトルネックに対処するテクノロジーエコシステムをマッピングしている。CSI（Container Storage Interface）とCOSI（Container Object Storage Interface）は、特定のベンダーに依存することなくKubernetesワークロードからのストレージへのアクセスを標準化する。

アクティブなCNCFプロジェクトであるFluidは、データをコンピュートノードに近づけて保持する分散キャッシングレイヤーを実装する。これはコンピュートとストレージリソース分離のオーバーヘッドを直接解決する——データはアクティブに使用するノード上でローカルにキャッシュされる。ストリーミングとイベント駆動型パイプラインアーキテクチャには、Apache Kafkaが参照実装として残る。

これがプラットフォームエンジニアにとって重要な理由

このホワイトペーパーは学術的な文書ではない——AIワークロード向けのKubernetesクラスターアーキテクチャについて今日決断を下すチームのための実用的な参考資料だ。ガイダンスは具体的で実用的だ：各ユースケースにどのデータフォーマットを選ぶか、キャッシングレイヤーをどう整理するか、どのCNCFプロジェクトを統合するか。

ベンダースポンサーなしのコミュニティ著作アプローチが、マーケティング的なホワイトペーパーに欠けている信頼性をこの文書に与えている。CNCF TAG Infrastructureはコミュニティの継続的な開発への参加を招いている——PDFのレビュー、TAG Infrastructure憲章の議論への貢献、そして#tag-infrastructureのSlackチャンネルへの参加を通じて。