デザインツール
ストレージ

AI/MLワークロード向けマイクロン製SSDへの投資を最大化する

ウェス・バスク | 2020年7月

NVIDIA GPUDirect Storageで、AI/MLワークロード向けマイクロン製SSDへの投資を最大化する

はじめに

マイクロンは人工知能(AI)がもたらす多大なイノベーションに大いに期待しています。そのような期待の下、マイクロンはこれまで、フラッシュがAIアプリケーションに与えられる影響や、その他の優れたテクノロジー(ハードウェアとソフトウェア)と連携してAIによるイノベーションを加速させる方法について積極的に追求してきました。

最近、マイクロンのラボでNVIDIA GPUDirect Storageソフトウェアの早期リリースを試用する機会があったのですが、とても素晴らしい結果が得られました。結果について触れる前に、その背景を簡単にご説明します。

2007年以来、NVIDIA CUDAはコンピューティング性能が求められるさまざまな作業をGPUによって高速化してきました。さらに、2014年にGPUDirect RDMAが導入されたことで、GPUとさまざまなPCIeアダプター(ネットワークインターフェースカード、ストレージコントローラ、ビデオキャプチャデバイスなど)との間でデータを直接移動できるようになりました。GPUDirect StorageによってGPUDirect RDMAとCUDAが拡張され、ストレージデバイス(NVMe SSDなど)からGPUメモリスペースにデータを直接移動できるように対応しました。この更新のおかげで、実質的に、CPUシステムメモリ(I/Oバッファリングに使用)へのデータ移動(従来のストレージI/O構成で必須のステップ(図1))がなくなります。

データパスに関するGPUDirect Storageの有無の比較を示す図 図1:データパスに関するGPUDirect Storageの有無の比較

ただし、最近まで、多くの標準的なデータサイエンスライブラリはGPUアクセラレーションに対応していませんでした。実際のところ、主流のPythonデータサイエンスライブラリ(NumPy、Pandas、scikit-learn)にはネイティブGPUアクセラレーションがないうえ、一部にはそのようなアクセラレーションを開発しないという具体的な計画もありました。 

他のライブラリは、Pandas、NumPyscikit-learnとの互換性を保ちながらGPUのサポートを可能にしようと試みているものの、GPUに対応するライブラリセットはこれまで存在しませんでした。現在では、CUDAをベースとするRAPIDSオープンソースソフトウェアライブラリが導入されたことで、エンドツーエンドのデータサイエンスと分析パイプラインを完全にGPUで実行可能にするオープンソースライブラリとAPIを利用できるようになりました。

そのようなGPUによって高速化された新しいRAPIDSライブラリやその他のライブラリは、非高速化ライブラリの数倍のコンピューティングパフォーマンスを発揮するものの、ストレージI/Oがボトルネックとなっています。GPUDirect Storageが特に役立つ領域です。

論理的には、これは簡単に解決できる問題です(NVMeドライブ、NIC、HBAにはすべて、GPUメモリアドレスへのデータの直接送信に対応するDMAエンジンが備わっています)。しかし、実際の導入はもっと複雑です。GPUDirect Storageの紹介記事など、NVIDIAのブログや広報をご確認ください。さらに、RAPIDSはGPUDirect Storageのユースケースの1つであり、考えられる多くの導入の1つでしかありません。

それでは、実際のシステムでのテストを用いて、GPUDirect Storageによるパフォーマンスの向上についてご説明します。

テスト構成

ここでご紹介するすべてのテストでは、8つのNVIDIA V100 GPU、2つのIntel Xeon 8180M CPU(各28コア)、8つのMicron 9300 Pro 15.36TB NVMe SSDを搭載したSuperMicro SYS-4029GP-TVRTを使用しています。システムの具体的な配置は図2をご覧ください。

SuperMicro SYS-4029GP-TVRTのPCIe配置 図2:SuperMicro SYS-4029GP-TVRTのPCIe配置

テストに使用したSuperMicro SYS-4029GP-TVRTには、NVMe SSDがCPUと直接接続されているという面白いアーキテクチャー上の特徴があります。この独特なシステムにより、ローカルNVMeよりもリモートストレージ(例:NVMe over Fabricsを介したアクセス)を用いる方が、スループットが向上する可能性があります。その理由を以下にご説明します。NICには、NVMeドライブの2倍のPCIeレーンが使われています。GPUDirect StorageはDMAを使用してストレージデバイスからGPUに直接データを送るため、RDMAやNVMe-oFも使用できます。高性能なネットワークインターフェースからPCIeスイッチを介してそれらのデバイスにアクセスすると、このサーバーで必要となるようにストレージデバイスからCPUを介して直接接続する場合よりも、多くのデータを送信できます。将来的には、GPUと同じPCIeスイッチに接続されたネットワークアダプターを介してアクセスされるリモートストレージにより、GPUDirect Storageのパフォーマンスを追求していく予定ですが、このテストのデータではローカルNVMeについてのみ取り上げます。

パフォーマンスの結果
4KBランダム読み取りパフォーマンス

