Google Cloud Managed Lustre で AI と ML ワークロードを最適化する

Last reviewed 2025-06-02 UTC

このドキュメントでは、Google Cloud Managed Lustre を使用して、Google Kubernetes Engine（GKE）にデプロイされた AI ワークロードと ML ワークロードのパフォーマンスを最適化する方法を示すリファレンス アーキテクチャについて説明します。このドキュメントは、 Google Cloudで AI ワークロードのストレージを設計、プロビジョニング、管理するアーキテクトと技術担当者を対象としています。このドキュメントは、ML のライフサイクル、プロセス、機能について理解していることを前提としています。

Managed Lustre は、DDN の EXAScaler Lustre に基づく、フルマネージドの永続並列ファイル システムです。 Google CloudManaged Lustre は、次の条件を満たす AI ワークロードに最適です。

  • 最大 8 PiB のストレージ容量が必要。
  • 最大 1 TB/秒の高スループットで、超低レイテンシ（ミリ秒未満）のアクセスを実現します。
  • 高い入出力オペレーション/秒（IOPS）を提供します。

Managed Lustre には、AI ワークロードに対して次のような利点があります。

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

アーキテクチャ

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

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

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

  • Google Kubernetes Engine クラスタ: GKE は、AI モデルと ML モデルのトレーニング プロセスとサービング プロセスが実行されるコンピューティング ホストを管理します。GKE は、コントロール プレーン、ノード、システム コンポーネントなど、クラスタの基盤となるインフラストラクチャを管理します。
  • Kubernetes スケジューラ: GKE コントロール プレーンは、ワークロードをスケジューリングし、ライフサイクル、スケーリング、アップグレードを管理します。
  • Virtual Private Cloud（VPC）ネットワーク: アーキテクチャ内のすべての Google Cloud リソースは、単一の VPC ネットワークを使用します。
  • Cloud Load Balancing: このアーキテクチャでは、Cloud Load Balancing は、アプリケーション ユーザーからの受信推論リクエストを GKE クラスタ内のサービング コンテナに効率的に分散します。Cloud Load Balancing を使用すると、AI / ML アプリケーションの高可用性、スケーラビリティ、最適なパフォーマンスを確保できます。詳細については、GKE のロード バランシングについて理解するをご覧ください。
  • 画像処理装置（GPU）または Tensor Processing Unit（TPU）: GPU と TPU は、AI と ML ワークロードのパフォーマンスを向上させる特殊なマシン アクセラレータです。最適な効率と互換性を確保するため、AI / ML ワークロード全体で同じタイプのアクセラレータを使用します。適切なプロセッサ タイプを選択する方法の詳細については、このドキュメントの後半のアクセラレータ オプションをご覧ください。
  • Managed Lustre: Managed Lustre は、低レイテンシと高スループットに最適化された高性能の並列ファイル システムを提供することで、AI と ML のトレーニングとサービングを高速化します。Cloud Storage のみを使用する場合と比較して、Managed Lustre を使用すると、トレーニング時間が大幅に短縮され、サービング中のモデルの応答性が向上します。これらの改善は、共有データへの高速で一貫したアクセスを必要とする要求の厳しいワークロードで特に実現されます。
  • Cloud Storage FUSE: Cloud Storage FUSE は、AI / ML ワークロードに永続的で費用対効果の高いストレージを提供します。Cloud Storage は、未加工のトレーニング データセット、モデルのチェックポイント、モデルのバックアップの中央リポジトリとして機能します。Cloud Storage を使用すると、計算でアクティブに使用されていないデータの耐久性、長期的な可用性、費用対効果を確保できます。

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

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

  1. トレーニング データを Cloud Storage にアップロードする: トレーニング データを Cloud Storage バケットにアップロードします。これは、安全でスケーラブルな中央リポジトリと信頼できる情報源として機能します。
  2. Managed Lustre にデータをコピーする: トレーニング データ コーパスは、API を介して転送され、Cloud Storage から Managed Lustre インスタンスにデータをインポートします。トレーニング データを転送すると、Managed Lustre の高パフォーマンス ファイル システム機能を活用して、モデル トレーニング中のデータ読み込みと処理速度を最適化できます。
  3. GKE でトレーニング ジョブを実行する: モデル トレーニング プロセスは GKE ノードで実行されます。Cloud Storage からデータを直接読み込むのではなく、Managed Lustre をデータソースとして使用することで、GKE ノードはトレーニング データにアクセスして読み込む速度を大幅に向上させ、レイテンシを短縮できます。また、Managed Lustre では、最初のバイトまでの時間（TTFB）で測定される最初のバイトの転送開始までの時間を短縮できます。Managed Lustre を使用すると、特に読み取りファイルが小さく複雑なモデルを含む大規模なデータセットの場合に、データ読み込み時間を短縮し、トレーニング プロセス全体を高速化できます。ワークロードの要件に応じて、GPU または TPU を使用できます。適切なプロセッサ タイプを選択する方法については、このドキュメントの後半のアクセラレータ オプションをご覧ください。
  4. トレーニング チェックポイントを Managed Lustre に保存する: トレーニング プロセス中に、定義した指標または間隔に基づいてチェックポイントが Managed Lustre に保存されます。チェックポイントは、モデルの状態を頻繁にキャプチャします。

