Parallelstore で AI ワークロードと ML ワークロードを最適化する

Last reviewed 2025-01-20 UTC

このドキュメントでは、Parallelstore を使用して人工知能(AI)または機械学習(ML)ワークロードのパフォーマンスを最適化する方法を示すリファレンス アーキテクチャについて説明します。Parallelstore は、AI と ML ワークロードの費用削減、リソース使用率の向上、トレーニング時間の短縮に役立つ並列ファイル システム ストレージ サービスです。

このドキュメントの対象読者は、 Google Cloudで AI ワークロードと ML ワークロードのストレージを設計、プロビジョニング、管理するアーキテクトと技術担当者です。このドキュメントは、ML のライフサイクル、プロセス、機能を理解していることを前提としています。

Parallelstore は、分散非同期オブジェクト ストレージ(DAOS)アーキテクチャ上に構築された、 Google Cloud のフルマネージドで高パフォーマンスのスクラッチ ファイル システムです。Parallelstore は、最大 100 TiB のストレージ容量を使用し、高スループットと高い 1 秒あたりの入出力オペレーション数(IOPS)で低レイテンシ(ミリ秒未満)のアクセスを提供する必要がある AI と ML のワークロードに最適です。

Parallelstore には、AI ワークロードと ML ワークロードに次のような利点があります。

  • トレーニングの総所有コスト(TCO)の削減: Parallelstore は、コンピューティング ノードにデータを効率的に配信することで、トレーニング時間を短縮します。この機能により、AI モデルと ML モデルのトレーニングの総所有コストを削減できます。
  • サービング TCO の削減: Parallelstore の高パフォーマンス機能により、モデルの読み込みが高速化され、推論サービングが最適化されます。これらの機能は、コンピューティング費用の削減とリソース使用率の向上に役立ちます。
  • リソースの効率的な使用: Parallelstore を使用すると、トレーニング、チェックポイント、サービングを 1 つのインスタンス内で組み合わせることができます。このリソース使用率により、単一の高パフォーマンス ストレージ システムで読み取りと書き込みのスループットを効率的に使用できます。

アーキテクチャ

次の図は、Parallelstore を使用してモデル トレーニング ワークロードとサービング ワークロードのパフォーマンスを最適化するアーキテクチャの例を示しています。

このアーキテクチャでは、Parallelstore を使用してモデル トレーニング ワークロードとサービング ワークロードのパフォーマンスを最適化します。

上のアーキテクチャに示されているワークロードについては、後のセクションで詳しく説明します。このアーキテクチャは、次のコンポーネントで構成されます。

コンポーネント 目的
Google Kubernetes Engine(GKE)クラスタ GKE は、AI モデルと ML モデルのトレーニング プロセスとサービス提供プロセスが実行されるコンピューティング ホストを管理します。GKE は、コントロール プレーン、ノード、すべてのシステム コンポーネントなど、クラスタの基盤となるインフラストラクチャを管理します。
Kubernetes スケジューラ GKE コントロール プレーンは、ワークロードをスケジューリングし、ワークロードのライフサイクル、スケーリング、アップグレードを管理します。図には表示されていませんが、Kubernetes ノード エージェント(kubelet)はコントロール プレーンと通信します。kubelet は、GKE ノードにスケジュールされたコンテナの起動と実行を担当します。Dynamic Workload Scheduler を使用してバッチ ワークロードと AI ワークロード用の GPU をデプロイすると、大きなコミットメントなしで GPU をリクエストできます。スケジューラの詳細については、GKE での AI/ML オーケストレーションをご覧ください。
Virtual Private Cloud(VPC)ネットワーク このアーキテクチャ内のすべての Google Cloud リソースは、単一の VPC ネットワークを使用します。要件に応じて、複数のネットワークを使用するアーキテクチャを構築できます。Parallelstore の VPC ネットワークを構成する方法については、 VPC ネットワークを構成するをご覧ください。
Cloud Load Balancing このアーキテクチャでは、Cloud Load Balancing は、アプリケーション ユーザーからの受信推論リクエストを GKE クラスタ内のサービング コンテナに効率的に分散します。Cloud Load Balancing を使用すると、AI アプリケーションと ML アプリケーションの高可用性、スケーラビリティ、最適なパフォーマンスを確保できます。詳細については、GKE ロード バランシングの概要をご覧ください。
グラフィック プロセッシング ユニット(GPU)またはテンソル プロセッシング ユニット(TPU) GPU と TPU は、AI ワークロードと ML ワークロードのパフォーマンスを向上させる専用のマシン アクセラレータです。適切なプロセッサ タイプを選択する方法については、このドキュメントのアクセラレータ オプションをご覧ください。
Parallelstore Parallelstore は、低レイテンシと高スループット向けに最適化された高パフォーマンスの並列ファイル システムを提供することで、AI と ML のトレーニングとサービングを高速化します。Cloud Storage のみを使用する場合と比較して、Parallelstore を使用すると、トレーニング時間が大幅に短縮され、サービング中のモデルの応答性が向上します。これらの改善は、共有データへの高速で一貫したアクセスを必要とする負荷の高いワークロードで特に実現されます。
Cloud Storage Cloud Storage は、AI ワークロードと ML ワークロードに永続的で費用対効果の高いストレージを提供します。Cloud Storage は、元のトレーニング データセット、モデルのチェックポイント、最終的なトレーニング済みモデルの中央リポジトリとして機能します。Cloud Storage を使用すると、計算で積極的に使用されていないデータの耐久性、長期的な可用性、費用対効果を確保できます。

