Cloud Storage FUSE で AI ワークロードと ML ワークロードを最適化する

このドキュメントでは、Cloud Storage FUSE を使用して Google Kubernetes Engine（GKE）で AI ワークロードと ML ワークロードのパフォーマンスを最適化する方法を示すリファレンス アーキテクチャについて説明します。

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

Cloud Storage FUSE は、Cloud Storage バケットをローカル ファイル システムとしてマウントできるオープンソースの FUSE アダプタです。この構成により、アプリケーションは標準のファイルのようなシステム セマンティクスを使用して、クラウドベースのストレージ バケットとシームレスにやり取りできます。Cloud Storage FUSE を使用すると、Cloud Storage のスケーラビリティと費用対効果を活用できます。

アーキテクチャ

パフォーマンス、可用性、障害復旧（DR）の要件に応じて、次のいずれかの Google Cloud デプロイ アーキタイプを選択して、AI ワークロードと ML ワークロードを Google Cloudで実行できます。

• リージョン: アプリケーションは、単一のGoogle Cloud リージョン内で独立して実行されます。ミッション クリティカルではないものの、ゾーンの停止に対する堅牢性が必要なアプリケーションには、このデプロイ アーキタイプをおすすめします。
• マルチリージョン: アプリケーションは、2 つ以上の Google Cloud リージョンで、アクティブ / アクティブまたはアクティブ / パッシブモードのいずれかで独立して実行されます。このデプロイ アーキタイプは DR シナリオに最適です。リージョンの停止や障害に対する復元力を必要とするミッション クリティカルなアプリケーションには、このデプロイ アーキタイプをおすすめします。デュアルリージョンまたはマルチリージョン デプロイでは、リソースの近接性を高めることでレイテンシを短縮し、スループットを向上させることができます。

選択したデプロイ アーキタイプは、アーキテクチャに必要な Google Cloud プロダクトと機能に影響します。マルチリージョン アーキテクチャでは、Anywhere Cache が使用されます。Anywhere Cache がワークロードに適しているかどうかを評価するには、Anywhere Cache Recommender を使用して、データ使用量とストレージを分析します。

次のタブは、リージョンとマルチリージョンのデプロイ アーキタイプの参照アーキテクチャを示しています。

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

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

1. トレーニング データを Cloud Storage に読み込む: トレーニング データは、階層名前空間が有効になっている Cloud Storage バケットにアップロードされます。Cloud Storage は、スケーラブルな中央リポジトリとして機能します。
2. GKE でトレーニング データを読み込んでトレーニング ジョブを実行する: GKE Pod にマウントされた Cloud Storage バケットにより、トレーニング アプリケーションは FUSE インターフェースを使用してトレーニング データを効率的に読み込んでアクセスできます。GKE ノードは、マウントされたファイル キャッシュをデータソースとして使用して、モデル トレーニング プロセスを実行します。トレーニング アプリケーションは、モデルのトレーニングに必要な複雑な計算を実行するために、トレーニング データをマシン アクセラレータに継続的に供給します。ワークロードの要件に応じて、GPU または TPU を使用できます。適切なプロセッサ タイプを選択する方法については、このドキュメントの後半にあるアクセラレータ オプションをご覧ください。

3. チェックポイントとモデルの保存と復元:

   • チェックポイントまたはモデルを保存する: トレーニング中に、チェックポイントを保存して、頻繁な間隔で別の Cloud Storage バケットに非同期で保存します。チェックポイントは、ユーザーが定義した指標または間隔に基づいてモデルの状態をキャプチャします。
   • チェックポイントまたはモデルを復元する: トレーニング ワークロードでチェックポイントまたはモデルデータの復元が必要な場合は、Cloud Storage で復元するアセットを見つける必要があります。復元されたチェックポイントまたはモデルを使用して、トレーニングの再開、パラメータのファインチューニング、検証セットでのパフォーマンスの評価を行うことができます。

サービング ワークロード

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

