Kubernetes（K8s、コンテナオーケストレーション基盤）上でAI・ML基盤を組んでいるプラットフォームエンジニアに向けた話をする。舞台はストレージ層、それも学習（モデルを訓練する処理）と推論（学習済みモデルで予測を返す処理）それぞれのI/O（データの読み書き）設計だ。CNCF（Cloud Native Computing Foundation）のTAG Infrastructure（技術諮問部会の一つ）が2026年7月8日に公開した白書「Data Storage in Cloud Native AI」は、マイクロサービス時代に固まったK8sストレージの設計前提が、AI/MLワークロードでは通用しない構造を整理している[1]。大量の小ファイル、compute-storage分離のAPIオーバーヘッド、学習と推論で真逆になる要求特性——いずれも「よくあるストレージ設計」の延長では対処しきれない。IT基盤とMBA双方の視点で経営判断に関わる読者にとっても、AI基盤投資の前提となるアーキテクチャ判断として押さえておく価値がある論点だ。
予備知識
- compute-storage分離: 計算資源（GPU/CPUノード）とストレージを別々のコンポーネントとしてスケールできるようにする設計。マイクロサービスでは定番だが、ネットワーク越しのAPI呼び出しが増える
- メタデータサーバ: ファイルの位置や属性情報を集中管理する専用コンポーネント。ファイル数が増えるほど問い合わせが集中する
- 学習ワークロード/推論ワークロード: 学習はモデルを訓練する長時間バッチ処理、推論は学習済みモデルで予測を返す短時間処理
- データローカリティ: 計算資源に近い場所へデータをキャッシュし、遠隔ストレージへのアクセス頻度を減らす考え方
GPU1枚を複数のPodで共有する仕組みが、Kubernetesの標準機能として実装されようとしている。KEP-4815（Kubernetes Enhancement Proposal 4815）は、DRA（Dynamic Reso[…]
大量の小ファイルがメタデータサーバを圧迫する「小ファイルの罠」
AI学習データセットは、画像・トークン化済みテキストなど数百万〜数十億単位の小ファイルで構成されることが多い。白書はこれを「small-file trap（小ファイルの罠）」と呼び、大量の小ファイル群がストレージのメタデータサーバに強い負荷をかける構造を指摘している[1]。
マイクロサービスの世界では、1リクエストあたりのファイルアクセス数は比較的少なく、メタデータサーバへの問い合わせも分散する。AI学習ではエポック（データセット全体を1周する学習単位）ごとに数百万ファイルへのアクセスが発生し、メタデータの問い合わせ自体がボトルネックになりやすい。この負荷はストレージのスループットではなく、メタデータ処理の応答速度で頭打ちになる点が厄介だ。
2026年6月16日、インドの通信キャリアRcom（AS18101、旧Reliance Communications）が、BGP（Border Gateway Protocol、経路情報をAS間で交換するインターネットの基幹プロトコ[…]
compute-storage分離が招くAPIオーバーヘッドとGPU遊休
クラウドネイティブの標準設計であるcompute-storage分離は、計算資源とストレージを独立にスケールできる利点がある一方、AI学習では別の問題を生む。白書は、この分離がAPI呼び出しのオーバーヘッドを増やし、結果としてGPU稼働率の低下につながると指摘している[1]。
一般的なマイクロサービスはリクエスト単位の遅延がミリ秒単位でも許容される場面が多い。だが学習ジョブはGPUという高価なリソースを止めずに動かし続けることが目的であり、ストレージからのデータ供給が追いつかなければGPUは待機状態になる。API呼び出しの往復遅延がGPUコストに直結する点が、通常のマイクロサービス設計との決定的な違いだ。
※本記事は2026年7月時点の情報です。料金・提供条件は変動が速いため、最新は各公式でご確認ください。一部アフィリエイトリンクを含みます。 ✅ 先に結論（Seedance 2.0の要点） 何がすごい[…]
学習と推論で真逆になるI/Oワークロードプロファイル
白書がもう一つ強調するのが、学習と推論でストレージへの要求が構造的に逆転することだ。学習は高スループットを維持し続ける持続的なバッチ処理でGPU稼働率の最大化を狙う一方、推論は低レイテンシでスパイク的な応答が求められる[1]。
同じK8sクラスタ上で学習ジョブと推論サービスを同じストレージ設計で支えようとすると、片方に最適化した構成がもう片方の性能を犠牲にしかねない。この対比を整理したのが次の表だ。
| 観点 | 学習ワークロード | 推論ワークロード |
|---|---|---|
| I/Oパターン | 大容量データを持続的にシーケンシャル読み込み | 小さなリクエスト単位でランダムアクセス |
| 最適化の目的 | GPUスループット（稼働率）の最大化 | レスポンスのレイテンシ最小化 |
| 負荷の形状 | 長時間の安定した高負荷 | スパイク的で予測しにくい負荷 |
| ストレージ要件 | 高帯域なシーケンシャル読み出し | 低レイテンシなランダム読み出し |
表が示すとおり、両者は帯域重視とレイテンシ重視という別方向の最適化を要求する。単一のストレージ構成で両立させるのではなく、ワークロードごとに異なる層を使い分ける発想が必要になる。
データローカリティ層という処方箋
白書は問題の指摘だけでなく、対処の方向性としてデータローカリティ戦略を挙げている。データレイクハウス（Parquet・Icebergなどのオープンフォーマットで統合されたデータ基盤）やベクトルデータベース（Milvusなど、埋め込みベクトルの類似検索を担う）を土台に、キャッシュオーケストレーション層でGPUノードに近い場所へデータを配置する考え方だ[1]。CNCFのインキュベーティングプロジェクトFluidは、AlluxioやJuiceFSのような分散キャッシュを観測可能なサービスへと変換し、データの偏在をスケジューリングに反映させる役割を担う[2]。
この構成のポイントは、ストレージそのものを置き換えるのではなく、既存のオブジェクトストレージとGPUノードの間にキャッシュ層を挟む点にある。メタデータ負荷とAPIオーバーヘッドの両方を、計算資源に近い場所でのキャッシュヒットによって緩和する狙いだ。
まとめ
CNCFの白書が示す核心は、マイクロサービス向けに最適化されたK8sストレージの設計前提が、AI/MLワークロードでは複数の理由から崩れるという点にある。大量の小ファイルがメタデータサーバを圧迫し、compute-storage分離がAPIオーバーヘッドとしてGPU遊休につながり、学習と推論は帯域とレイテンシという逆方向の要求を突きつける。K8s基盤でAI/MLを支えるプラットフォームエンジニアは、既存のストレージ構成を「マイクロサービス時代の前提のまま」流用していないか、ワークロードごとにデータローカリティ層を分けて設計できているかを、現行アーキテクチャの棚卸しの着眼点にしてほしい。
よくある質問（FAQ）
compute-storage分離はAI基盤では避けるべきか
分離自体を避ける必要はない。スケーラビリティの利点は保ちつつ、API呼び出しの往復遅延がGPU稼働率に与える影響を測定し、キャッシュ層で緩和する設計を組み合わせることが現実的な対処になる。
学習用と推論用でストレージを完全に分ける必要があるか
物理的なストレージ製品を分ける必要は必ずしもないが、帯域重視とレイテンシ重視という異なる最適化目標を同じ構成で両立させるのは難しい。ワークロードごとにキャッシュ層やアクセスパターンを分離して設計する発想が有効だ。
小ファイルの罠にはどう対処すればよいか
ファイル単位のメタデータ問い合わせを減らす方向、たとえば複数ファイルをまとめたフォーマットへの変換や、メタデータ負荷を吸収するキャッシュ・オーケストレーション層の導入が、白書が示す方向性に沿った対処になる[1][2]。
