人工知能（AI）と機械学習（ML）のワークロードに Google Cloud ストレージ サービスを選択する場合は、ジョブごとに適切なストレージ オプションの組み合わせを選択するように配慮する必要があります。たとえば、データセットのアップロード、モデルのトレーニングとチューニング、本番環境へのモデルの配置、アーカイブへのデータセットとモデルの保存でストレージを慎重に選択する必要があります。要するに、AI ワークロードと ML ワークロードの各ステージで、レイテンシ、スケール、費用が適切になるように最適なストレージ サービスを選択する必要があります。
このドキュメントでは、十分な情報に基づいて判断できるように、Google Cloud のさまざまなストレージ オプションを主な AI ワークロードと ML ワークロードに統合する際の設計上のガイダンスを提供します。
図 1 は、プライマリ ストレージの選択の概要を示しています。この図に示すように、ファイルサイズが大きい場合、1 秒あたりの入出力オペレーション数（IOPS）が少ない場合、またはレイテンシが大きい場合は、Cloud Storage を選択します。逆に、高い IOPS、小さいファイルサイズ、または低レイテンシが必要な場合は Filestore を選択します。
図 1: AI と ML のプライマリ ストレージに関する考慮事項
AI / ML ワークロードのステージの概要
AI ワークロードと ML ワークロードは、準備、トレーニング、サービング、アーカイブの 4 つの主要なステージで構成されます。AI と ML のワークロードのライフサイクルで、この 4 つのステージごとにストレージ オプションを検討する必要があります。ほとんどの場合は、準備ステージで選択したストレージを残りのステージでも使用することをおすすめします。この推奨事項に従うことで、ストレージ サービス間でのデータセットのコピーを減らすことができます。ただし、この一般的なルールにはいくつかの例外があります。詳しくは、このガイドの後半で説明します。
各ステージには他のソリューションよりも優れたパフォーマンスを発揮するストレージ ソリューションがあります。最適な結果を得るために、別のストレージ オプションとの併用が必要になることもあります。どのストレージを選択するのが効果的かは、データセットのプロパティ、必要なコンピューティング リソースとストレージ リソースの規模、レイテンシなどの要因によって異なります。次の表に、各ステージと、そのステージにおすすめのストレージの概要を示します。この表をビジュアルに表現したディシジョン ツリーもご覧ください。
表 1: AI / ML ワークロードのステージとステップにおけるストレージの推奨事項
| ステージ | ステップ | ストレージに関する推奨事項 |
|---|---|---|
準備 |
データの準備
|
Cloud Storage
Filestore Zonal
|
トレーニング |
|
Cloud Storage
Cloud Storage（ローカル SSD または Filestore）
Filestore
|
|
Cloud Storage
Filestore Zonal
|
|
サービング |
|
Cloud Storage
Filestore
|
アーカイブ |
|
Cloud Storage
|
この表の基本的な前提条件については、次のセクションをご覧ください。
条件
AI / ML ワークロードに使用するストレージ オプションを絞り込むには、まず、次のことを考えてみてください。
- AI / ML の I/O リクエスト サイズとファイルサイズは小さい、中程度、大きい、のどれか
- AI / ML ワークロードは、I/O レイテンシと Time To First Byte（TTFB）の影響を受けやすいか
- 単一のクライアント、集約クライアント、またはその両方に高い読み取り / 書き込みスループットが必要か
- 最も大きい単一の AI / ML トレーニング ワークロードに必要な Cloud GPU または Cloud TPU の最大数はいくつか
このほかにも、AI / ML ワークロードを最適化するために選択できるコンピューティング オプションとアクセラレータについても理解する必要があります。
コンピューティング プラットフォームの考慮事項
Google Cloud では、AI / ML ワークロードを実行するために、主に次の 3 つの方法をサポートしています。
- Compute Engine: 仮想マシン（VM）は、すべての Google マネージド ストレージ サービスとパートナー サービスをサポートしています。Compute Engine は、ローカル SSD、Persistent Disk、Cloud Storage、Cloud Storage FUSE、NetApp Volumes、Filestore をサポートしています。Google では、Compute Engine の大規模トレーニング ジョブのため、SchedMD と提携して Slurm スケジューラの拡張機能を提供しています。
Google Kubernetes Engine（GKE）: GKE は、一般的なフレームワーク、ワークロード、データ処理ツールと統合される人気の AI 用プラットフォームです。GKE では、ローカル SSD、永続ボリューム、Cloud Storage FUSE、Filestore のサポートを提供します。
Vertex AI: Vertex AI は、AI / ML ワークロードにエンドツーエンドのソリューションを提供するフルマネージド AI プラットフォームです。Vertex AI は、Cloud Storage とネットワーク ファイル システム（NFS）のファイルベースのストレージ（Filestore や NetApp Volumes など）をサポートしています。
Compute Engine と GKE の場合は、Cluster Toolkit を使用して Google Cloud のベスト プラクティスに準拠している再現可能なターンキー クラスタをデプロイすることをおすすめします。
アクセラレータに関する考慮事項
AI / ML ワークロードのストレージを選択する際には、タスクに適したアクセラレータ処理オプションも選択する必要があります。Google Cloud では、NVIDIA Cloud GPU とカスタム開発の Google Cloud TPU の 2 つのアクセラレータを選択できます。どちらのアクセラレータも、標準プロセッサよりも効率的に ML ワークロードを処理するために使用される特定用途向け集積回路（ASIC）です。
Cloud GPU と Cloud TPU アクセラレータには、ストレージに関する重要な違いがいくつかあります。Cloud GPU を使用するインスタンスは、リモート ストレージ スループットが最大 200 GBps のローカル SSD をサポートしています。Cloud TPU ノードと VM はローカル SSD をサポートしていません。リモート ストレージ アクセスにのみ依存しています。
アクセラレータ最適化マシンタイプの詳細については、アクセラレータ最適化マシン ファミリーをご覧ください。Cloud GPU の詳細については、Cloud GPU プラットフォームをご覧ください。Cloud TPU の詳細については、Cloud TPU の概要をご覧ください。Cloud TPU と Cloud GPU のどちらを選択するべきかは、Cloud TPU を使用するタイミングをご覧ください。
ストレージ オプション
表 1 で説明したように、AI / ML ワークロードでオブジェクト ストレージまたはファイル ストレージを使用し、このストレージ オプションをブロック ストレージで補完します。図 2 に、AI / ML ワークロードの初期ストレージを選択する際に検討すべき一般的なオプション（Cloud Storage、Filestore、Google Cloud NetApp ボリューム）を示します。
図 2: Google Cloud が提供する AI / ML に適したストレージ サービス
オブジェクト ストレージが必要な場合は Cloud Storage を選択します。Cloud Storage は次のものを提供します。
- 非構造化データとオブジェクトの保存場所。
- Cloud Storage JSON API などの API。
- データを保存する永続ストレージ。
- テラバイト/秒のスループット。ただし、より高いストレージ レイテンシが必要。
ファイル ストレージが必要な場合は、Filestore と NetApp Volumes のいずれかを選択します。これらは次のものを提供します。
- Filestore
- 高性能な NFS ベースのエンタープライズ ファイル ストレージ。
- データを保存する永続ストレージ。
- 低いストレージ レイテンシと 26 Gbps のスループット。
- NetApp Volumes
- NFS とサーバー メッセージ ブロック（SMB）に互換性のあるファイル ストレージ。
- NetApp ONTAP ストレージ ソフトウェア ツールを使用するオプションで管理できます。
- データを保存する永続ストレージ。
- スループットは 4.5 GBps。
AI / ML ワークロードには、次のストレージ オプションを優先的に使用してください。
AI / ML ワークロードを補完するには、次のストレージ オプションを使用します。
これらのストレージ オプション間でデータを転送する必要がある場合は、データ転送ツールを使用できます。
Cloud Storage
Cloud Storage は、非構造化データのデータ準備、AI モデルのトレーニング、データのサービング、バックアップ、アーカイブに重点を置いたフルマネージド オブジェクト ストレージ サービスです。Cloud Storage の利点は次のとおりです。
- グローバルでエクサバイトまで拡張可能な無制限のストレージ容量
- 超高スループット
- AI / ML ワークロード用のリージョンおよびデュアルリージョン ストレージ オプション
Cloud Storage のスループットは 1 秒あたり数テラバイトまで拡張されますが、Filestore やローカル ファイル システムよりもレイテンシが長くなります（数十ミリ秒）。個々のスレッドのスループットは 1 秒あたり約 100～200 MB に制限されています。つまり、高スループットを実現するには、数百から数千の個々のスレッドを使用する必要があります。また、高スループットを実現するには、大容量のファイルと大容量の I/O リクエストを使用する必要があります。
Cloud Storage は、さまざまなプログラミング言語のクライアント ライブラリをサポートしていますが、Cloud Storage FUSE もサポートしています。Cloud Storage FUSE を使用すると、Cloud Storage バケットをローカル ファイル システムにマウントできます。Cloud Storage FUSE を使用すると、アプリケーションで標準のファイル システム API を使用して、バケットからの読み取りやバケットへの書き込みを行うことができます。Cloud Storage のスケール、アフォーダンス、パフォーマンスで、トレーニング データ、モデル、チェックポイントを保存してアクセスできます。
Cloud Storage の詳細については、次のリソースをご覧ください。
Filestore
Filestore は、フルマネージドの NFS ファイルベースのストレージ サービスです。AI / ML ワークロードに使用される Filestore サービスティアには、次のものが含まれます。
- エンタープライズ ティア: リージョンの可用性を必要とするミッション クリティカルなワークロードに使用されます。
- ゾーンティア: 高い IOPS とスループット パフォーマンス要件でゾーンの可用性を必要とする構成のアプリケーションに使用されます。
- ベーシック ティア: ファイル共有、ソフトウェア開発、ウェブ ホスティング、基本的な AI / ML ワークロードに使用されます。
Filestore は、低レイテンシの I/O パフォーマンスを提供します。I/O のアクセス要件が小さいデータセットや、ファイルが小さいデータセットに適しています。ただし、Filestore では、必要に応じて大規模な I/O や大規模なファイルのユースケースも処理できます。Filestore は最大約 100 TB までスケールアップできます。データを繰り返し読み取る AI トレーニング ワークロードでは、ローカル SSD で FS-Cache を使用すると、読み取りスループットを向上させることができます。
Filestore の詳細については、Filestore の概要をご覧ください。Filestore サービスティアの詳細については、サービスティアをご覧ください。Filestore のパフォーマンスの詳細については、インスタンスのパフォーマンスを最適化してテストするをご覧ください。
Google Cloud NetApp Volumes
NetApp Volumes は、NFS、SMB、マルチプロトコル環境をサポートする高度なデータ管理機能を備えたフルマネージド サービスです。NetApp Volumes は、低レイテンシ、マルチテビバイト ボリューム、ギガバイト/秒のスループットをサポートしています。
NetApp Volumes の詳細については、Google Cloud NetApp Volumes とはをご覧ください。NetApp Volume のパフォーマンスの詳細については、想定されるパフォーマンスをご覧ください。
ブロック ストレージ
プライマリ ストレージを選択した場合、ブロック ストレージでパフォーマンスを補完し、ストレージ オプション間でデータを転送して、低レイテンシのオペレーションを利用できます。ブロック ストレージには、ローカル SSD と Persistent Disk の 2 つのストレージ オプションがあります。
ローカル SSD
ローカル SSD は、VM またはコンテナにローカル ストレージを直接提供します。Cloud GPU を含むほとんどの Google Cloud マシンタイプには、ローカル SSD が含まれています。ローカル SSD ディスクは Cloud GPU に物理的にアタッチされるため、数百万の IOPS でも低レイテンシのアクセスが可能になります。一方、Cloud TPU ベースのインスタンスにはローカル SSD は含まれません。
ローカル SSD は高パフォーマンスですが、ストレージ インスタンスは一時的なものです。したがって、ローカル SSD ドライブに保存されたデータは、インスタンスを停止または削除すると失われます。ローカル SSD はエフェメラルな性質を持つため、データの耐久性を高める必要がある場合は、他のタイプのストレージを検討してください。
ただし、トレーニング データの量が非常に少ない場合は、トレーニング データを Cloud Storage から GPU のローカル SSD にコピーするのが一般的です。これは、ローカル SSD を使用すると I/O レイテンシが短くなり、トレーニング時間が短くなるためです。
ローカル SSD の詳細については、ローカル SSD についてをご覧ください。Cloud GPU インスタンス タイプで使用可能なローカル SSD の容量の詳細については、GPU プラットフォームをご覧ください。
Persistent Disk
Persistent Disk は、データの永続化と管理の包括的なスイートを備えたネットワーク ブロック ストレージ サービスです。Persistent Disk は、ブートディスクとして使用するだけでなく、スクラッチ ストレージなどの AI ワークロードでも使用できます。Persistent Disk は次のオプションで使用できます。
- Standard: 効率的で信頼性の高いブロック ストレージを提供します。
- Balanced: 費用対効果に優れた信頼性の高いブロック ストレージを提供します。
- SSD: 高速で信頼性の高いブロック ストレージを提供します。
- Extreme: IOPS のカスタマイズが可能で、最高水準のパフォーマンスを実現するブロック ストレージを提供します。
Persistent Disk の詳細については、Persistent Disk をご覧ください。
データ転送ツール
AI / ML タスクを実行する際に、ロケーション間でデータをコピーしなければならない場合があります。たとえば、データが Cloud Storage にある場合は、モデルのトレーニングのために別の場所に移動し、チェックポイント スナップショットまたはトレーニング済みモデルを Cloud Storage にコピーします。Filestore でほとんどのタスクを実行し、データとモデルを Cloud Storage に移動してアーカイブすることもできます。このセクションでは、Google Cloud のストレージ サービス間でデータを移動する方法について説明します。
Storage Transfer Service
Storage Transfer Service を使用すると、Cloud Storage、Filestore、NetApp Volumes の間でデータを転送できます。このフルマネージド サービスを使用すると、オンプレミスのファイル ストレージとオブジェクト ストレージ リポジトリ、Google Cloud ストレージ、他のクラウド プロバイダ間でデータをコピーすることもできます。Storage Transfer Service を使用すると、ソースのロケーションからターゲット ロケーションにデータを安全にコピーできるだけでなく、変更されたデータの定期的な転送も行うことができます。また、データの整合性検証、自動再試行、ロード バランシングも行います。
Storage Transfer Service の詳細については、Storage Transfer Service とはをご覧ください。
コマンドライン インターフェース
Filestore と Cloud Storage の間でデータを移動する場合は、Google Cloud CLI を使用する必要があります。gcloud CLI を使用すると、一連のコマンドを使用して、最適なスループットで Cloud Storage バケットとオブジェクトを作成し、管理できます。
ストレージの選択肢を AI / ML のステージにマッピングする
このセクションでは、表 1 の内容を詳しく説明し、AI / ML ワークロードの各ステージに関する具体的な推奨事項とガイダンスを説明します。これらの選択の根拠を理解し、AI / ML の各ステージに最適なストレージ オプションを選択できるようにすることが目標です。この分析の結果、3 つの主な推奨事項が得られます。詳細については、AI と ML 向けのストレージの推奨事項のセクションで説明します。
次の図は、AI / ML のワークロードの 4 つの主要なステージに推奨されるストレージ オプションを示したディシジョン ツリーです。図の後に、各ステージの詳細な説明と、各ステージで選択できるオプションについて説明します。
図 3: AI / ML の各ステージに適したストレージ
準備
この最初のステージでは、永続的で信頼できる情報源として Cloud Storage と Filestore のどちらを使用するかを選択する必要があります。データ集約型トレーニングの潜在的な最適化を選択することもできます。組織内のチームごとにワークロードやデータセットの種類が異なるため、チームごとに異なるストレージ オプションが存在する可能性があります。このようなさまざまなニーズに対応するために、Cloud Storage と Filestore のストレージを適宜組み合わせて使用できます。
準備ステージに Cloud Storage を使用する
- ワークロードには 50 MB 以上の大きなファイルが含まれています。
- ワークロードで IOPS を下げる必要があります。
ワークロードは、数十ミリ秒という高いストレージ レイテンシを許容できます。
Cloud Storage API、または Cloud Storage FUSE とファイル API のサブセットを介して、データセットにアクセスする必要があります。
Cloud Storage のワークロードを最適化するには、リージョン ストレージを選択し、コンピューティング リソースと同じリージョンにバケットを配置します。ただし、信頼性を高める必要がある場合や、2 つの異なるリージョンにあるアクセラレータを使用する場合は、デュアルリージョン ストレージを選択することをおすすめします。
準備ステージに Filestore を使用する
次のいずれかの条件に該当する場合は、データの準備に Filestore を選択する必要があります。
- ワークロードに 50 MB 未満の小さいファイルが含まれている。
- より高い IOPS が必要なワークロード。
- ランダム I/O とメタデータ アクセスのストレージ要件を満たすため、ワークロードが 1 ミリ秒未満の低レイテンシが必要。
- データを表示して管理するために、POSIX を完全にサポートするデスクトップのようなエクスペリエンスが必要。
- ユーザーはソフトウェア開発などの他のタスクを行う必要があります。
準備ステージに関するその他の考慮事項
このステージで選択肢を決めるのが難しい場合は、次の点を考慮して決定してください。
- データセットで Dataflow、Spark、BigQuery などの他の AI / ML フレームワークを使用する場合は、これらのフレームワークとカスタム統合が可能な Cloud Storage が適しています。
- Filestore の最大容量は約 100 TB です。これより大きいデータセットでモデルをトレーニングする必要がある場合、またはセットを複数の 100 TB のインスタンスに分割できない場合は、Cloud Storage のほうが適しています。
データ準備フェーズでは、多くのユーザーがデータを大きなチャンクに再編成してアクセス効率を高め、ランダムな読み取りリクエストを回避します。多くのユーザーは、ストレージ システムの I/O パフォーマンス要件をさらに削減するために、パイプライン化やトレーニングの最適化を使用して I/O スレッドの数を増やします。
トレーニング
通常、トレーニング ステージでは、準備ステージで選択したプライマリ ストレージ オプションを再利用します。プライマリ ストレージ単独でトレーニング ワークロードを処理できない場合は、プライマリ ストレージの追加が必要になることがあります。ローカル SSD などの補助ストレージを必要に応じて追加し、ワークロードのバランスをとることができます。
この段階では、Cloud Storage または Filestore の使用に関する推奨事項に加えて、これらの推奨事項の詳細も提供されます。詳細には次のものが含まれます。
- ファイルサイズとリクエスト サイズに関するガイダンス
- プライマリ ストレージの選択を補完するタイミングの提案
- このフェーズの 2 つの主要なワークロード（データの読み込み、チェックポイントの作成と再起動）の実装の詳細
トレーニング ステージに Cloud Storage を使用する
データをトレーニングする際に Cloud Storage を選択する主な理由は次のとおりです。
- データの準備に Cloud Storage を使用する場合は、Cloud Storage でデータをトレーニングすることをおすすめします。
- Cloud Storage は、スループット、単一 VM の高スループットを必要としないワークロード、必要に応じて多くのスレッドを使用するワークロードに適しています。
トレーニング ステージに Cloud Storage とローカル SSD または Filestore を使用する
データをトレーニングする際に Cloud Storage とローカル SSD または Filestore を選択するのは、小さな I/O リクエストやファイルをサポートする必要がある場合です。この場合、一部のデータをローカル SSD または Filestore ゾーンに移動することで、Cloud Storage のトレーニング タスクを補完できます。
トレーニング ステージで Filestore を使用する
データをトレーニングする際に Filestore を選択する主な理由は次のとおりです。
- データの準備に Filestore を使用している場合は、ほとんどの場合、引き続き Filestore でデータをトレーニングする必要があります。
- Filestore は、低レイテンシ、クライアントあたりの高スループット、スレッド数が少ないが高パフォーマンスを必要とするアプリケーションに適しています。
- Filestore でトレーニング タスクを補完する必要がある場合は、必要に応じてローカル SSD キャッシュの作成を検討してください。
ファイルサイズとリクエスト サイズ
データセットでトレーニングの準備が整ったら、さまざまなストレージ オプションを評価する際に役立つ 2 つの主なオプションがあります。
大容量のファイルを含み、大容量のリクエストでアクセスされるデータセット
このオプションでは、トレーニング ジョブは主に 50 MB 以上の大きなファイルで構成されます。トレーニング ジョブは、リクエストあたり 1 MB～16 MB のファイルを取り込みます。一般に、このオプションには Cloud Storage と Cloud Storage FUSE をおすすめします。これは、Cloud Storage でアクセラレータを提供し続けるのに十分な大きさのファイルがあるためです。このオプションで最大のパフォーマンスを実現するには、数百から数千のスレッドが必要になる場合があります。
ただし、他のアプリケーションで POSIX API の完全な機能が必要である場合や、ワークロードが必要なスレッド数に適していない場合は、Filestore が適しています。
小規模から中規模のファイルを含むデータセット、または小さいリクエスト サイズでアクセスされるデータセット
このオプションを使用すると、トレーニング ジョブを次のいずれかの方法で分類できます。
- 50 MB 未満の小～中規模のファイルが多い。
- ファイルが大きいが、データが順次またはランダムに読み取られるデータセット。読み取りリクエストのサイズは比較的小さくなります（たとえば 1 MB 未満）。このユースケースの例は、システムがマルチギガバイトまたはマルチテラバイトのファイルから一度に 100 KB 未満を読み取る場合です。
すでに POSIX 機能に Filestore を使用している場合は、トレーニング用データを Filestore に保存することをおすすめします。Filestore は、データへの低レイテンシの I/O アクセスを提供します。レイテンシが短くなると、トレーニング時間全体が短縮され、モデルのトレーニング コストが削減される可能性があります。
Cloud Storage を使用してデータを保存する場合は、トレーニングの前にデータをローカル SSD または Filestore にコピーすることをおすすめします。
データ読み込み
データの読み込み中、Cloud GPU または Cloud TPU はモデルをトレーニングするためにデータのバッチを繰り返しインポートします。このフェーズは、バッチのサイズとリクエストの順序に応じて、キャッシュに適した方法で処理できます。この時点での目標は、費用を最小限に抑えながら最大限の効率でモデルをトレーニングすることです。
トレーニング データのサイズがペタバイト規模にスケーリングすると、データの読み取りが複数回必要になる可能性があります。このようなスケールでは、GPU または TPU アクセラレータによる集中的な処理が必要です。ただし、Cloud GPU と Cloud TPU がアイドル状態ではなく、データを積極的に処理するようにする必要があります。そうしないと、ある場所から別の場所にデータをコピーしている間に、高額なアイドル アクセラレータの料金が発生します。
データの読み込みについては、次の点に注意してください。
- 並列処理: トレーニングを並列化する方法は数多くあり、それぞれの方法がストレージ全体のパフォーマンスと、各インスタンスがローカルにキャッシュを作成する必要性に影響を与える可能性があります。
- 1 つのトレーニング ジョブで使用できる Cloud GPU または Cloud TPU の最大数: アクセラレータと VM の数が増えると、ストレージ システムへの影響が著しく大きくなる可能性があります。これにより、Cloud GPU や Cloud TPU がアイドル状態の場合に費用が増加します。ただし、アクセラレータの数を増やすと、費用を最小限に抑えることができます。使用する並列処理のタイプに応じて、アイドル アクセラレータを回避するために必要な合計読み取りスループット要件を増やすことで、費用を最小限に抑えることができます。
Cloud Storage または Filestore でこれらの改善をサポートするには、各インスタンスにローカル SSD を追加して、過負荷状態のストレージ システムから I/O をオフロードできるようにする必要があります。
ただし、Cloud Storage から各インスタンスのローカル SSD にデータをプリロードするには、固有の課題があります。データ転送中にアイドル アクセラレータの費用が増加する可能性があります。データ転送時間が長く、アイドル状態のアクセラレータの費用が高額になっている場合は、代わりに、ローカル SSD で Filestore を使用すると費用を削減できる可能性があります。
- インスタンスあたりの Cloud GPU の数: 各インスタンスに Cloud GPU を追加すると、NVLink を使用して Cloud GPU 間のスループットを向上させることができます。ただし、利用可能なローカル SSD とストレージ ネットワーキングのスループットは、必ずしも線形に増加するとは限りません。
- ストレージとアプリケーションの最適化: ストレージ オプションとアプリケーションには、最適に動作するための特定のパフォーマンス要件があります。これらのストレージとアプリケーション システムの要件と、データ読み込みの最適化（Cloud GPU や Cloud TPU を効率的に動作させるなど）のバランスをとるようにしてください。
チェックポイントの作成と再起動
チェックポイントの作成と再起動の場合、トレーニング ジョブは、インスタンスの障害から迅速に復旧できるように、状態を定期的に保存する必要があります。障害が発生した場合、ジョブを再起動して最新のチェックポイントを取り込み、トレーニングを再開する必要があります。チェックポイントの作成と取り込みに使用される正確なメカニズムは、通常、TensorFlow や PyTorch などのフレームワークに固有のものです。チェックポイント作成の効率を高めるために、複雑なフレームワークを構築しているユーザーもいます。こうした複雑なフレームワークにより、より頻繁にチェックポイントを実行できます。
ほとんどのユーザーは、Cloud Storage や Filestore などの共有ストレージを使用します。チェックポイントを保存する場合、どの時点でも 3～5 個のチェックポイントを保存するだけで済みます。チェックポイントのワークロードは、主に書き込みと複数回の削除で構成されます。理想的には、障害発生時のまれな読み取りで構成されます。復元中の I/O パターンには、集中的で頻繁な書き込み、頻繁な削除、チェックポイントの頻繁な読み取りが含まれます。
また、各 GPU または TPU が作成する必要のあるチェックポイントのサイズも考慮する必要があります。チェックポイントのサイズにより、トレーニング ジョブを効率的かつタイムリーに完了するために必要な書き込みスループットが決まります。
費用を最小限に抑えるには、次の項目を増やすことを検討してください。
- チェックポイントの頻度
- チェックポイントに必要な書き込みスループットの合計
- 再起動の効率性
サービング
モデルを提供する（AI 推論とも呼ばれます）場合、主な I/O パターンは、モデルを Cloud GPU または Cloud TPU メモリに読み込む読み取り専用のパターンです。このステージの目標は、本番環境でモデルを実行することです。このモデルはトレーニング データよりもはるかに小さいため、複数のインスタンス間でモデルを複製してスケーリングできます。このステージでは、ゾーン障害やリージョン障害に対する高可用性と保護が重要です。そのため、さまざまな障害シナリオでもモデルが利用できるようにする必要があります。
多くの生成 AI のユースケースでは、モデルへの入力データが非常に小さく、永続的に保存する必要がない場合があります。また、モデルに対して大量のデータを実行しなければならない場合もあります（科学データセットなど）。この場合、データセットの分析中に提供された Cloud GPU または Cloud TPU を維持するオプションと、推論結果を保存する永続的な場所を選択する必要があります。
モデルをサービングする際の主な選択肢は 2 つあります。
サービング ステージに Cloud Storage を使用する
データの提供に Cloud Storage を選択する主な理由は次のとおりです。
- Cloud Storage でモデルをトレーニングする場合、モデルのサービング時にモデルを Cloud Storage に残しておくことで移行コストを抑えることができます。
- 生成されたコンテンツは Cloud Storage に保存できます。
- Cloud Storage は、AI 推論が複数のリージョンで行われる場合に適しています。
- デュアルリージョン バケットとマルチリージョン バケットを使用すると、リージョンの障害が発生してもモデルの可用性を維持できます。
サービング ステージで Filestore を使用する
データの提供に Filestore を選択する主な理由は次のとおりです。
- Filestore でモデルをトレーニングする場合、Filestore でモデルを公開すると移行コストを節約できます。
- Filestore Enterprise サービスティアは、サービスレベル契約（SLA）で 99.99% の可用性が保証されているため、リージョン内の複数のゾーン間でモデルを提供する場合に高可用性を確保できます。
- Filestore Zonal サービスティアは、AI / ML のワークロードに高可用性が不要な場合に低コストで合理的な選択肢となる可能性があります。
- リージョン間の復元が必要な場合は、モデルをリモート バックアップ ロケーションまたはリモート Cloud Storage バケットに保存して、必要に応じて復元できます。
- Filestore は耐久性と高可用性のオプションを提供します。小さなファイルを生成する場合やファイル API が必要な場合に、モデルに低レイテンシでアクセスできます。
アーカイブ
アーカイブ ステージの I/O パターンは「書き込みは 1 回、読み取りはまれ」です。このステージの目標は、さまざまなトレーニング データセットと、生成されたさまざまなバージョンのモデルを保存することです。これらの増分バージョンのデータとモデルはバックアップと障害復旧に使用できます。また、これらのアイテムは耐久性のある場所に長期間にわたって保管する必要があります。データとモデルに頻繁にアクセスする必要はありませんが、必要なときに利用できるようにする必要があります。
オブジェクト データを長期保存するには Cloud Storage が最適です。このストレージは耐久性、拡張性、コスト効率に優れています。Cloud Storage では、データセット、モデル、バックアップ ファイルにアクセスする頻度に応じて次のようにストレージ クラスを使用し、費用を最適化できます。
- 頻繁にアクセスされるデータは Standard Storage に保存する。
- 毎月アクセスしているデータは Nearline Storage に保存する。
- 3 か月ごとにアクセスするデータは Coldline Storage に保存する。
- 年に 1 回アクセスするデータは Archive Storage に保存する。
オブジェクトのライフサイクル管理を使用して、データをアクセス頻度が低いストレージ クラスに移動するポリシーや、特定の条件でデータを削除するポリシーを作成できます。データにアクセスする頻度が不明な場合は、Autoclass 機能を使用して、アクセス パターンに基づいてストレージ クラス間でデータを自動的に移動できます。
データが Filestore にある場合は、アーカイブ目的でデータを Cloud Storage に移動することがよくあります。ただし、別のリージョンに Filestore バックアップを作成することで Filestore データの保護を強化できます。また、Filestore のスナップショットを取得して、ローカル ファイルとファイル システムを復元することもできます。Filestore のバックアップの詳細については、バックアップの概要をご覧ください。Filestore のスナップショットの詳細については、スナップショットの概要をご覧ください。
AI / ML のストレージに関する推奨事項
このセクションでは、前のセクションのストレージの選択肢を AI と ML のステージにマッピングするで行った分析をまとめます。ほとんどの AI / ML ワークロードに推奨される 3 つのストレージ オプションの組み合わせについて詳しく説明します。この 3 つのオプションは次のとおりです。
Cloud Storage を選択する
Cloud Storage は、他のストレージ サービスと比べると、容量あたりの費用が最も少ないストレージ サービスです。クライアント数に合わせてスケーリングされ、リージョンとデュアル リージョンのアクセスと可用性を提供します。このストレージには Cloud Storage FUSE を介してアクセスできます。トレーニング用のコンピューティング プラットフォームが同じリージョンにある場合は、リージョン ストレージを選択します。より高い信頼性が必要な場合や、Cloud GPU または Cloud TPU を 2 つの異なるリージョンで使用する場合は、デュアルリージョン ストレージを選択します。
Cloud Storage は、長期的なデータ保存や、ストレージ パフォーマンス要件の低いワークロードに最適です。ただし、POSIX の完全なサポートが必要な場合や、Cloud Storage がパフォーマンスのボトルネックになる場合は、Filestore やローカル SSD などの他のオプションが有効な代替手段となります。
Cloud Storage とローカル SSD または Filestore を選択する
大量のデータを使用するトレーニングやチェックポイント、再起動のワークロードの場合、I/O 集約型のトレーニング フェーズで高速なストレージ サービスを使用するのが合理的です。一般的な選択肢としては、データをローカル SSD または Filestore にコピーする方法があります。このアクションにより、データが Cloud GPU または Cloud TPU に継続的に提供されるため、ジョブの実行時間が全体的に短縮され、チェックポイント オペレーションの完了でのインスタンスの停止を防ぐことができます。また、チェックポイントを頻繁に作成するほど、バックアップとして使用できるチェックポイントが多くなります。バックアップ数が増えると、有用なデータが到着する全体的なレート（グッドプット）も向上します。プロセッサの最適化とグッドプットの向上により、モデルのトレーニングの全体的なコストを削減できます。
ローカル SSD または Filestore を使用する場合は、トレードオフを考慮する必要があります。次のセクションでは、それぞれの長所と短所について説明します。
ローカル SSD の利点
- データの転送後の高いスループットと IOPS
- 追加費用は最小限
ローカル SSD の欠点
- データの読み込み中は、Cloud GPU または Cloud TPU がアイドル状態のままになります。
- データ転送は、すべてのインスタンスのすべてのジョブで行う必要があります。
- 一部の Cloud GPU インスタンス タイプでのみ使用できます。
- ストレージ容量が限られています。
- チェックポイントの作成をサポートしていますが、Cloud Storage などの耐久性の高いストレージ オプションにチェックポイントを手動で転送する必要があります。
Filestore の利点
- 共有 NFS ストレージを提供します。これにより、データを 1 回転送して複数のジョブとユーザー間で共有できます。
- Cloud GPU または Cloud TPU の料金が発生する前にデータが転送されるため、Cloud GPU や Cloud TPU がアイドル状態になることはありません。
- 大容量のストレージを利用できます。
- 数千の VM にチェックポイントを迅速に作成できます。
- Cloud GPU、Cloud TPU、他のすべての Compute Engine インスタンス タイプをサポートします。
Filestore の欠点
- 初期費用が高くなります。ただし、コンピューティング効率の向上により、全体的にはトレーニング費用を削減できる可能性があります。
Filestore とオプションのローカル SSD を選択する
Filestore は、低レイテンシと完全な POSIX サポートを必要とする AI / ML ワークロードに最適です。Filestore は、サイズの小さいファイルや小規模の I/O トレーニング ジョブに推奨される選択肢ですが、AI / ML のノートブック、ソフトウェア開発、その他の多くのアプリケーションでレスポンシブなエクスペリエンスを提供します。Filestore をゾーンにデプロイすることで、高パフォーマンスのトレーニングやチェックポイントの永続的な保存を実現できます。また、Filestore をゾーンにデプロイすると障害発生時にすばやく再起動できます。Filestore をリージョンにデプロイして、推論ジョブの高可用性をサポートすることもできます。ローカル SSD キャッシュをサポートする FS-Cache をオプションで追加すると、トレーニング データの読み取りを高速で繰り返し、ワークロードを最適化できます。
次のステップ
ストレージ オプション、AI、ML の詳細については、次のリソースをご覧ください。
- クラウド ワークロードに最適なストレージ戦略の設計
- Cloud Storage のプロダクト概要
- Cloud Storage FUSE
- Filestore の概要
- ローカル SSD について
- Storage Transfer Service の概要
- Vertex AI の概要
- Vertex AI Pipelines のネットワーク到達性の拡張
- 動画 -- より大きなデータセットにすばやく簡単にアクセスし、Vertex AI で ML モデルのトレーニングを加速させる | Google Cloud
- AI Training で Cloud Storage をファイル システムとして利用
- Vertex AI のカスタムモデル トレーニング用データの読み取りと格納 | Google Cloud のブログ
寄稿者
作成者:
- Dean Hildebrand | CTO オフィス テクニカル ディレクター
- Sean Derrington | グループ アウトバウンド プロダクト マネージャー、ストレージ
- Richard Hendricks | アーキテクチャ センター スタッフ
その他の寄稿者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー