このドキュメントでは、Google Cloud Managed Lustre を使用して、Google Kubernetes Engine（GKE）にデプロイされた AI / ML ワークロードのパフォーマンスを最適化する方法を示すリファレンス アーキテクチャについて説明します。このドキュメントは、 Google Cloudで AI ワークロードのストレージを設計、プロビジョニング、管理するアーキテクトと技術担当者を対象としています。このドキュメントは、ML のライフサイクル、プロセス、機能について理解していることを前提としています。
Managed Lustre は、DDN の EXAScaler Lustre に基づく、完全に Google Cloud-マネージドの永続並列ファイル システム（PFS）です。Managed Lustre は、AI トレーニングとチェックポイント処理のワークロードに推奨されるプライマリ ソリューションです。特に、Lustre や他の PFS ソリューションから既存のワークロードを移行する場合に効果的です。リソース使用率を最大化するには、Managed Lustre をトレーニングに使用するワークロードで、サービングと推論に同じインスタンスを使用する必要があります。
Managed Lustre は、次の条件を満たす AI ワークロードに推奨されるソリューションです。
- PiB 規模のストレージ容量が必要。
- 最大 1 TB/秒の高スループットで、超低レイテンシ（ミリ秒未満）のアクセスを提供します。
- 高い入出力オペレーション/秒（IOPS）を提供します。
Managed Lustre には、AI ワークロードに対して次のような利点があります。
- トレーニングの総所有コスト（TCO）を削減: Managed Lustre は、コンピューティング ノードにデータを効率的に配信することで、トレーニング時間を短縮します。この機能により、AI モデルと ML モデルのトレーニングの総所有コストを削減できます。
- サービングの TCO を低減: Managed Lustre は、モデルの読み込みを高速化し、推論サービングを最適化する高性能機能を提供します。これらの機能は、コンピューティング費用を低減し、リソース使用率の向上に役立ちます。
- 効率的なリソース使用: Managed Lustre を使用すると、チェックポイント処理とトレーニングを 1 つのインスタンス内で行うことができます。このようにリソースを共有することで、高パフォーマンスの単一のストレージ システムで読み取り / 書き込みスループットを効率的に使用できます。
アーキテクチャ
次の図は、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 は、低レイテンシと高スループット向けに最適化された高パフォーマンスの永続 PFS を提供することで、AI と ML のトレーニングとサービングを高速化します。Cloud Storage のみを使用する場合と比較して、Managed Lustre を使用すると、トレーニング時間が大幅に短縮され、サービング中のモデルの応答性が向上します。これらの改善は、共有データへの高速で一貫したアクセスを必要とする要求の厳しいワークロードで特に実現されます。
- Cloud Storage FUSE: Cloud Storage FUSE は、AI / ML ワークロードに永続的で費用対効果の高いストレージを提供します。Cloud Storage は、未加工のトレーニング データセット、モデルのチェックポイント、モデルのバックアップの中央リポジトリとして機能します。Cloud Storage を使用すると、計算でアクティブに使用されていないデータの耐久性、長期的な可用性、費用対効果を確保できます。
トレーニング ワークロード
上記のアーキテクチャでは、モデルのトレーニング中のデータフローは次のようになります。
- トレーニング データを Cloud Storage にアップロードする: トレーニング データを Cloud Storage バケットにアップロードします。これは、安全でスケーラブルな中央リポジトリと信頼できる情報源として機能します。
- Managed Lustre にデータをコピーする: トレーニング データ コーパスは、Cloud Storage から Managed Lustre インスタンスにデータをインポートすることで転送されます。トレーニング データを転送すると、Managed Lustre の高パフォーマンスのファイル システム機能を活用して、モデルのトレーニング中のデータ読み込みと処理速度を最適化できます。
- GKE でトレーニング ジョブを実行する: モデル トレーニング プロセスが GKE ノードで実行されます。Cloud Storage からデータを直接読み込むのではなく、Managed Lustre をデータソースとして使用することで、GKE ノードはトレーニング データにアクセスして読み込む速度を大幅に向上させ、レイテンシを短縮できます。Managed Lustre では、最初のバイトまでの時間（TTFB）で測定される最初のバイトの転送開始までの時間も短縮されます。Managed Lustre を使用すると、特に読み取りファイルが小さく、モデルが複雑な大規模データセットの場合に、データ読み込み時間を短縮し、トレーニング プロセス全体を高速化できます。ワークロードの要件に応じて、GPU または TPU を使用できます。適切なプロセッサ タイプを選択する方法については、このドキュメントの後半のアクセラレータ オプションをご覧ください。
- トレーニング チェックポイントを Managed Lustre に保存する: トレーニング プロセス中に、定義した指標または間隔に基づいてチェックポイントが Managed Lustre に保存されます。チェックポイントは、モデルの状態を頻繁にキャプチャします。チェックポイントは、長期保存のために Cloud Storage に選択的にエクスポートできます。
サービング ワークロード
上記のアーキテクチャでは、モデルのサービング時のデータフローは次のようになります。
- サービング用のモデルを読み込む: モデルのデプロイの準備が整うと、GKE Pod は、トレーニング済みのモデルを Managed Lustre インスタンスからサービング ノードに読み込みます。トレーニング中に使用した Managed Lustre インスタンスに十分な IOPS 容量があり、アクセラレータと同じゾーンにある場合は、同じ Managed Lustre インスタンスを使用してモデルをサービングできます。Managed Lustre インスタンスを再利用すると、トレーニングとサービングの間でリソースを効率的に共有できます。最適なパフォーマンスと互換性を維持するには、サービング GKE ノード用に選択した GPU または TPU プロセッサ タイプと同じものを使用します。
- 推論リクエスト: アプリケーション ユーザーは、サービング エンドポイントを介して推論リクエストを送信します。これらのリクエストは、Cloud Load Balancing サービスに転送されます。Cloud Load Balancing は、受信したリクエストを GKE クラスタ内のサービング コンテナに分散します。この分散により、単一のコンテナが過負荷になることがなく、リクエストが効率的に処理されます。
- 推論リクエストのサービング: 推論リクエストを受信すると、コンピューティング ノードはプリロードされたモデルにアクセスして必要な計算を実行し、予測を生成します。
- レスポンス配信: サービス提供コンテナは、Cloud Load Balancing を介してレスポンスを返送します。Cloud Load Balancing は、レスポンスを適切なアプリケーション ユーザーにルーティングして、推論リクエスト サイクルを完了します。
使用するプロダクト
このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。
- Virtual Private Cloud（VPC）: Google Cloud ワークロードにグローバルでスケーラブルなネットワーキング機能を提供する仮想システム。VPC には、VPC ネットワーク ピアリング、Private Service Connect、プライベート サービス アクセス、共有 VPC が含まれます。
- Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサとリージョン ロードバランサのポートフォリオ。
- Google Kubernetes Engine（GKE）: Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションを大規模にデプロイして運用するために使用できる Kubernetes サービス。
- Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
- Google Cloud Managed Lustre: AI、ハイ パフォーマンス コンピューティング（HPC）、データ集約型アプリケーション向けのフルマネージドの並列ファイル システム。
ユースケース
Managed Lustre は、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 は、トレーニング、チェックポイント、サービング ワークロードに使用できます。Cloud Storage FUSE と Anywhere Cache は、Managed Lustre と比較して費用が安く、マルチリージョン推論が容易であるため、サービングと推論におすすめのストレージ ソリューションです。最高レベルの可用性を確保するには、Anywhere Cache とマルチリージョン バケットまたはデュアルリージョン バケットで Cloud Storage FUSE を使用します。この構成により、トレーニング済みの AI モデルを複数のリージョンで使用できるようになります。ただし、Managed Lustre インスタンスと比較すると、Cloud Storage FUSE の VM あたりのスループットが低くなる可能性があります。詳細については、Cloud Storage FUSE を使用して AI / ML ワークロードを最適化するをご覧ください。
設計上の考慮事項
Google Cloudで AI / ML ワークロードのセキュリティ、信頼性、費用、運用、パフォーマンスを最適化する Managed Lustre デプロイを設計するには、次のセクションのガイドラインを使用します。
Google Cloudの AI ワークロードと ML ワークロードに固有のアーキテクチャ原則と推奨事項の概要について、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 クラスタを使用する場合は、次の追加のデータ暗号化機能を使用できます。
- Confidential Google Kubernetes Engine Node を使用して、使用中の（つまりメモリ内の）データを暗号化します。Confidential GKE Node の機能、可用性、制限事項の詳細については、Confidential GKE Node で使用中のワークロード データを暗号化するをご覧ください。
- GKE ノード間で Pod トラフィックを暗号化するために使用される暗号鍵をより詳細に制御する必要がある場合は、管理する鍵を使用して転送中のデータを暗号化できます。詳細については、ユーザー管理の暗号鍵を使用して GKE で転送中のデータを暗号化するをご覧ください。
データの分離
セキュリティを強化し、データ保護を改善するには、チェックポイントとトレーニング済みモデルとは別の 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 はノードプールを自動的に作成し、ワークロードの要件に基づいて自動的にスケーリングします。
アプリケーションの可用性を高めるには、各ゾーンに Managed 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 つの Managed 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 の視点: 費用の最適化をご覧ください。GKE での費用の最適化については、GKE で費用が最適化された Kubernetes アプリケーションを実行するためのベスト プラクティスをご覧ください。
効果的な運用
このセクションでは、効率的に運用できる 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/s を超えるため、クラスタの総スループットが高くなります。この機能を使用すると、数千台の VM でモデルの読み込み時間を最小限に抑えることができます。ボトルネックを特定できる主要な指標を追跡するには、Cloud Monitoring を使用し、ストレージ容量の増加に伴ってパフォーマンスが向上するように十分な容量をデプロイしていることを確認します。
リソースの配置
レイテンシを最小限に抑え、パフォーマンスを最大化するには、GPU または TPU コンピューティング クライアントの地理的位置に近いリージョンに Managed Lustre インスタンスを作成します。このドキュメントで説明するリファレンス アーキテクチャでは、GKE コンテナとファイル システムが同じゾーンに配置されます。
- トレーニングとチェックポイント処理の場合: 最適な結果を得るには、クライアントと Managed Lustre インスタンスを同じゾーンにデプロイします。このコロケーションにより、データ転送時間が最小限に抑えられ、Managed Lustre の書き込みスループットの利用率が最大化されます。
- サービングの場合: 同じゾーンのコンピューティング クライアントと併置するのが理想的ですが、リージョンごとに 1 つの Managed Lustre インスタンスがあれば十分な場合があります。このアプローチでは、複数のインスタンスのデプロイに関連する追加費用を回避し、コンピューティング パフォーマンスを最大化できます。ただし、容量やスループットを追加で必要とする場合は、リージョンごとに複数のインスタンスをデプロイすることを検討してください。
Managed Lustre インスタンスでサポートされているリージョンとゾーンについては、サポートされているロケーションをご覧ください。
パフォーマンスに関するその他の考慮事項
AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: パフォーマンスの最適化をご覧ください。
デプロイ
Managed Lustre インスタンスを作成してマウントするには、Cluster Toolkit で使用可能な Managed Lustre モジュールを使用することをおすすめします。Cluster Toolkit は、Google Cloudで再現可能な AI 環境と ML 環境のデプロイ用に設計された、Terraform ベースのモジュラー ツールキットです。
GKE に Managed Lustre を手動でデプロイする方法については、Managed Lustre インスタンスを作成すると Google Kubernetes Engine から既存の Managed Lustre インスタンスに接続するをご覧ください。
Managed Lustre 用に VPC ネットワークを構成する方法については、VPC ネットワークを構成するをご覧ください。
次のステップ
- HPC ワークロードの並列ファイル システムの使用方法について学習する。
- Google Cloudで ML を実装するためのベスト プラクティスについて学習する。
- Google Cloudで AI / ML ワークロードのストレージを設計する方法を確認する。
- GKE で Keras を使用して TensorFlow モデルをトレーニングする方法について学習する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Samantha He | テクニカル ライター
その他の寄稿者:
- Dean Hildebrand | CTO オフィス テクニカル ディレクター
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
- Sean Derrington | ストレージ担当グループ プロダクト マネージャー