トレーニング ワークロード

上記のアーキテクチャでは、モデルのトレーニング中のデータフローは次のようになります。

  1. トレーニング データを Cloud Storage にアップロードする: トレーニング データを Cloud Storage バケットにアップロードします。このバケットは、安全でスケーラブルな一元的なリポジトリと信頼できる情報源として機能します。
  2. Parallelstore にデータをコピーする: トレーニング データ コーパスは、Parallelstore インスタンスへの一括 API インポートを介して Cloud Storage から転送されます。トレーニング データを転送すると、Parallelstore の高パフォーマンス ファイル システム機能を利用して、モデル トレーニング中のデータ読み込みと処理速度を最適化できます。
  3. GKE でトレーニング ジョブを実行する: モデル トレーニング プロセスは GKE ノードで実行されます。Cloud Storage からデータを直接読み込むのではなく、Parallelstore をデータソースとして使用することで、GKE ノードはトレーニング データにアクセスして読み込み、速度と効率を大幅に向上させることができます。Parallelstore を使用すると、特に大規模なデータセットと複雑なモデルの場合、データの読み込み時間が短縮され、全体的なトレーニング プロセスが高速化されます。ワークロードの要件に応じて、GPU または TPU を使用できます。適切なプロセッサ タイプを選択する方法については、このドキュメントのアクセラレータ オプションをご覧ください。
  4. トレーニング チェックポイントを Parallelstore に保存する: トレーニング プロセス中に、定義した指標または間隔に基づいてチェックポイントが Parallelstore に保存されます。チェックポイントは、モデルの状態を頻繁にキャプチャします。
  5. チェックポイントとモデルを Cloud Storage に保存する: Parallelstore インスタンスからの一括 API エクスポートを使用して、一部のチェックポイントを保存し、トレーニング済みモデルを Cloud Storage に保存することをおすすめします。この方法により、フォールト トレラントが確保され、特定の時点からトレーニングを再開する、本番環境にモデルをデプロイする、さらにテストを実施するなどの将来のユースケースが可能になります。ベスト プラクティスとして、チェックポイントはトレーニング データとは異なるバケットに保存します。
    • チェックポイントまたはモデルを復元する: AI ワークフローと ML ワークフローでチェックポイントまたはモデルデータを復元する必要がある場合は、Cloud Storage で復元するアセットを見つける必要があります。タイムスタンプ、パフォーマンス指標、特定のバージョンに基づいて復元するアセットを選択します。API インポートを使用してアセットを Cloud Storage から Parallelstore に転送し、アセットをトレーニング コンテナに読み込みます。復元したチェックポイントまたはモデルを使用して、トレーニングの再開、パラメータのファインチューニング、検証セットでのパフォーマンスの評価を行うことができます。

サービス ワークロード