基本的な4KBランダム読み取りワークロードから開始します。このテストでは、各GPUがMicron 9300 NVMe SSDの1TBのファイルから読み取りを行います。1対1の関係があり、各GPUが単一のNVMeドライブから排他的に読み取りを行います。この関係が本番システムの構成で用いられるとは限りませんが、ラボでは、多数のGPUとSSDをテストしやすくするため、この構成を用いています。本番システムの場合、単一のCPUで動作するすべてのドライブを単一のRAIDグループに構成します。

 

4KBI/O送信のスループットとCPU負荷を示すグラフ 図3:4K I/O送信サイズのデータパス別、8つのGPUのGPUとNVMeのペアあたりのワーカー数によるCPU使用量とスループット

図3を見ると、CPUの「バウンスバッファ」を使用する従来のデータパスに比べて、GPUDirect Storageがパフォーマンスに大きな影響を与えていることが分かります。ワーカー数が少ない場合、GPUDirect Storageのパスの方ががやや高速で、CPU使用量はわずかに優れています。ワーカー数が増加するとともに、GPUDirect Storageのメリットは大幅に増大していきます。この構成では、GPUDirect StorageはCPU使用量を6未満のCPUコアと同等に保ちながら(緑色の線、右軸)、8.8GB/秒のスループットのピークに達しています(64個のワーカーの青色のバー)。対照的に、従来のパスは2.24GB/秒でピークに達し(12個のワーカーの灰色のバー)、ワーカー数の増加による負荷でパフォーマンスが低下し、CPU使用量が増加します(黒色の線、右軸)。これは、96個のワーカーで52個のすべてのCPUコアをロードし、ワーカー数が96場合と同等です。

データ送信サイズがパフォーマンスに与える影響

次に、データ送信サイズがパフォーマンスを与える影響についてご説明します。このテストでは、GPUとNVMeのペアごとに16個のワーカーを使用します。前述の4KB I/Oテストの結果を基に16個のワーカーをピックアップすると、従来のデータパスの場合、16個のワーカーはピークをわずかに超え、GPUDirect Storageよりもかなり前にピークに達しています。

16個のワーカーのスループットとCPU負荷を示すグラフ 図4:GPUとNVMeのペアあたり16個のワーカーのデータパスによる8個のGPUのI/O送信サイズ別のCPU使用量とスループット

図4を見ると、I/O送信サイズを増加した場合、従来のデータパスに固有の制限が緩和されることが分かります。送信サイズが大きくなるほど、スループットとCPU使用量が実質的に同等になります。残念ながら、多くの場合、ストレージにアクセスするすべてのワークロードが常に大きなデータ送信サイズを用いるように確保することは困難です。そのため、小規模から中規模の送信の場合も上記と同じく、GPUDirect Storageを使用するとスループットが大幅に向上し、それに応じてCPU使用量も向上します。

I/Oレイテンシー

I/Oレイテンシーもパフォーマンスの重要な要素です。I/Oレイテンシーについて以下にご説明します。このテストでも16個のワーカーに注目し、I/O送信サイズを変化させます。

16個のワーカーのスループットとレイテンシーを示すグラフ 図5:GPUとNVMeのペアあたり16個のワーカーのデータパスによる8個のGPUのI/O送信サイズ別のレイテンシーとスループット

スループットとCPU使用量の場合と同様に、GPUDirect Storageデータパスのレイテンシーは小規模から大規模の送信サイズで大幅に向上し、大規模な送信サイズでは従来のデータパスと実質的に同等になりました(図5)。ここではマイクロ秒(µs)単位でレイテンシーを表示しています。GPUDirect Storageの値は脅威的です。4KB送信の平均レイテンシーは116µsで、32KB送信でも203µsにしか増加しません。レイテンシーの影響が大きいワークロードの場合、アプリケーションのパフォーマンスに大幅に影響する可能性があります。32KB送信を超えると、小規模なI/O送信の場合と同様に、レイテンシーはデータアクセスのオーバーヘッドではなく、データ送信時間が影響するようになります。

まとめ

小規模と中規模のブロックサイズでは、GPUDirect Storageにより、合計スループットが大幅に向上し、レイテンシーが大幅に低下し、必要なCPUコア数も大幅に減少します。それらの向上効果のいずれかを考慮するだけでも、GPUアクセラレーションが必要なアプリケーションでGPUDirect Storageを検討する価値が高まります。そして、すべての向上効果が合わせることでGPU I/O環境が階段関数的に変化します。今回のテストでは、大規模なブロック送信の場合は小規模や中規模のようなメリットは得られませんでしたが、従来のデータパスではなくGPUDirect Storageを採用した場合のメリットはありません。

NVIDIAのGPUDirect StorageとマイクロンのデータセンターSSDを組み合わせることで、AIソリューションを加速し、より多くの作業を短時間で行えるようになります。マイクロンとNVIDIAがAIソリューションの導入にどう役立つかについては、以下のリソースが参考になります。

SMTS Systems Performance Engineer

Wes Vaske

Wes Vaske is a principal storage solution engineer with Micron.