サービング ワークロード

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

  1. サービング用のモデルを読み込む: モデルのデプロイの準備が整うと、GKE Pod がトレーニング済みモデルを Managed Lustre インスタンスからサービング ノードに読み込みます。トレーニング中に使用したマネージド Lustre インスタンスに十分な IOPS 容量があり、アクセラレータと同じゾーンにある場合は、同じマネージド Lustre インスタンスを使用してモデルをサービングできます。Managed Lustre インスタンスを再利用すると、トレーニングとサービング間でリソースを効率的に共有できます。最適なパフォーマンスと互換性を維持するには、サービング GKE ノード用に選択した GPU または TPU プロセッサ タイプと同じものを使用します。
  2. 推論リクエスト: アプリケーション ユーザーは、サービング エンドポイントを介して推論リクエストを送信します。これらのリクエストは 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の内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
  • Google Cloud Managed Lustre: AI、ハイ パフォーマンス コンピューティング（HPC）、データ集約型アプリケーション向けのフルマネージド並列ファイル システム。

ユースケース

Managed Lustre は、最大 1 PiB のストレージ容量を必要とし、高スループットと高 IOPS で低レイテンシ（ミリ秒未満）のアクセスを提供する必要がある AI ワークロードに最適です。このセクションでは、Managed Lustre を使用できるユースケースの例を示します。

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

LLM は、テキストベースのデータの理解と処理に特化した AI モデルです。LLM は、大規模なテキスト データセットでトレーニングされており、機械翻訳、質問応答、テキスト要約など、さまざまなタスクを実行できます。効率的なトレーニングとバッチ処理を容易にするには、LLM がデータセットに低レイテンシでアクセスする必要があります。Managed Lustre は、トレーニングと推論の両方に必要な高スループットと低レイテンシを提供することで、データ集約型アプリケーションで優れたパフォーマンスを発揮します。これにより、LLM を活用したアプリケーションの応答性が向上します。

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

医療画像分析や自動運転システムなど、高解像度の画像や動画を処理する従来の AI / ML アプリケーションやマルチモーダル生成モデルには、大容量のストレージと高速なデータアクセスが必要です。Managed Lustre は、高速データ読み込みを可能にする高パフォーマンスの永続ファイル システムを提供し、アプリケーションのパフォーマンスを向上させます。たとえば、Managed Lustre は MRI や CT スキャンなどの大量の患者データを保存し、モデル トレーニングのためにコンピューティング ノードへの迅速なデータ読み込みを容易にすることができます。この機能により、AI モデルと ML モデルでデータを迅速に分析して、診断と治療を行うことができます。

代替案を設計する

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

コンピューティング インフラストラクチャの代替手段

このドキュメントのリファレンス アーキテクチャでは、AI ワークロードと ML ワークロードに GKE を使用しています。ワークロードの要件に応じて、Slurm を使用して Compute Engine にマネージド Lustre インスタンスをデプロイすることもできます。このアプローチは、独自の AI 知的財産（IP）をスケーラブルな環境に統合する必要がある場合や、特殊なワークロードのパフォーマンスを最適化するための柔軟性と制御が必要な場合におすすめします。

Compute Engine では、GKE よりもオペレーティング システム レベルの制御をよりきめ細かく行うことができます。Compute Engine を使用すると、次のことができます。

  • 特定のワークロード要件を満たすように、仮想マシン内の OS 環境を選択、構成、管理します。
  • 特定の VM マシンタイプの選択など、インフラストラクチャをニーズに合わせて調整できます。
  • AI ワークロードのパフォーマンスを向上させるには、アクセラレータ最適化マシン ファミリーを使用します。