1. モデルを読み込む: トレーニングが完了すると、Pod は並列ダウンロードが有効になっている Cloud Storage FUSE を使用して、トレーニング済みのモデルを読み込みます。並列ダウンロードでは、モデルの一部を Cloud Storage から並列で取得することで、モデルの読み込みを高速化します。モデルの読み込み時間を大幅に短縮するため、プロセスはキャッシュ ディレクトリをプリフェッチ バッファとして使用します。
2. 推論リクエスト: アプリケーション ユーザーは、Cloud Load Balancing サービスを介して AI アプリケーションと ML アプリケーションから推論リクエストを送信します。Cloud Load Balancing は、受信したリクエストを GKE クラスタ内のサービング コンテナに分散します。この分散により、単一のコンテナが過負荷になることがなく、リクエストが効率的に処理されます。
3. レスポンスの配信: ノードがリクエストを処理し、予測を生成します。サービング コンテナは、Cloud Load Balancing を介してアプリケーション ユーザーにレスポンスを返します。

使用するプロダクト

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

• Google Kubernetes Engine（GKE）: Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションを大規模にデプロイして運用するために使用できる Kubernetes サービス。
• Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
• Virtual Private Cloud（VPC）: Google Cloud ワークロードにグローバルでスケーラブルなネットワーキング機能を提供する仮想システム。VPC には、VPC ネットワーク ピアリング、Private Service Connect、プライベート サービス アクセス、共有 VPC が含まれます。
• Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサとリージョン ロードバランサのポートフォリオ。
• Cloud DNS: Google の世界規模のネットワークから復元力のある低レイテンシの DNS サービスを提供するサービス。

ユースケース

大容量のストレージと高パフォーマンスのファイル アクセスを必要とする AI / ML ワークロードには、Cloud Storage FUSE を中心に構築されたアーキテクチャを使用することをおすすめします。適切な計画を立てることで、これらのアーキテクチャで 1 TB/秒を超えるスループットを実現できます。また、Cloud Storage FUSE を使用すると、AI / ML ワークフローのすべてのステージで単一の信頼できる情報源として機能する中央ストレージ リポジトリを活用できます。このアプローチは、規模やサイズに関係なく、あらゆるワークロードで使用できます。

これらのワークロードでは、Cloud Storage FUSE には次のメリットがあります。

• データアクセスの簡素化: Connector for PyTorch、JAX、TensorFlow などの AI / ML フレームワークを使用して、トレーニング データとチェックポイントにアクセスします。AI と ML のフレームワークを介してデータにアクセスすることで、コードのリファクタリングが不要になります。
• 高速起動: Cloud Storage FUSE を使用して Cloud Storage のデータに直接アクセスすることで、大規模なデータセットをコンピューティング リソースにダウンロードする必要がなくなります。データに直接アクセスできるため、ジョブの起動時間が短縮されます。
• 費用対効果: Cloud Storage の固有のスケーラビリティと費用対効果を活用して、費用を最適化します。

Cloud Storage FUSE は、50 MB 未満のファイルを含むレイテンシの影響を受けやすいワークロードや、ランダム I/O とメタデータ アクセスに 1 ミリ秒未満のレイテンシを必要とするワークロードには適していません。

大量のデータを使用するトレーニングやチェックポイント、再起動のワークロードの場合、I/O 集約型のトレーニング フェーズでストレージの代替手段を検討してください。

代替案を設計する

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

プラットフォームの代替

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

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

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

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

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

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

ストレージの代替手段

Cloud Storage FUSE は、Cloud Storage のスケーラビリティと費用対効果を活用できる便利なファイル システムを提供します。ただし、Cloud Storage FUSE は、小さなファイルの読み取りで低レイテンシを必要とするワークロードや、POSIX 準拠の完全なストレージ ソリューションを必要とするワークロードには適していません。このようなユースケースでは、次のストレージの代替案を検討することをおすすめします。