上記のアーキテクチャでは、モデルのサービング中のデータフローは次のようになります。

  1. サービング用にモデルを読み込む: トレーニングが完了すると、Pod はトレーニング済みモデルをサービング ノードに読み込みます。トレーニング中に使用した Parallelstore インスタンスに十分な IOPS 容量がある場合は、トレーニング インスタンスを使用してモデルをサービングすることで、モデルの読み込みを高速化し、費用を削減できます。トレーニング インスタンスを再利用すると、トレーニングとサービング間でリソースを効率的に共有できます。ただし、パフォーマンスと互換性を最適に維持するには、トレーニングに、サービング GKE ノードで使用可能なアクセラレータ タイプと一致するアクセラレータ タイプ(GPU または TPU)を使用します。
  2. 推論リクエスト: アプリケーション ユーザーは、AI と ML アプリケーションを介して推論リクエストを送信します。これらのリクエストは Cloud Load Balancing サービスに転送されます。Cloud Load Balancing は、受信したリクエストを GKE クラスタ内のサービング コンテナに分散します。この分散により、単一のコンテナが過負荷にならないようにし、リクエストを効率的に処理します。
  3. 推論リクエストの処理: 本番環境では、システムはモデル サービング キャッシュを利用して推論リクエストを効率的に処理します。コンピューティング ノードは、まず一致する予測を確認することでキャッシュとやり取りします。一致する予測が見つかった場合は、直接返されます。これにより、レスポンス時間とリソース使用量を最適化できます。それ以外の場合、モデルはリクエストを処理し、予測を生成して、将来の効率性のためにキャッシュに保存します。
  4. レスポンスの配信: サービス提供コンテナは、Cloud Load Balancing を介してレスポンスを返します。Cloud Load Balancing はレスポンスを適切なアプリケーション ユーザーに転送し、推論リクエスト サイクルが完了します。

使用するプロダクト

このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。

  • Virtual Private Cloud(VPC): Google Cloud ワークロードにグローバルでスケーラブルなネットワーキング機能を提供する仮想システム。VPC には、VPC ネットワーク ピアリング、Private Service Connect、プライベート サービス アクセス、共有 VPC が含まれます。
  • Google Kubernetes Engine(GKE): Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションを大規模にデプロイして運用するために使用できる Kubernetes サービス。
  • Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
  • Parallelstore: AI、ハイ パフォーマンス コンピューティング(HPC)、データ集約型アプリケーション向けのフルマネージド並列ファイル システム。

ユースケース

Parallelstore は、最大 100 TiB のストレージ容量を備え、高スループットと高 IOPS で低レイテンシ(ミリ秒未満)のアクセスを提供する必要がある AI と ML のワークロードに最適です。以降のセクションでは、Parallelstore を使用できるユースケースの例を示します。

テキストベースの処理とテキスト生成

大規模言語モデル(LLM)は、テキストベースのデータを理解して処理するために特別に設計された特化した AI モデルです。LLM は、膨大なテキスト データセットでトレーニングされているため、機械翻訳、質問応答、テキスト要約など、さまざまなタスクを実行できます。LLM モデルをトレーニングするには、リクエストの効率的な処理とテキスト生成のために、データセットへの低レイテンシ アクセスが必要です。Parallelstore は、トレーニングと推論の両方に必要な高スループットと低レイテンシを実現し、LLM を活用したアプリケーションの応答性を高めるため、データ集約型のアプリケーションに適しています。

高解像度の画像または動画の処理

医用画像分析や自動運転システムなど、従来の AI や ML アプリケーション、または高解像度の画像や動画を処理するマルチモーダル生成モデルには、大容量のストレージと高速なデータアクセスが必要です。Parallelstore の高パフォーマンス スクラッチ ファイル システムにより、高速なデータ読み込みが可能になり、アプリケーションのパフォーマンスが向上します。たとえば、Parallelstore は、Cloud Storage から pull された MRI スキャンや CT スキャンなどの大量の患者データを一時的に保持して処理できます。この機能により、AI モデルと ML モデルは、診断と治療のためにデータを迅速に分析できます。

代替案を設計する

以降のセクションでは、 Google Cloudの AI アプリケーションで検討できる代替の設計アプローチについて説明します。

代替プラットフォーム

モデルのトレーニングとサービング ワークフローを GKE でホストする代わりに、Slurm を備えた Compute Engine を検討できます。Slurm は、高度に構成可能なオープンソースのワークロードとリソース マネージャーです。Slurm で Compute Engine を使用することは、大規模なモデル トレーニングとシミュレーションに特に適しています。独自の AI と ML の知的財産(IP)をスケーラブルな環境に統合し、柔軟性と制御で特殊なワークロードのパフォーマンスを最適化する必要がある場合は、Compute Engine と Slurm を使用することをおすすめします。