Slurm は、高度に構成可能なオープンソースのワークロードとリソース マネージャーです。Slurm は、AI ワークロードの管理に強力なオプションを提供し、コンピューティング リソースの構成と管理を制御できます。このアプローチを使用するには、Slurm 管理と Linux システム管理に関する専門知識が必要です。GKE は、クラスタ管理を自動化するマネージド Kubernetes 環境を提供します。

Slurm のデプロイについては、Slurm を利用した HPC クラスタのデプロイをご覧ください。Managed Lustre スターター ブループリントを使用して Cluster Toolkit を使用してデプロイすることもできます。

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

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

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

サービング ストレージの代替手段

最高レベルの可用性を確保するには、Anywhere Cache とマルチリージョン バケットまたはデュアルリージョン バケットで Cloud Storage FUSE を使用します。この構成により、トレーニング済みの AI モデルを複数のリージョンで使用できるようになります。ただし、Managed Lustre インスタンスと比較すると、Cloud Storage FUSE の VM あたりのスループットが低くなる可能性があります。Cloud Storage FUSE でパフォーマンスを改善する方法については、Cloud Storage FUSE ファイル キャッシュを使用するをご覧ください。

Google Cloud Hyperdisk ML は、大規模なデータセットへの読み取り専用アクセスを必要とする大規模な AI / ML ワークロードを高速化するように設計された、高パフォーマンスのブロック ストレージ ソリューションです。Hyperdisk ML は、ボリューム サイズが小さい場合に集約スループットをわずかに高くプロビジョニングできますが、Managed Lustre と比較して VM あたりのスループットは低くなります。また、Hyperdisk ML ボリュームには、同じゾーンにある GPU VM または TPU VM からのみアクセスできます。したがって、複数のゾーンからサービスを提供するリージョン GKE クラスタの場合は、各ゾーンに個別の Hyperdisk ML ボリュームをプロビジョニングする必要があります。複数の Hyperdisk ML ボリュームをプロビジョニングすると、単一のリージョン マネージド Lustre インスタンスを使用するよりもコストが高くなる可能性があります。

また、Hyperdisk ML は、データの書き込み後に変更できないように設計されています。この書き込みが 1 回で何度でも読み取りできる（WORM）アプローチにより、偶発的な破損や不正な変更を防ぐことができます。ただし、サービング モデルを更新する場合、既存のモデルをオーバーライドすることはできません。代わりに、新しい Hyperdisk ML インスタンスを作成する必要があります。AI ワークロードでの Hyperdisk ML の使用について詳しくは、Hyperdisk ML で AI/ML データの読み込みを高速化するをご覧ください。

設計上の考慮事項

Google Cloudで AI ワークロードと ML ワークロードのセキュリティ、信頼性、費用、運用、パフォーマンスを最適化する Managed Lustre デプロイを設計するには、次のセクションのガイドラインを使用します。

ワークロードのアーキテクチャを構築する際は、Google Cloud Well-Architected Framework: AI と ML の視点のベスト プラクティスと推奨事項を検討してください。

セキュリティ、プライバシー、コンプライアンス

このセクションでは、セキュリティ、プライバシー、コンプライアンスの要件を満たすGoogle Cloud の AI ワークロードと ML ワークロードに関する考慮事項について説明します。

SSH セキュリティ

GKE で実行されるアプリケーションのアクセス制御を強化するには、Identity-Aware Proxy（IAP）を使用します。IAP は GKE Ingress リソースと統合され、適切な Identity and Access Management（IAM）ロールを付与された認証済みユーザーのみがアプリケーションにアクセスできるようにします。詳細については、GKE での IAP の有効化と IAM によるアクセス制御をご覧ください。

データ暗号化

デフォルトでは、Managed Lustre インスタンスに保存されているデータを含め、GKE のデータは Google-owned and Google-managed encryption keysを使用して保存時と転送中に暗号化されます。機密データのセキュリティをさらに強化するため、Cloud Key Management Service（Cloud KMS）で所有、管理する鍵を使用して、アプリケーション レイヤでデータを暗号化できます。詳細については、アプリケーション レイヤで Secret を暗号化するをご覧ください。

GKE Standard クラスタを使用する場合は、次の追加のデータ暗号化機能を使用できます。

データの分離