• Google Cloud Hyperdisk ML: 数百 GB から 64 TB の小規模な読み取り専用データセットを持つ数百ノードの大規模クラスタを使用するワークロードに最適な高パフォーマンスのブロック ストレージ ソリューション。Hyperdisk ML は Cloud Storage よりもスループットが高く、読み取り専用モードで複数の VM にアタッチできます。Kubernetes ReadOnlyMany アクセスモードを使用すると、モデル レジストリから直接読み込む場合と比較して、Hyperdisk ML でモデル重みの読み込みを高速化できます。AI ワークロードと ML ワークロードでの Hyperdisk ML の使用の詳細については、Hyperdisk ML で AI/ML データの読み込みを高速化するをご覧ください。
• Connector for PyTorch: Cloud Storage のオープンソース プロダクトで、PyTorch を使用するワークロードに最適です。Connector for PyTorch は、Cloud Storage バケットからデータを直接ストリーミングし、中間ストレージの必要性を排除することで、トレーニング ワークロードを最適化します。この直接アクセスと最適化により、データの読み込み、トレーニング、チェックポイント設定で、Cloud Storage に対する直接 API 呼び出しよりも大幅に優れたパフォーマンスを実現できます。

代替ストレージ オプションは、特定の AI / ML ワークロードでパフォーマンス上のメリットをもたらす可能性がありますが、レイテンシ、スループット、ストレージ容量のニーズを評価することが重要です。

AI / ML ワークロードのストレージ オプションの包括的な比較については、 Google Cloudで AI と ML ワークロードのストレージを設計するをご覧ください。

設計上の考慮事項

このセクションでは、セキュリティ、信頼性、費用、パフォーマンスのために Cloud Storage FUSE を構成するためのベスト プラクティスと設計上の考慮事項について説明します。ここで説明する推奨事項はすべてではありませんが、環境で Cloud Storage FUSE のメリットを最大限に活用するための重要な考慮事項に対処しています。特定のニーズとワークロードの特性によっては、追加の構成オプションとトレードオフを検討する必要がある場合があります。

次の設計に関する推奨事項では、GKE で Cloud Storage FUSE をデプロイする方法を改善するための構成について説明します。Cloud Storage FUSE オプションのほとんどは、マウント オプションで構成されます。Cloud Storage FUSE コマンドライン オプションとその使用方法の詳細については、gcsfuse CLI と GKE のパフォーマンスを向上させるために Cloud Storage FUSE CSI ドライバを最適化するをご覧ください。

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

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

GKE の考慮事項

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

• GKE Autopilot のセキュリティ機能
• GKE Autopilot で Kubernetes のセキュリティを簡単に確保

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

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

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

• Confidential GKE Node を使用して、使用中の（つまりメモリ内の）データを暗号化します。Confidential GKE Node の機能、可用性、制限事項の詳細については、Confidential GKE Node で使用中のワークロード データを暗号化するをご覧ください。
• GKE ノード間で Pod トラフィックを暗号化するために使用される暗号鍵をより詳細に制御する必要がある場合は、管理する鍵を使用して転送中のデータを暗号化できます。詳細については、ユーザー管理の暗号鍵を使用して GKE で転送中のデータを暗号化するをご覧ください。

Cloud Storage に関する考慮事項

デフォルトでは、Cloud Storage に保存されるデータは Google-owned and Google-managed encryption keysを使用して暗号化されます。必要に応じて、顧客管理の暗号鍵（CMEK）を使用するか、顧客指定の暗号鍵（CSEK）などの外部の管理方法で管理する独自の鍵を使用できます。詳細については、データ暗号化オプションをご覧ください。

Cloud Storage は、バケットとオブジェクトにアクセスするためのユーザー権限を付与する 2 つのシステムをサポートしています。1 つは IAM、もう 1 つはアクセス制御リスト（ACL）です。ほとんどの場合は IAM の使用をおすすめします。これにより、バケットレベルとプロジェクト レベルで権限を付与できます。詳細については、アクセス制御の概要をご覧ください。

Cloud Storage を介して読み込むトレーニング データには、機密データが含まれる場合があります。このようなデータを保護するには、Sensitive Data Protection を使用してデータを検出、分類、匿名化します。トレーニング ワークロードとサービング ワークロードを分離するには、モデルとチェックポイントを別々の Cloud Storage バケットに保存します。この分離により、サービング中にトレーニング データセットから機密情報が誤って公開されるのを防ぐことができます。詳細については、Cloud Storage での Sensitive Data Protection の使用をご覧ください。