Compute Engine では、仮想マシン(VM)をプロビジョニングして管理します。これにより、インスタンスタイプ、ストレージ、ネットワーキングをきめ細かく制御できます。特定の VM マシンタイプの選択など、インフラストラクチャをニーズに合わせて調整できます。アクセラレータ最適化マシンファミリーを使用して、AI ワークロードと ML ワークロードのパフォーマンスを向上させることもできます。Compute Engine で使用可能なマシンタイプ ファミリーの詳細については、マシン ファミリーのリソースと比較ガイドをご覧ください。

Slurm は、AI ワークロードと ML ワークロードを管理するための強力なオプションを提供し、コンピューティング リソースの構成と管理を制御できます。このアプローチを使用するには、Slurm の管理と Linux システム管理に関する専門知識が必要です。

アクセラレータのオプション

マシン アクセラレータは、AI ワークロードと ML ワークロードに必要な計算を高速化するように設計された専用のプロセッサです。Graphics Processing Unit(GPU)または Tensor Processing Unit(TPU)を選択できます。

  • GPU アクセラレータは、グラフィック レンダリング、ディープ ラーニング トレーニング、科学技術計算など、幅広いタスクで優れたパフォーマンスを提供します。 Google Cloud には、さまざまなパフォーマンスと価格帯に対応する幅広い GPU が用意されています。GPU モデルと料金については、GPU の料金をご覧ください。
  • TPU は、大規模な AI モデルのトレーニングと推論向けに最適化されたカスタム設計の AI アクセラレータです。chatbot、コード生成、メディア コンテンツ生成、合成音声、ビジョン サービス、レコメンデーション エンジン、パーソナライズ モデルなど、さまざまなユースケースに最適です。TPU モデルと料金の詳細については、TPU の料金をご覧ください。

ストレージの代替手段

マルチリージョン バケットまたはデュアルリージョン バケットを使用する Cloud Storage FUSE は、トレーニング済みの AI モデルと ML モデルが Cloud Storage と複数のリージョンに保存されるため、最高レベルの可用性を実現します。Cloud Storage FUSE は Parallelstore よりも VM あたりのスループットが低くなりますが、Cloud Storage FUSE を使用すると、Cloud Storage のスケーラビリティと費用対効果を活用できます。特に負荷の高いワークロードの場合、モデルの読み込みを高速化し、パフォーマンスを向上させるには、各リージョンで既存または新しい Parallelstore インスタンスを使用できます。Cloud Storage FUSE でパフォーマンスを改善する方法については、GKE のパフォーマンスを向上させるために Cloud Storage FUSE CSI ドライバを最適化するをご覧ください。

Google Cloud Hyperdisk ML は、大規模なデータセットへの読み取り専用アクセスを必要とする大規模な AI ワークロードと ML ワークロードを高速化するように設計された高性能のブロック ストレージ ソリューションです。Hyperdisk ML は、より高い合計スループットでプロビジョニングできますが、Parallelstore と比較して VM あたりのスループットは低くなります。

また、Hyperdisk ML ボリュームには、同じゾーンの GPU または TPU VM からのみアクセスできます。したがって、複数のゾーンからサービスを提供するリージョン GKE クラスタの場合は、各ゾーンに個別の Hyperdisk ML ボリュームをプロビジョニングする必要があります。この配置は、リージョンごとに 1 つのインスタンスのみが必要な Parallelstore とは異なります。Hyperdisk ML は読み取り専用であることも重要です。AI ワークロードと ML ワークロードで Hyperdisk ML を使用する方法については、Hyperdisk ML で AI/ML データの読み込みを高速化するをご覧ください。

設計上の考慮事項

Google Cloudで AI ワークロードと ML ワークロードのパフォーマンスと費用対効果を最適化する Parallelstore デプロイを設計するには、次のセクションのガイドラインを使用します。このガイドラインでは、ワークフロー内の特定のタスクに複数のストレージ オプションを組み合わせたハイブリッド ソリューションの一部として Parallelstore を使用する際に考慮すべき推奨事項について説明します。

トレーニング

AI モデルと ML モデルのトレーニングでは、モデルにデータを繰り返し入力し、パラメータを調整し、各イテレーションでパフォーマンスを評価する必要があります。このプロセスは計算負荷が高く、トレーニング データを読み取り、更新されたモデル パラメータを書き込む必要があるため、大量の I/O リクエストが発生します。