セキュリティを強化し、データ保護を改善するには、チェックポイントとトレーニング済みモデルとは別の Managed Lustre インスタンスにトレーニング データを保存します。個別のストレージ インスタンスを使用すると、パフォーマンスの分離、トレーニング データの分離によるセキュリティの強化、データ保護の改善が実現します。アクセス制御リストを使用すると、単一のインスタンス内でセキュリティを管理できますが、別のインスタンスを使用すると、より堅牢なセキュリティ境界が提供されます。

セキュリティ上のその他の考慮事項

Autopilot の運用モードでは、GKE がクラスタを事前構成し、セキュリティのベスト プラクティスに沿ってノードを管理するため、ユーザーはワークロード固有のセキュリティに注力できます。詳細については、GKE Autopilot のセキュリティ機能と GKE Autopilot で Kubernetes のセキュリティを簡単に確保をご覧ください。

データのプライバシーの保護については、Sensitive Data Protection の概要とストレージとデータベースの機密データを検査する Google Cloud をご覧ください。

AI ワークロードと ML ワークロードに固有のセキュリティの原則と推奨事項については、Well-Architected Framework の AI と ML の視点: セキュリティをご覧ください。

信頼性

このセクションでは、このリファレンス アーキテクチャを使用して、 Google Cloudでのリージョン デプロイ用に信頼性の高いインフラストラクチャを構築して運用する際に考慮すべき設計要素について説明します。

インフラストラクチャの停止に対する堅牢性

このアーキテクチャで使用される Autopilot 運用モードでは、GKE は次の組み込みの信頼性機能を備えています。

  • ワークロードでリージョン GKE クラスタを使用しています。コントロール プレーンとワーカーノードは、リージョン内の 3 つの異なるゾーンに分散されます。ワークロードは、ゾーンの停止に対して堅牢です。リージョン GKE クラスタでは、ゾーンクラスタよりも稼働時間のサービスレベル契約（SLA）が高くなります。
  • ノードの作成やノードプールの管理は必要ありません。GKE はノードプールを自動的に作成し、ワークロードの要件に基づいて自動的にスケーリングします。

アプリケーションの可用性を高めるには、各ゾーンにマネージド Lustre インスタンスをデプロイして、複数のゾーンからアプリケーションを提供します。

クラスタ キャパシティ プランニング

GKE クラスタの自動スケーリングで必要なときに十分な GPU 容量を使用できるようにするには、予約を作成して使用します。予約により特定のリソースに対して特定のゾーンで容量が保証されます。予約は、プロジェクトに固有のものにすることも、複数のプロジェクトで共有することもできます。予約済みリソースがプロビジョニングまたは使用されていない場合でも、予約済みのリソースには料金が発生します。詳細については、予約済みのゾーンリソースを使用するをご覧ください。

データの耐久性

GKE でワークロードをバックアップして復元するには、各クラスタで Backup for GKE を有効にします。Backup for GKE は、障害復旧、CI/CD パイプライン、ワークロードのクローン作成、アップグレードのシナリオで役立ちます。

バックアップと復元を行う特定のワークロードまたはすべてのワークロードを選択できます。ワークロードを 1 つのクラスタからバックアップし、別のクラスタに復元することもできます。ワークロードのダウンタイムを短縮するために、バックアップを自動的に実行するようにスケジュールできます。これにより、インシデントが発生した場合にワークロードを迅速に復元できます。

信頼性に関するその他の考慮事項

AI ワークロードと ML ワークロードに固有の信頼性の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 信頼性をご覧ください。

費用の最適化

このセクションでは、 Google Cloudで AI と ML のワークフローを設定して運用する際の費用を最適化するためのガイダンスを示します。

Managed Lustre のパフォーマンス ティア

Managed Lustre インスタンスを作成するときに、パフォーマンス ティアを選択する必要があります。ワークロードのパフォーマンスと費用の要件に基づいて、適切なティアを選択します。

ノード プロビジョニング モデル

Autopilot モードでは、GKE はワークロードの要件に基づいてクラスタのインフラストラクチャの効率を最適化します。費用を管理するために、リソースの使用率の継続的なモニタリングや容量の管理を行う必要はありません。

Autopilot クラスタの CPU、メモリ、一時ストレージの使用量を予測できる場合は、確約利用割引を受けることができます。アプリケーションの実行費用を削減するには、GKE ノードで Spot VM を使用します。Spot VM は標準 VM よりも低価格ですが、可用性は保証されません。

リソース管理