データ所在地の要件がある場合は、Cloud Storage を使用して要件を満たすことができます。データは、指定したリージョン内で保存または複製されます。

Cloud Storage FUSE の考慮事項

キャッシュ保存を有効にすると、Cloud Storage FUSE は、指定したディレクトリ内の暗号化されていない形式で、Cloud Storage バケットの永続ファイルを保存します。Cloud Storage は、ディレクトリ アクセス権を持つすべてのユーザーまたはプロセスにすべてのファイルを公開します。これらのリスクを軽減し、セキュリティを強化するため、FUSE カーネルレイヤは、システムをマウントしたユーザーにファイル システムへのアクセスを制限します。この制限により、inode 権限が緩やかであっても、ルートユーザーを含む他のユーザーはアクセスできなくなります。

ただし、デフォルトのアクセス制限をオーバーライドする必要があるユースケースもあります。たとえば、複数のノードが Cloud Storage に保存されているチェックポイントにアクセスして共有する必要がある分散 AI と ML のトレーニング ワークロードでは、より広範なアクセスを許可する必要がある場合があります。このような場合は、-o allow_other オプションを使用してデフォルトの制限をオーバーライドできます。ただし、ファイルへのアクセス権を拡大すると、権限のないユーザーにデータが公開される可能性があります。そのため、このオプションを使用する際は注意が必要です。

デフォルトでは、Cloud Storage FUSE ファイル システム内のすべての inode は、ファイル システムをマウントしたユーザーが所有します。これらのデフォルトは多くのケースに適していますが、Pod のセキュリティ コンテキストをカスタマイズすることもできます。セキュリティ コンテキストのカスタマイズについては、セキュリティと権限をご覧ください。

信頼性

信頼性の高いオペレーションを確保するため、Cloud Storage FUSE には、潜在的な中断を処理してデータの整合性を維持するための自動再試行が組み込まれています。失敗したリクエストは、Cloud Storage への指数バックオフで自動的に再試行されます。指数バックオフでは、再試行の間隔が徐々に長くなります。この組み込みメカニズムにより、アプリケーションは一時的なネットワークの問題や Cloud Storage の一時的な利用不可を克服できます。

Cloud Storage FUSE には多くの利点がありますが、次の点に注意してください。

• 同時書き込み: 複数のユーザーがファイルを変更しようとすると、最後の書き込みが優先されるオペレーションが優先され、それ以前の書き込みオペレーションはすべて失われます。データの整合性を維持するため、特定のオブジェクトは常に 1 つのソースによってのみ変更されるようにすることをおすすめします。
• キャッシュの永続性: バケットのマウントを解除するか、バケットを再起動すると、キャッシュは永続化されません。セキュリティ上の問題を回避するため、バケットのマウントを解除するか再起動した後は、ファイル キャッシュ ディレクトリを手動で削除することが重要です。
• 専用キャッシュを使用するプロセス: Cloud Storage FUSE は効率的な並列処理のために同時アクセスをサポートしていますが、キャッシュは各 Cloud Storage FUSE プロセスに固有であることに注意してください。そのため、同じマシンまたは別のマシンで実行されている別の Cloud Storage FUSE プロセスで同じキャッシュ ディレクトリを使用しないでください。

ワークロードのアーキテクチャを構築する際には、Well-Architected Framework: 信頼性の柱に記載されている一般的なベスト プラクティスと推奨事項も検討してください。

費用の最適化

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

GKE の考慮事項

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

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

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

費用最適化のガイダンスについて詳しくは、GKE で費用が最適化された Kubernetes アプリケーションを実行するためのベスト プラクティスをご覧ください。

Cloud Storage に関する考慮事項

AI / ML のストレージ ニーズは動的になる可能性があります。たとえば、トレーニング データには大容量のストレージが必要になる場合がありますが、サービングでは主にモデルデータとチェックポイントを保存するため、容量要件が減少します。費用を管理するには、オブジェクトのライフサイクル管理と Autoclass を有効にすることをおすすめします。