トレーニング中のパフォーマンスのメリットを最大限に活用するには、次のことをおすすめします。

  • キャッシュ保存: Cloud Storage の上に高性能キャッシュとして Parallelstore を使用します。
  • プリフェッチ: Cloud Storage から Parallelstore にデータをインポートして、トレーニング中のレイテンシを最小限に抑えます。GKE Volume Populator を使用して、Cloud Storage のデータを PersistentVolumesClaims に事前に入力することもできます。
  • 費用の最適化: 長期的なストレージ費用を最小限に抑えるために、トレーニング後にデータを低コストの Cloud Storage クラスにエクスポートします。永続データは Cloud Storage に保存されるため、トレーニング ジョブに応じて Parallelstore インスタンスを破棄して再作成できます。
  • GKE との統合: GKE Container Storage Interface(CSI)ドライバと統合して管理を簡素化します。GKE クラスタを Parallelstore インスタンスに接続する方法については、Google Kubernetes Engine Parallelstore CSI ドライバをご覧ください。
  • A3 VM のパフォーマンス: A3 バリアントでは 20 GB/秒(GPU あたり約 2.5 GB/秒)を超えるデータ配信が可能で、最適なデータ配信を実現します。
  • 同時アクセス: Parallelstore インスタンスを使用して、フル デュプレックスの読み取りと書き込みに対応します。

トレーニング用に Parallelstore をデプロイする場合は、次の点を考慮してください。

  • スクラッチ ファイル システム: トレーニング プロセス全体でチェックポイント処理の間隔を構成します。Parallelstore はスクラッチ ファイル システムです。つまり、データは一時的に保存されます。100 TiB の範囲では、データ損失までの推定平均時間は 2 か月です。23 TiB の範囲では、データ損失までの推定平均時間は 12 か月以上です。
  • ファイルとディレクトリのストライプ化: 主なファイルサイズに合わせてファイルとディレクトリのストライプ化を最適化し、パフォーマンスを最大化します。
  • 費用の最適化: Parallelstore ではなく Cloud Storage にデータを適切にステージングすることで、費用を最適化します。
  • ゾーンの選択: GPU または TPU コンピューティング クライアントとストレージ ノードを同じゾーンに配置して、コストとパフォーマンスを最適化します。

パフォーマンスを最適化するように Parallelstore 環境を構成する方法については、パフォーマンスに関する考慮事項をご覧ください。

チェックポインティング

チェックポイントは、AI モデルと ML モデルのトレーニングに欠かせない要素です。チェックポイントを使用すると、プロセスのさまざまな時点でモデルの状態を保存できるため、中断やシステム障害が発生した場合や、さまざまなハイパーパラメータ構成を探索する場合に、保存したチェックポイントからトレーニングを再開できます。トレーニングに Parallelstore を使用する場合は、高書き込みスループットを活用してトレーニング時間を最小限に抑えるために、チェックポイントにも Parallelstore を使用することが重要です。このアプローチでは、トレーニングとチェックポイントの両方を可能な限り高速に維持することで、リソースを効率的に使用し、GPU リソースの TCO を削減できます。

Parallelstore でチェックポイント ワークフローを最適化するには、次のベスト プラクティスを検討してください。

  • 高速チェックポイント処理: Parallelstore で高速なチェックポイント書き込みを利用します。容量の TiB あたり 0.5 GB/秒、A3 VM あたり 12 GB/秒を超えるスループットを実現できます。
  • 選択的チェックポイント ストレージ: 長期保存と障害復旧のために、Parallelstore から選択したチェックポイントを Cloud Storage にエクスポートします。
  • 同時オペレーション: トレーニングとチェックポイントの書き込みに Parallelstore を同時に使用することで、読み取りと書き込みのフル デュプレックスを利用できます。

サービス提供

サービングでは、トレーニング済みの AI モデルと ML モデルをデプロイして、推論リクエストを処理します。最適なパフォーマンスを実現するには、これらのモデルをメモリに読み込む時間を最小限に抑えることが重要です。Parallelstore は主にトレーニング ワークロード用に設計されていますが、Parallelstore の VM あたりの高スループット(20 GB/秒以上)とクラスタの合計スループットを使用して、数千の VM にわたるモデルの読み込み時間を最小限に抑えることができます。ボトルネックを特定して効率を最適化できる主要な指標を追跡するには、Cloud Monitoring を使用します。