効率的な管理を通じて費用とパフォーマンスを最適化するには、Dynamic Workload Scheduler を使用します。Dynamic Workload Scheduler は、AI アクセラレータ（GPU と TPU）へのアクセスを改善するのに役立つリソース管理とジョブ スケジューラです。Dynamic Workload Scheduler は、すべてのアクセラレータを同時にスケジュールし、定義されたアクセラレータ容量管理を使用してオフピーク時に実行できます。Dynamic Workload Scheduler は、ジョブを戦略的にスケジュールすることで、アクセラレータの使用率を最大化し、アイドル時間を短縮し、クラウド費用を最適化します。

リソースの活用

リソース使用率を最大化するには、トレーニングとサービングに 1 つのマネージド Lustre インスタンスを使用します。トレーニング ワークロードとサービング ワークロードを単一の Managed Lustre インスタンスに統合すると、冗長なインフラストラクチャが排除され、リソース管理が簡素化されるため、費用を最小限に抑えることができます。ただし、両方のワークロードでスループットの需要が高い場合は、リソース競合が発生する可能性があります。トレーニング後に IOPS の空きがある場合は、同じインスタンスを使用することで、サービング用のモデルの読み込みを高速化できます。Cloud Monitoring を使用して、スループットの需要を満たすのに十分なリソースを割り当てていることを確認します。

ストレージ費用を最小限に抑えるには、トレーニングとチェックポイントの後に、Managed Lustre インスタンスからデータをエクスポートして、低コストの Cloud Storage クラスに保存します。データを Cloud Storage にエクスポートすると、ワークロードの必要に応じて Managed Lustre インスタンスを破棄して再作成することもできます。

Cloud Storage バケットの費用を管理するには、オブジェクトのライフサイクル管理または Autoclass を有効にします。オブジェクトのライフサイクル管理では、設定したルールに基づいて、古いデータや使用頻度の低いデータを低コストのストレージ クラスに自動的に移動したり、データを削除したりします。Autoclass は、アクセス パターンに基づいてストレージ クラス間でデータを移動します。オブジェクトのライフサイクル管理または Autoclass を使用すると、費用を最小限に抑え、予期しない取得料金の発生を防ぐことで、データ使用量に対して最も費用対効果の高いストレージ クラスを確保できます。

費用に関するその他の考慮事項

AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 費用の最適化と、コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティスをご覧ください。

効果的な運用

このセクションでは、効率的に運用できる AI と ML のワークフローのインフラストラクチャを設計する際に役立つガイダンスを提供します。

モデル管理

バイナリやメタデータなどのモデル アーティファクトを追跡して管理するには、Vertex AI Model Registry を使用します。これにより、モデル バージョンをシームレスに保存、整理、デプロイできます。

モデルの信頼性を最適化するには、Vertex AI Model Monitoring を実装して、データのドリフトを検出し、パフォーマンスを追跡し、本番環境で異常を特定します。

GKE クラスタの自動スケーリング

Autopilot クラスタを使用すると、ノードプールのプロビジョニングや管理を行う必要がなくなります。ノードプールはノード自動プロビジョニングによって自動的にプロビジョニングされ、ワークロードの要件を満たすように自動的にスケーリングされます。

GKE Standard クラスタの場合、クラスタ オートスケーラーは、ワークロードの需要に基づいてノードプール内のノード数を自動的に変更します。クラスタ オートスケーラーの自動スケーリングの動作を制御するには、ノードプールの最小サイズと最大サイズを指定します。

GKE クラスタ オートスケーラーを使用する場合は、クラスタノードで Compute Engine のマネージド インスタンス グループ（MIG）の自動スケーリングを有効にしないでください。GKE クラスタ オートスケーラーは、Compute Engine オートスケーラーとは別のものです。GKE クラスタ オートスケーラーは、基盤となる MIG を含む GKE クラスタ全体のリソース使用率を分析して、ワークロードをスケーリングするように設計されています。両方のオートスケーラーを使用すると、スケーリングの決定が競合する可能性があります。詳細については、GKE クラスタの自動スケーリングについてをご覧ください。

指標のモニタリング

ボトルネックを特定するには、レイテンシ、エラー率、リソース使用率などの主要な指標をモニタリングします。これには Cloud Monitoring を使用します。Cloud Monitoring は、リソース使用パターンの追跡と潜在的な非効率性の特定に役立つリアルタイムの可視性を提供します。

ストレージ管理