オブジェクトのライフサイクル管理を使用すると、設定したルールに基づいて、古いデータや未使用のデータを低コストのストレージ クラスに自動的に移動したり、データを削除したりできます。

Autoclass 機能は、アクセス パターンに基づいてストレージ クラス間でデータを自動的に移動します。この機能により、パフォーマンスと費用のバランスを最適に保つことができます。

Cloud Storage FUSE の考慮事項

FUSE アクティビティによって生成されるストレージ、メタデータ オペレーション、ネットワーク トラフィックには、標準の Cloud Storage 料金が適用されます。Cloud Storage FUSE の使用に追加料金はかかりません。一般的な Cloud Storage FUSE オペレーションと、そのオペレーションを Cloud Storage オペレーションにマッピングする方法については、オペレーション マッピングをご覧ください。

キャッシュ ディレクトリの費用を最適化するには、ローカル SSD、Persistent Disk、メモリ内データなど、すでにプロビジョニングされているマシン容量を一時ファイル システムに使用できます。既存のマシン容量を使用すると、追加のストレージ リソースに対する課金を回避できます。また、キャッシュ ヒットを最大化すると、ローカルで処理されるデータにはオペレーション料金やネットワーク下り（外向き）料金が発生しないため、Cloud Storage の費用を大幅に削減できます。

料金の詳細については、Cloud Storage の料金をご覧ください。

ワークロードのアーキテクチャを構築する際には、Well-Architected Framework: 費用の最適化の柱に記載されている一般的なベスト プラクティスと推奨事項も検討してください。

パフォーマンスの最適化

Cloud Storage FUSE は、AI / ML ワークロードの Cloud Storage 内のデータに効率的にアクセスできるように設計されています。ただし、メタデータ リクエストが頻繁に行われると、特に大規模なクラスタでパフォーマンスが低下する可能性があります。パフォーマンスの向上について詳しくは、GKE のパフォーマンスを向上させるために Cloud Storage FUSE CSI ドライバを最適化するをご覧ください。

パフォーマンスを最適化するには、次の構成を検討してください。

• 階層型名前空間を有効にする: データアクセスと組織を強化するには、階層型名前空間を有効にして Cloud Storage バケットを作成します。階層型名前空間を使用すると、データをファイル システム構造で整理できます。これにより、パフォーマンスが向上し、整合性が確保され、AI ワークロードと ML ワークロードの管理が簡素化されます。階層型名前空間を使用すると、初期 QPS が向上し、高速なアトミック ディレクトリ名の変更が可能になります。

• ファイル キャッシュを有効にする: ファイル キャッシュは、ローカル ノード ディレクトリを使用して頻繁に読み取られるファイルをキャッシュに保存することで、トレーニング データへの繰り返しアクセスを高速化します。キャッシュ メディアから繰り返し読み取りを行うと、レイテンシが短縮され、Cloud Storage へのオペレーションが最小限に抑えられます。ローカル SSD を備えた GPU マシンタイプでは、ローカル SSD ディレクトリが自動的に使用されます。TPU など、ローカル SSD が含まれていないマシンタイプの場合は、/tmpfs などの RAM ディスク ディレクトリを使用できます。

  ファイル キャッシュを有効にするには、次のマウント オプションを使用します。

  • 使用可能なファイル キャッシュの値をキャッシュ容量の上限に設定するには、file-cache:max-size-mb: を -1 に設定します。
  • メタデータ キャッシュの有効期間（TTL）を無制限に設定し、最大容量に達した後に LRU（Least Recently Used）アルゴリズムに基づいてエビクションを行うには、metadata-cache:ttl-secs: を -1 に設定します。

