• 何が起きた: NetAppが9月29日、メタデータ処理と実データの読み書きを分離したAI向けストレージアーキテクチャ「NetApp Novus」を発表した。
  • なぜ重要か: 大量のファイル操作を処理する能力と、大容量データを転送する帯域を別々に増強できるため、ストレージ待ちによるGPUの停止時間を減らすことを狙っている。
  • 次に見るべき点: 100TB/sは大規模な実機構成で測定した値ではなく、拡張試験を基にした予測を含む。実際のAI環境で読み出しとチェックポイント書き込みが重なった際の性能や、初期提供される認定構成でどこまで拡張できるかが焦点となる。

NetAppは2026年9月29日、ラスベガスで開催した「INSIGHT 2026」で、AI向けの新しいストレージアーキテクチャ「NetApp Novus」を発表した。

ファイルの場所などを管理するメタデータ処理と、データ本体の読み書きを担う処理を分離し、大規模なGPU環境でそれぞれを独立して拡張できるようにする。

主な対象は、GPUを大量に運用するネオクラウドやGPU-as-a-Service事業者、ハイパースケーラーなどの「AIファクトリー」だ。

NetAppは100TB/sを超える読み出し帯域への拡張を掲げるが、重要なのは単純な最高速度だけではない。大量の小さなファイル操作と、巨大なチェックポイントの書き込みが同時に発生するAI基盤で、片方の処理がもう片方を妨げないようにすることがNovusの狙いだ。

AD

メタデータ処理とデータ転送を分ける

AIモデルの学習では、性質の異なるストレージ処理が同時に発生する。

学習データを読み込む際には、大量のファイルを開き、その場所や属性を調べる処理が必要になる。こうした処理では、ファイル名や配置などを管理する「メタデータ」への細かな要求が大量に発生する。

一方、学習途中の状態を保存するチェックポイントでは、複数の計算ノードからテラバイト規模のデータを一斉に書き込むことがある。

NetAppのArindam Banerjee氏は公式ブログで、この二つを同じコントローラーで処理すると互いに性能を奪い合うと説明している。

大量のSSDを追加して保存容量や最大帯域を増やしても、ファイルの場所を調べる処理が詰まれば、GPUへデータを渡す前に待ち時間が発生する。

つまり、保存容量、データ転送帯域、同時に処理できるファイル操作の数は、別々の性能として考える必要がある。

Novusでは、メタデータ処理を「Novus Data Director」と呼ばれるソフトウェアへ分離する。

データ本体は、NetAppのストレージOS「ONTAP」を利用するデータノードに保存する。初期構成では、Data Directorを認定済みのSupermicroサーバーで動かし、データノードにはNetApp AFF A90を使用する。

製品説明資料では、GPUサーバー側のクライアントがまずData Directorへファイルの配置情報を問い合わせ、その情報を受け取った後、データノードへ直接アクセスする構成が示されている。

データそのものをData Director経由で転送しないため、メタデータ処理能力とデータ転送帯域をそれぞれ独立して増強できる。

さらに、複数のストレージシステムを一つの「名前空間」にまとめる。

名前空間とは、利用者から見たファイルのパス体系を指す。ストレージを追加するたびに別の保存先としてマウントするのではなく、同じファイルシステムとして見せたまま、容量や帯域を増やすことを狙っている。

既存のpNFSを大規模AI基盤に利用

メタデータと実データへのアクセスを分離する考え方そのものは、新しく登場したものではない。

2018年に公開されたIETFのRFC 8435では、pNFS（Parallel NFS）の「Flexible File Layout」が標準化されている。

pNFSでは、クライアントがメタデータサーバーからファイルの配置情報を受け取り、その後はデータサーバーへ直接アクセスできる。

NetAppの既存ONTAPの管理文書でも、pNFSを利用して複数のストレージへ並列にアクセスする仕組みが説明されている。

したがってNovusの新しさは、メタデータとデータを分ける仕組みそのものを発明したことではない。

専用のメタデータ層と複数のONTAPストレージを組み合わせ、大規模なAI基盤向けにそれぞれを独立して拡張できる製品構成として提供する点にある。

GPUサーバー側では、Linuxカーネルに組み込まれたNFSv4.2とpNFS Flex Filesを利用する。

Novusの製品ページでは、複数の接続を使って帯域を広げるnconnectや、ストレージとGPUメモリの間で効率的にデータを転送するGPUDirect Storageにも対応すると説明している。

NetAppが強調する利点の一つは、GPUサーバーへNovus専用の独自クライアントを配布する必要がないことだ。

数千、数万台のGPUサーバーを運用する環境では、独自ソフトウェアをすべてのノードへ配布し、LinuxカーネルやGPUの世代が変わるたびに検証する作業も大きな負担になる。

既存の標準技術を使うことで、その作業を減らすことが狙いだ。

ただし、何も設定せずに利用できるという意味ではない。

対応するLinux環境の確認やネットワーク設定、GPUDirect Storageを利用するための構成などは必要になる。初期提供されるハードウェアも認定済みの構成に限られる。

また、製品説明資料では、Novusが利用するストレージ側のネットワークと、GPU同士が学習結果を交換するバックエンドネットワークを別々に描いている。

学習データをストレージからGPUへ届ける経路と、GPU間で勾配などを同期する通信経路は別である。

そのため、Novus導入後のGPU待ち時間を評価する際も、ストレージI/Oが原因の待機と、GPU間通信が原因の待機を分けて考える必要がある。

AD

「100TB/s」は何を意味するのか

NetAppが掲げる100TB/sについては、実際に測定した結果と、そこから予測した値を分けて見る必要がある。

NetAppの発表文には、OmdiaのTony Palmer氏による評価が掲載されている。

Omdiaは、単一の名前空間にONTAPクラスターを追加していく試験を監査し、クラスターを増やすにつれて性能がほぼ線形に伸びることを確認したという。

その結果を基にしたモデルから、Novusが100TB/sの連続読み出し帯域まで拡張できると予測している。

つまり、100TB/sという数字は、100TB/s規模の完成したシステムで実際のAI学習を動かし、その性能を測定したベンチマークではない。

ゼタバイト規模への対応についても同様で、アーキテクチャとして目指す拡張範囲を示したものであり、ゼタバイト級の実運用システムがすでに確認されたという意味ではない。

GPUの台数についても数字の読み方に注意が必要だ。

NetAppは公式ブログで、GPU 1基が最大約2GB/sのストレージ帯域を必要とする場合、5万基へ同時に供給するには合計100TB/sが必要になると説明している。

製品ページでも「5万基以上のGPU」「約2GB/s」「100TB/s」という数字を並べている。

単純に総帯域をGPUへ均等配分した場合は、次のようになる。

同時に帯域を利用するGPU数（仮定） 総読み出し帯域 GPU 1基当たりの帯域
5万基 100TB/s 2GB/s
10万基 100TB/s 1GB/s
100万基 100TB/s 0.1GB/s

ここでは1TB＝1,000GBとして、100TB/sを100,000GB/sに換算している。すべてのGPUが同時に同じ帯域を利用すると仮定した単純計算であり、実際の導入環境を再現したものではない。

NetAppは別の説明で「数十万」あるいは「数百万」のGPUを支えられる規模にも言及しているが、これは「すべてのGPUへ常時2GB/sを供給する」という意味ではない。

必要なストレージ帯域は、学習するモデル、データ形式、キャッシュの使い方、チェックポイントの頻度などによって大きく変わる。

したがって、GPUの台数だけでストレージ性能を評価することはできない。

さらに、100TB/sという連続読み出し性能だけでは、Novusの設計上の特徴を十分に評価できない。

大量の小さなファイルを開く処理と、大規模なチェックポイント書き込みを同時に実行した場合に、それぞれの待ち時間がどれだけ増えるのかが重要になる。

こうした混在した負荷でメタデータ処理とデータ転送の干渉をどこまで抑えられるかを確認できれば、Novusの分離型アーキテクチャが実際のAI学習時間をどれだけ短縮できるかを判断しやすくなる。

AFXとNovusでは、分離しているものが違う

NetAppには、すでに「AFX」と呼ばれる分離型のAI向けストレージがある。

ただし、AFXの公式アーキテクチャ資料で説明されている「分離」と、Novusで行われる分離は対象が異なる。

設計上の違い AFX Novusの初期構成
主に分離するもの ストレージのコントローラーノードとSSDを収めるストレージシェルフ メタデータ処理と実データを処理するストレージ
データへのアクセス コントローラーが共通のストレージプールへアクセス Data Directorから配置情報を受け取り、クライアントがAFF A90へ直接アクセス
拡張するときの考え方 処理能力が必要ならコントローラー、容量が必要ならシェルフを追加 メタデータ処理能力と、データ側の容量・帯域を独立して追加

この表は設計思想の違いを整理したもので、AFXとNovusの性能を比較するものではない。

AFXでは、処理を担うコントローラーとSSD容量を切り離し、それぞれを必要に応じて追加できる。

Novusではさらに上の階層で、複数のONTAPストレージを一つの名前空間へまとめるメタデータ処理を、データ転送から切り離している。

同じ「分離型」という言葉を使っていても、解決しようとしているボトルネックは異なる。

Novusは9月29日の発表時点で注文可能とされている。

初期構成では、Novus Data Directorを認定済みのSupermicroサーバーで動かし、データ層にはNetApp AFF A90を利用する。

一方、製品説明資料では、将来的にメタデータサービスとONTAPベースのデータサービスの双方を、認定された第三者製ハードウェアで動かすソフトウェア定義型の構成も検討している。

現在購入できる構成と、将来提供を予定している構成は分けて考える必要がある。

AIファクトリーの運営者が導入前に確認したいのは、最大帯域だけではなく、自社の実際のAIワークロードを使った混在負荷での性能だ。

大量のファイルを開く処理とチェックポイントの書き込みを同時に発生させ、GPUがストレージを待つ時間がどの程度変わるかを測る。

さらに、複数の利用者やジョブが同時にストレージを利用した場合の性能や、障害発生時の復旧も確認する必要がある。

単純にストレージの最大帯域を増やすだけでは解消できなかった待ち時間を減らせるのであれば、Novusの分離型アーキテクチャは、GPUを追加する前に既存のGPUをより長く計算へ使うための手段になり得る。