Cloud Storage バケットの使用状況に基づいてデータ管理を自動化するには、オブジェクト ライフサイクル管理または Autoclass を有効にします。オブジェクトのライフサイクル管理では、設定したルールに基づいて、古いデータや使用頻度の低いデータを低コストのストレージ クラスに自動的に移動したり、データを削除したりできます。Autoclass は、アクセス パターンに基づいてストレージ クラス間でデータを移動します。オブジェクトのライフサイクル管理または Autoclass を使用すると、ストレージ インフラストラクチャ全体でポリシーを確実に適用し、人的ミスの可能性を減らすことができます。これにより、手動で介入することなく、パフォーマンスとコスト削減の両方を実現できます。

運用上のその他の考慮事項

AI ワークロードと ML ワークロードに固有の運用効率のベスト プラクティスと推奨事項については、Well-Architected Framework の AI と ML の視点: 運用の卓越性をご覧ください。

パフォーマンスの最適化

このセクションでは、 Google Cloudで AI と ML のワークフローのパフォーマンスを最適化するためのガイダンスを示します。このセクションのガイダンスはすべてを網羅しているわけではありません。Google Cloud Managed Lustre 環境のパフォーマンスの最適化の詳細については、パフォーマンスに関する考慮事項をご覧ください。

トレーニングに関する考慮事項

各 A3 または A4 VM は、マネージド Lustre インスタンスから 20 GB/秒（GPU あたり約 2.5 GB/秒）を配信できます。トレーニングを開始する前に、トレーニング中のレイテンシを最小限に抑えるため、トレーニング データを Cloud Storage からプリフェッチして Managed Lustre にインポートする必要があります。トレーニング ワークロードのスループットを最大化するには、スループットとストレージ容量のニーズに合わせて Managed Lustre インスタンスをプロビジョニングします。たとえば、20 TiB の Managed Lustre インスタンスは、選択したパフォーマンス ティアに応じて、すべてのクライアントで 2.5 GB/秒～ 20 GB/秒の集約スループットを提供します。トレーニングで高いスループットが必要な場合は、それに応じて Managed Lustre インスタンスのサイズを大きくする必要があります。

チェックポイントに関する考慮事項

Managed Lustre が提供する高い書き込みスループットを活用し、トレーニング時間を最小限に抑えるには、トレーニングとチェックポイントの両方に Managed Lustre を使用します。このアプローチにより、リソースの効率的な使用が実現し、トレーニングとチェックポイントの両方を可能な限り高速に保つことで、GPU リソースの TCO を削減できます。高速チェックポイント設定を実現するには、分散非同期チェックポイント設定を実行します。Managed Lustre は永続的であるため、チェックポイントを同じインスタンス内に保存できます。費用の最適化と長期保存をさらに行うには、チェックポイントを Cloud Storage バケットにエクスポートすることを検討してください。

サービングに関する考慮事項

サービング中に最適なパフォーマンスを実現するには、モデルをメモリに読み込む時間を最小限に抑える必要があります。Managed Lustre は、VM あたり 20 GB/秒を超える高いスループットを提供し、高いクラスタ スループットを実現します。この機能を使用すると、数千台の VM でモデルの読み込み時間を最小限に抑えることができます。ボトルネックを特定できる主要な指標を追跡するには、Cloud Monitoring を使用し、ストレージ容量の増加に伴ってパフォーマンスが向上するように十分な容量をデプロイしていることを確認します。

リソースの配置

レイテンシを最小限に抑え、パフォーマンスを最大化するには、GPU または TPU コンピューティング クライアントに地理的に近いリージョンに Managed Lustre インスタンスを作成します。このドキュメントで説明するリファレンス アーキテクチャでは、GKE コンテナとファイル システムが同じゾーンに配置されます。

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

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

パフォーマンスに関するその他の考慮事項

AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: パフォーマンスの最適化をご覧ください。

デプロイ

マネージド Lustre インスタンスを作成してマウントするには、Cluster Toolkit で使用可能なマネージド Lustre モジュールを使用することをおすすめします。Cluster Toolkit は、Google Cloudで再現可能な AI 環境と ML 環境のデプロイ用に設計された、Terraform ベースのモジュラー ツールキットです。

GKE に Managed Lustre を手動でデプロイする方法については、Managed Lustre を作成するインスタンスと Google Kubernetes Engine から既存の Managed Lustre インスタンスに接続するをご覧ください。

Managed Lustre 用に VPC ネットワークを構成する方法については、VPC ネットワークを構成するをご覧ください。

次のステップ

寄稿者

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

その他の寄稿者:

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