• メタデータ キャッシュの値を増やす: Cloud Storage FUSE には、メタデータ ルックアップに関連するオペレーションのパフォーマンスを向上させる 2 種類のメタデータ キャッシュ（統計情報キャッシュと型キャッシュ）があります。

  メタデータ キャッシュ値を増やすには、次のマウント オプションを設定します。

  • 使用可能な統計情報キャッシュの値をキャッシュ容量の上限に設定するには、metadata-cache:stat-cache-max-size-mb: を -1 に設定します。
  • 使用可能なタイプ キャッシュの値を容量上限に設定するには、metadata-cache:type-cache-max-size-mb: を -1 に設定します。
  • キャッシュに保存されたメタデータ アイテムの有効期限が切れないようにするには、デフォルト値の 60 秒で metadata-cache:ttl-secs: を -1 に設定します。無限値は、読み取り専用ボリュームと大容量メモリ構成のノードにのみ使用してください。

• メタデータ キャッシュに事前にデータを入力する: メタデータ プリフェッチ機能を使用すると、Cloud Storage FUSE CSI ドライバは、Cloud Storage バケット内のオブジェクトに関する関連メタデータを Cloud Storage FUSE キャッシュに事前に読み込みます。このアプローチにより、Cloud Storage への呼び出しが減り、AI や ML のトレーニング ワークロードなど、多くのファイルを含む大規模なデータセットにアクセスするアプリケーションに特に有益です。

  メタデータ キャッシュに事前入力するには、指定されたボリュームのメタデータ プリフェッチを有効にします。音量属性 gcsfuseMetadataPrefetchOnMount を true に設定します。

• リスト キャッシュ保存を有効にする: この機能は、ディレクトリとファイルの一覧表示を最適化します。これは、ディレクトリ全体へのアクセスとリスティングを繰り返すことが多い AI と ML のトレーニング ワークロードに特に有益です。リスト キャッシュ保存により、コンピュータのメモリ内のディレクトリ リストに繰り返しアクセスする必要性が減り、トレーニング プロセスが非常に効率的になります。

  リスト キャッシュ保存を有効にして、カーネルリスト キャッシュ アイテムの有効期限が切れないようにするには、マウント オプション file-system:kernel-list-cache-ttl-secs: を -1 に設定します。

• 並列ダウンロードを有効にする: 並列ダウンロードは、複数のチャンクを同時に取得することで、モデルの初期読み込みを高速化します。並列ダウンロードを有効にすると、モデルの読み込みが高速になり、サービング中の応答性が向上します。

  並列ダウンロードを有効にするには、ファイル キャッシュを有効にして、マウント オプション file-cache:enable-parallel-downloads: を true に設定します。

• GKE サイドカーの上限を引き上げる: リソースの制約によってパフォーマンスが低下しないように、CPU やメモリ使用量などのサイドカー コンテナのリソースの上限を構成します。ローカル SSD キャッシュを使用する場合は、ephemeral-storage-limit を無制限に設定することを検討してください。この設定により、Cloud Storage FUSE は、使用可能なローカル SSD ストレージをキャッシュの強化に最大限に活用できます。

• 読み取り専用マウント: トレーニング ワークロードでは通常、データの読み取りのみが必要になるため、特にファイル キャッシュを使用する場合は、最適なパフォーマンスを得るためにマウント ポイントを読み取り専用として構成します。この構成は、大規模クラスタでの最適化のメリットを最大化し、データ不整合の可能性を防ぐうえでも役立ちます。

ワークロードのアーキテクチャを構築する際には、Well-Architected Framework: パフォーマンスの最適化の柱に記載されている一般的なベスト プラクティスと推奨事項も検討してください。

次のステップ

• 詳細:
  • Cloud Storage FUSE の概要。
  • GKE 用の Cloud Storage FUSE CSI ドライバについて。
  • GKE のパフォーマンスを向上させるために Cloud Storage FUSE CSI ドライバを最適化する。
  • Google Cloudで ML を実装するためのベスト プラクティス。
  • Google Cloudで AI と ML ワークロードのストレージを設計する。
• 実装:
  • A4 ノードを使用して GKE クラスタを作成します。
  • クイックスタート: FUSE CSI ドライバを使用して Cloud Storage バケットにアクセスする。
  • Anywhere Cache のキャッシュを作成して管理する。
• Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。

寄稿者

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

その他の寄稿者:

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