このドキュメントでは、Google Cloud Managed Lustre を使用して、Google Kubernetes Engine（GKE）にデプロイされた AI / ML ワークロードのパフォーマンスを最適化する方法を示すリファレンス アーキテクチャについて説明します。このドキュメントは、 Google Cloudで AI ワークロードのストレージを設計、プロビジョニング、管理するアーキテクトと技術担当者を対象としています。このドキュメントは、Kubernetes のコンセプトと ML のライフサイクル、プロセス、機能を理解していることを前提としています。
Managed Lustre は、DDN の EXAScaler Lustre に基づく、フルマネージドの永続並列ファイル システム（PFS）です。 Google CloudManaged Lustre は、AI トレーニングとチェックポイント処理のワークロードに推奨されるソリューションです。これは、Lustre や他の PFS ソリューションから既存のワークロードを移行する場合に特に効果的です。リソースを最大限活用するためには、Managed Lustre を使ってトレーニングするワークロードでもサービングおよび推論と同じインスタンスを使用する必要があります。
Managed Lustre は、次の条件を満たす AI ワークロードに推奨されるソリューションです。
- PiB 規模のストレージ容量が必要。
- 高スループットで超低レイテンシ（ミリ秒未満）のアクセスを提供します。
- 高い 1 秒あたりの入出力オペレーション（IOPS）を実現する。
Managed Lustre には、AI ワークロードに対して次のような利点があります。
- トレーニングの総所有コスト（TCO）を削減: Managed Lustre は、コンピューティング ノードにデータを効率的に配信することで、トレーニング時間を短縮します。この機能により、AI モデルと ML モデルのトレーニングの総所有コストを削減できます。
- サービングの TCO を低減: Managed Lustre は、モデルの読み込みを高速化し、推論サービングを最適化する高性能機能を提供します。これらの機能は、コンピューティング費用を低減し、リソース使用率の向上に役立ちます。
- 効率的なリソース使用: Managed Lustre を使用すると、チェックポイント処理とトレーニングを 1 つのインスタンス内で行うことができます。このようにリソースを共有することで、高パフォーマンスの単一のストレージ システムで読み取り / 書き込みスループットを効率的に使用できます。
アーキテクチャ
次の図は、Managed Lustre を使用してモデルのトレーニング ワークロードとサービング ワークロードのパフォーマンスを最適化するアーキテクチャの例を示しています。
上記のアーキテクチャに示されているワークロードについては、後のセクションで詳しく説明します。このアーキテクチャには次のコンポーネントが含まれています。
- GKE クラスタ: 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 では、Time to First Byte（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 クラスタ内のサービング コンテナに分散します。この分散により、1 つのコンテナが過負荷になることがなく、リクエストが効率的に処理されます。
- 推論リクエストのサービング: 推論リクエストを受信すると、コンピューティング ノードは読み込み済みのモデルにアクセスして、必要な計算を実行し、予測を生成します。
- レスポンスの配信: サービング コンテナが 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 に Managed 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 の料金をご覧ください。
ストレージの代替手段
Rapid Cache を備えた Cloud Storage FUSE は、トレーニング、チェックポイント処理、サービング ワークロードに使用できます。Rapid Cache を備えた Cloud Storage FUSE は、Managed Lustre と比較して費用が低く、マルチリージョン推論が容易なため、サービングと推論に推奨されるストレージ ソリューションです。最高レベルの可用性を確保するには、Rapid 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 で顧客管理の暗号鍵（CMEK）を使用して、Managed Lustre インスタンスの保存データを暗号化できます。また、アプリケーション レイヤで GKE シークレットを暗号化することもできます。詳細については、顧客管理の暗号鍵の使用とアプリケーション レイヤで 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 ワークフローのインフラストラクチャを設計する際に役立つガイダンスを提供します。
モデル管理
バイナリやメタデータなどのモデル アーティファクトを追跡して管理するには、Gemini Enterprise Agent Platform の Model Registry を使用します。これにより、モデル バージョンをシームレスに保存、整理、デプロイできます。
モデルの信頼性を最適化するには、Gemini Enterprise Agent Platform で Model Monitoring を実装して、データのドリフトを検出し、パフォーマンスを追跡し、本番環境の異常を特定します。
GKE クラスタの自動スケーリング
Autopilot クラスタを使用すると、ノードプールのプロビジョニングや管理を行う必要がなくなります。ノードプールはノード自動プロビジョニングによって自動的にプロビジョニングされ、ワークロードの要件に合わせて自動スケーリングされます。
GKE Standard クラスタの場合、クラスタ オートスケーラーは、ワークロードの需要に基づいてノードプール内のノード数を自動的に変更します。クラスタ オートスケーラーの自動スケーリング動作を制御するには、ノードプールの最小サイズと最大サイズを指定します。
GKE クラスタ オートスケーラーを使用する場合は、クラスタノードで マネージド インスタンス グループ（MIG）に対する Compute Engine の自動スケーリングを有効にしないでください。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 のワークフローのパフォーマンスを最適化するためのガイダンスを示します。このセクションのガイダンスはすべてを網羅しているわけではありません。Managed Lustre 環境のパフォーマンスの最適化の詳細については、パフォーマンスに関する考慮事項をご覧ください。
トレーニングに関する考慮事項
各 A3 または A4 VM は、Managed 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 は、20 GB/秒を超える高い VM あたりのスループットを提供し、クラスタの総スループットを向上させます。この機能により、数千台の 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 インスタンスを作成すると Managed Lustre CSI ドライバを使用して GKE の既存の Managed Lustre インスタンスにアクセスするをご覧ください。
Managed Lustre 用に VPC ネットワークを構成する方法については、VPC ネットワークを構成するをご覧ください。
次のステップ
- Google Cloudで ML を実装するためのベスト プラクティスの詳細を確認する。
- AI Hypercomputer の AI / ML ワークロード向けストレージ サービスの詳細を確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者: Samantha He | テクニカル ライター
その他の寄稿者:
- Dean Hildebrand | CTO オフィス テクニカル ディレクター
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
- Sean Derrington | ストレージ担当グループ プロダクト マネージャー