サービング用に Parallelstore をデプロイする場合は、次の点を考慮してください。

  • 高スループット: Cloud Monitoring を使用して Parallelstore のパフォーマンスを最大化し、100 TiB で最大 125 GB/秒のスループットを実現するのに十分な容量をデプロイします。
  • サービスの中断の可能性: Parallelstore はスクラッチ ファイル システムであるため、サービスが中断することがあります。100 TiB クラスタの場合、データ損失までの平均時間は約 2 か月です。
  • データを復元する: サービスが中断した場合は、最新の Cloud Storage バックアップから Parallelstore データを復元する必要があります。データは約 16 GB/秒の速度で転送されます。
  • 共有インスタンス: トレーニングとサービングに 1 つの Parallelstore インスタンスを使用すると、リソース使用率を最大化し、費用対効果を高めることができます。ただし、両方のワークロードでスループット要件が高い場合、リソース競合が発生する可能性があります。トレーニング後に予備の IOPS を使用できる場合は、同じインスタンスを使用して、サービング用のモデルの読み込みを高速化できます。Cloud Monitoring を使用して、スループット需要を満たすために十分なリソースを割り当てるようにします。
  • 個別のインスタンス: 個別のインスタンスを使用すると、パフォーマンスの分離、トレーニング データの分離によるセキュリティの強化、データ保護の強化が実現します。アクセス制御リストは単一インスタンス内のセキュリティを管理できますが、個別のインスタンスを使用すると、より堅牢なセキュリティ境界を実現できます。

配置のオプション

レイテンシを最小限に抑え、パフォーマンスを最大化するには、GPU または TPU コンピューティング クライアントに地理的に近いリージョンに Parallelstore インスタンスを作成します。

  • トレーニングとチェックポイント用: 最適な結果を得るには、クライアントと Parallelstore インスタンスが同じゾーンにあることを確認してください。このコロケーションにより、データ転送時間が最小限に抑えられ、Parallelstore の書き込みスループットの使用率が最大化されます。
  • サービングの場合: 同じゾーンのコンピューティング クライアントとコロケーションするのが理想的ですが、リージョンごとに 1 つの Parallelstore インスタンスがあれば十分です。このアプローチでは、複数のインスタンスのデプロイに関連する追加費用を回避し、コンピューティング パフォーマンスを最大化できます。ただし、容量やスループットを増やす必要がある場合は、リージョンごとに複数のインスタンスをデプロイすることを検討してください。

2 つのリージョンに Parallelstore をデプロイすると、サービングに使用される GPU または TPU に地理的にデータを近づけることができるため、パフォーマンスが大幅に向上します。この配置により、レイテンシが短縮され、推論中の高速なデータアクセスが可能になります。リージョンが停止した場合、トレーニング アプリケーションとサービング アプリケーションの両方がユーザーに使用できなくなります。

高可用性と信頼性を確保するには、このアーキテクチャのレプリカを別のリージョンにインスタンス化する必要があります。地理的に冗長なアーキテクチャを作成すると、1 つのリージョンで停止が発生しても、AI アプリケーションと ML アプリケーションは引き続き動作できます。クラスタデータと Cloud Storage データをバックアップして復元し、必要に応じて別のリージョンに復元するには、Backup for GKE を使用します。

Parallelstore インスタンスでサポートされているロケーションについては、サポートされているロケーションをご覧ください。

デプロイ

このリファレンス アーキテクチャを作成してデプロイするには、Cluster Toolkit を使用することをおすすめします。Cluster Toolkit は、Google Cloudに繰り返し使用できる AI 環境と ML 環境をデプロイするように設計された、Terraform ベースのモジュラー ツールキットです。環境を定義するには、GKE と Parallelstore のトレーニング ブループリントを使用します。クラスタの Parallelstore インスタンスをプロビジョニングして管理するには、Parallelstore モジュールを参照してください。

Parallestore を手動でデプロイする方法については、Parallelstore インスタンスを作成するをご覧ください。動的プロビジョニングでスケーラビリティをさらに向上させ、パフォーマンスを強化するには、GKE で Parallelstore インスタンスを基盤とする Volume を作成して使用します。

次のステップ

寄稿者

作成者: Samantha He | テクニカル ライター

その他の寄稿者:

  • Dean Hildebrand | CTO オフィス テクニカル ディレクター
  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Sean Derrington | グループ アウトバウンド プロダクト マネージャー、ストレージ