GKE のパフォーマンスを向上させるために Cloud Storage FUSE CSI ドライバを最適化する

このガイドでは、Google Kubernetes Engine（GKE）で Cloud Storage FUSE CSI ドライバのパフォーマンスを最適化する方法について説明します。

Cloud Storage FUSE は柔軟性とスケーラビリティを提供しますが、最適なパフォーマンスを実現するには、慎重な構成とチューニングが重要です。Cloud Storage FUSE のパフォーマンスは、レイテンシ、スループット、整合性に関して POSIX ファイル システムと異なる場合があります。チューニングの目的は、メタデータ オペレーションのオーバーヘッドを最小限に抑え、データアクセスの効率を最大化することである。Cloud Storage バケット内のデータを使用する AI/ML アプリケーションを実行している場合は、CSI ドライバをチューニングすると、AI/ML アプリケーションのトレーニング時間と推論時間を短縮できます。

このガイドは、Cloud Storage バケットに保存されているデータにアクセスするアプリケーションのパフォーマンスを向上させたいデベロッパーと ML エンジニアを対象としています。

このページを読む前に、Cloud Storage、Kubernetes、Cloud Storage FUSE CSI ドライバの基本を理解しておいてください。使用する特定の機能の GKE バージョンの要件も確認してください。

マウント オプションを構成する

Cloud Storage FUSE CSI ドライバは、Cloud Storage バケットをローカル ファイル システムにどのようにマウントするかを構成するマウント オプションをサポートします。サポートされているマウント オプションの全一覧については、Cloud Storage FUSE CLI ファイルのドキュメントをご覧ください。

マウント オプションは、使用しているボリュームのタイプに応じて、次の方法で指定できます。

CSI エフェメラル ボリューム

CSI エフェメラル ボリュームを使用する場合は、Pod マニフェストの spec.volumes[n].csi.volumeAttributes.mountOptions フィールドにマウント オプションを指定します。

マウント オプションは文字列として指定し、フラグをカンマで区切ってスペースを入れないようにします。次に例を示します。

  mountOptions: "implicit-dirs,file-cache:enable-parallel-downloads:true,file-cache:download-chunk-size-mb:3"

永続ボリューム

永続ボリュームを使用する場合は、PersistentVolume マニフェストの spec.mountOptions フィールドにマウント オプションを指定します。

マウント オプションはリストとして指定する必要があります。次に例を示します。

  mountOptions:
    - implicit-dirs
    - file-cache:enable-parallel-downloads:true
    - file-cache:download-chunk-size-mb:3

マウントに関する考慮事項

CSI ドライバでマウントを構成する際は、次の点を考慮してください。

一般的な考慮事項

  • 次のフラグは使用できません: app-name、temp-dir、foreground、log-file、log-format、key-file、token-url、reuse-token-from-url。
  • Cloud Storage FUSE では、デフォルトで暗黙のディレクトリは表示されません。
  • バケット全体ではなくバケット内のディレクトリのみをマウントする場合は、only-dir=relative/path/to/the/bucket/root フラグを使用してディレクトリの相対パスを渡します。

セキュリティと権限

  • Pod またはコンテナにセキュリティ コンテキストを使用する場合、またはコンテナ イメージが root 以外のユーザーまたはグループを使用する場合は、uid と gid のマウントフラグを設定する必要があります。ファイル システムの権限を設定するには、file-mode マウントフラグと dir-mode マウントフラグも使用する必要があります。Cloud Storage FUSE ファイル システムに対して chmod、chown、chgrp コマンドを実行することはできません。したがって、uid、gid、file-mode、dir-mode マウントフラグを使用して、root 以外のユーザーまたはグループにアクセス権を付与する必要があります。

Linux カーネルのマウント オプション

  • Linux カーネルのマウント オプションを構成する必要がある場合は、o フラグを使用してオプションを渡すことができます。たとえば、マウントされたファイル システムでバイナリの直接実行を許可しない場合は、o=noexec フラグを設定します。各オプションには、o=noexec、o=noatime などの個別のフラグが必要です。使用できるオプションは、exec、noexec、atime、noatime、sync、async、dirsync のみです。

キャッシュを構成する

このセクションでは、パフォーマンスを向上させるために Cloud Storage FUSE CSI ドライバで使用できるキャッシュ オプションの概要について説明します。

ファイルのキャッシュ保存

Cloud Storage FUSE CSI ドライバとファイル キャッシュを併用することで、Cloud Storage バケットの小さなファイルを扱うアプリケーションの読み取りパフォーマンスを改善できます。Cloud Storage FUSE ファイル キャッシュ機能は、クライアント ベースの読み取りキャッシュで、これにより、選択したキャッシュ ストレージから繰り返し行うファイルの読み取りを、より短時間で行えるようにします。

読み取りキャッシュは、ローカル SSD、Persistent Disk ベースのストレージ、RAM ディスク（メモリ）などのさまざまなストレージ オプションから、価格とパフォーマンスのニーズに基づいて選択できます。

ファイル キャッシュを有効にして使用する

デフォルトでは、GKE におけるファイル キャッシュ機能は無効になっています。Cloud Storage FUSE CSI ドライバでファイル キャッシュを有効にするには、オプトインする必要があります。

ファイル キャッシュを有効にして制御するには、ボリューム属性 fileCacheCapacity を設定するか、file-cache:max-size-mb マウント オプションを使用します。

GKE は、ノードに構成されたエフェメラル ストレージを基盤とする Cloud Storage FUSE ファイル キャッシュに、デフォルトで emptyDir ボリュームを使用します。これは、ノードに接続されているブートディスクまたはノードのローカル SSD です。ノードでローカル SSD を有効にすると、GKE はローカル SSD を使用して emptyDir ボリュームをサポートします。

読み取りオペレーションにおけるファイル キャッシュのデフォルトの emptyDir ボリュームは、サイドカー コンテナのカスタム読み取りキャッシュ ボリュームを構成することで置き換えできます。

ファイル キャッシュのベスト プラクティスの詳細については、Cloud Storage FUSE のパフォーマンスをご覧ください。

ファイル キャッシュのバックアップ用ストレージを選択する

ファイル キャッシュのバックアップ用ストレージを選択するには、次の点を考慮してください。

  • ローカル SSD をサポートする GPU VM ファミリーと CPU VM ファミリー（A3 VM など）では、ローカル SSD を使用することをおすすめします。

    • A3 以降の VM の場合、GKE は Pod が使用できるようにローカル SSD を自動的に設定します。
    • VM ファミリーがローカル SSD をサポートしていない場合、GKE はブートディスクを使用してキャッシュに保存します。GKE のブートディスクのデフォルトのディスクタイプは pd-balanced です。

    • VM ファミリーがローカル SSD をサポートしているが、ローカル SSD のエフェメラル ストレージがデフォルトで有効になっていない場合は、ノードプールでローカル SSD を有効にできます。これは、N1 マシンや N2 マシンなど、第 1 世代と第 2 世代のマシン ファミリーに適用されます。詳細については、ローカル SSD を使用するクラスタを作成するをご覧ください。

      ノードでローカル SSD のエフェメラル ストレージが有効になっているかどうかを確認するには、次のコマンドを実行します。

      kubectl describe node <code><var>NODE_NAME</var></code> | grep "cloud.google.com/gke-ephemeral-storage-local-ssd"

  • TPU VM ファミリー（特に v6 以降）では、これらの VM インスタンスの RAM が大きいため、最適なパフォーマンスを得るためにファイル キャッシュとして RAM を使用することをおすすめします。

    • RAM を使用する場合は、メモリ不足（OOM）エラーに注意してください。これは Pod の中断を引き起こします。Cloud Storage FUSE はメモリを使用するため、サイドカー コンテナを使用するようにファイル キャッシュを設定すると、OOM エラーが発生する可能性があります。このようなシナリオを回避するには、ファイル キャッシュ構成の file-cache:max-size-mb フィールドを小さい値に調整します。
    • 他の TPU ファミリーの場合は、pd-balanced または pd-ssd を使用することをおすすめします。GKE のブートディスクのデフォルトのディスクタイプは pd-balanced です。

  • パフォーマンスの低下や予期しない終了につながる可能性があるため、ブートディスクをキャッシュに使用しないでください。代わりに、Persistent Disk を基盤とする PersistentVolume の使用を検討してください。

RAM ディスクベースのファイル キャッシュを使用する

十分な大きさの RAM を備えた TPU VM を使用している場合は、ファイル キャッシュまたは並列ダウンロードに RAM ディスクを使用して、ブートディスクまたは永続ディスクを使用するオーバーヘッドを削減できます。

Cloud Storage FUSE CSI ドライバで RAM ディスクを使用するには、マニフェストに次の行を追加します。

volumes:
  - name: gke-gcsfuse-cache
    emptyDir:
      medium: Memory

統計情報キャッシュ

Cloud Storage FUSE CSI ドライバは、サイズや変更時間などのファイル メタデータをキャッシュに保存することでパフォーマンスを向上させます。CSI ドライバはデフォルトでこの統計キャッシュを有効にし、Cloud Storage から情報を繰り返しリクエストするのではなく、ローカルに保存することでレイテンシを短縮します。最大サイズ（デフォルトは 32 MB）と、キャッシュにデータが保持される時間（デフォルトは 60 秒）を構成できます。メタデータ キャッシュを微調整することで、Cloud Storage への API 呼び出しを減らし、ネットワーク トラフィックとレイテンシを最小限に抑えて、アプリケーションのパフォーマンスと効率を向上させることができます。

統計情報のキャッシュ保存のベスト プラクティスの詳細については、Cloud Storage FUSE のキャッシュ保存の概要をご覧ください。

メタデータ プリフェッチを使用してメタデータ キャッシュに事前入力する

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

この機能には、GKE バージョン 1.31.3-gke.1162000 以降が必要です。

メタデータ プリフェッチによるパフォーマンスの向上を確認するには、メタデータ キャッシュ アイテムの有効期間（TTL）値を無制限に設定する必要があります。通常、TTL を設定すると、キャッシュに保存されたコンテンツが古くなるのを防ぐことができます。TTL を無制限に設定する場合は、バケットの内容をアウトバンドで変更しないように注意する必要があります（つまり、別のワークロードまたはアクタがワークロードを変更できるようにします）。帯域外変更はローカルでは表示されないため、整合性の問題が発生する可能性があります。

メタデータ プリフェッチを有効にするには、次の構成変更を行います。読み取り頻度の高いボリュームでは、この機能を有効にすることをおすすめします。

例については、並列ダウンロードを使用して大規模なファイルの読み取りパフォーマンスを改善するのコードサンプルをご覧ください。

リスト キャッシュ

アプリのディレクトリ リストを高速化するには、リスト キャッシュ保存を有効にします。この機能は、ディレクトリ リスティングをメモリに保存するため、繰り返しのリクエストをより高速に処理できます。リスト キャッシュはデフォルトで無効になっています。マウント オプションで kernel-list-cache-ttl-secs パラメータを設定すると有効にできます。リスティングのキャッシュ保存期間を定義します。

並列ダウンロードを使用して大規模なファイルの読み取りパフォーマンスを改善する

Cloud Storage FUSE の並列ダウンロードを使用すると、Cloud Storage から大規模なファイルを読み取る速度を向上させ、マルチスレッド ダウンロードを実現できます。Cloud Storage FUSE の並列ダウンロードは、サイズが 1 GB を超える読み取りを行うモデル サービング ユースケースで特に効果的です。

一般的な例:

  • モデル サービング。インスタンスの起動時にモデルのダウンロードを高速化するために、大きなプリフェッチ バッファが必要になります。
  • チェックポイントの復元。サイズの大きい複数のファイルへの 1 回限りのアクセスを改善するため、読み取り専用データ キャッシュが必要になります。
ベスト プラクティス:

単一スレッドで大規模ファイルの読み取りを実行するアプリケーションには、並列ダウンロードを使用します。読み取り並列処理が多いアプリケーション（8 つを超えるスレッドを使用）の場合、この機能によりパフォーマンスが低下する可能性があります。

Cloud Storage FUSE CSI ドライバで並列ダウンロードを使用する手順は次のとおりです。

  1. ファイル キャッシュを有効にして使用するの説明に従って、ファイル キャッシュを有効にしてクラスタを作成します。

  2. マニフェストで、マウント オプションを使用して次の追加設定を構成し、並列ダウンロードを有効にします。

    1. file-cache:enable-parallel-downloads:true を設定します。
    2. 必要に応じて、file-cache:parallel-downloads-per-file、file-cache:parallel-downloads-per-file、file-cache:max-parallel-downloads、file-cache:download-chunk-size-mb を調整します。

  3. （省略可）必要に応じて、次のボリューム属性の調整を検討してください。

アクセス制御チェックによる割り当ての使用量を削減する

デフォルトでは、CSI ドライバはアクセス制御チェックを実行して、Pod サービス アカウントが Cloud Storage バケットにアクセスできることを確認します。これにより、Kubernetes Service API、Security Token Service、IAM 呼び出しの形で追加のオーバーヘッドが発生します。GKE バージョン 1.29.9-gke.1251000 以降では、ボリューム属性 skipCSIBucketAccessCheck を使用して、このような冗長なチェックをスキップし、割り当ての使用量を削減できます。

推論サービングの例

次の例は、推論サービングで並列ダウンロードを有効にする方法を示しています。

  1. 次の仕様で PersistentVolume と PersistentVolumeClaim のマニフェストを作成します。

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: serving-bucket-pv
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 64Gi
  persistentVolumeReclaimPolicy: Retain
  storageClassName: example-storage-class
  claimRef:
    namespace: NAMESPACE
    name: serving-bucket-pvc
  mountOptions:
    - implicit-dirs #avoid if list cache enabled and doing metadata prefetch
    - metadata-cache:ttl-secs:-1
    - metadata-cache:stat-cache-max-size-mb:-1
    - metadata-cache:type-cache-max-size-mb:-1
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-system:kernel-list-cache-ttl-secs:-1
    - file-cache:enable-parallel-downloads:true
  csi:
    driver: gcsfuse.csi.storage.gke.io
    volumeHandle: BUCKET_NAME
    volumeAttributes:
      skipCSIBucketAccessCheck: "true"
      gcsfuseMetadataPrefetchOnMount: "true"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: serving-bucket-pvc
  namespace: NAMESPACE
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 64Gi
  volumeName: serving-bucket-pv
  storageClassName: example-storage-class

    次の値を置き換えます。

    • NAMESPACE: Pod をデプロイする Kubernetes Namespace。
    • BUCKET_NAME: Cloud Storage バケットへのアクセスを構成するときに指定した Cloud Storage バケット名。アンダースコア（_）を指定すると、Kubernetes ServiceAccount がアクセスできるすべてのバケットをマウントできます。詳細については、Cloud Storage FUSE ドキュメントの動的マウントをご覧ください。

  2. マニフェストをクラスタに適用します。

    kubectl apply -f PV_FILE_PATH

    PV_FILE_PATH は、YAML ファイルのパスに置き換えます。

  3. ローカル SSD ベースのファイル キャッシュまたは RAM ディスク ベースのファイル キャッシュを使用するかどうかに応じて、次の仕様を使用して Pod マニフェストを作成し、PersistentVolumeClaim を使用します。

    ローカル SSD

    apiVersion: v1
kind: Pod
metadata:
  name: gcs-fuse-csi-example-pod
  namespace: NAMESPACE
  annotations:
    gke-gcsfuse/volumes: "true"
    gke-gcsfuse/cpu-limit: "0"
    gke-gcsfuse/memory-limit: "0"
    gke-gcsfuse/ephemeral-storage-limit: "0"
spec:
  containers:
    # Your workload container spec
    ...
    volumeMounts:
    - name: serving-bucket-vol
      mountPath: /serving-data
      readOnly: true
  serviceAccountName: KSA_NAME
  volumes:
  - name: serving-bucket-vol
    persistentVolumeClaim:
      claimName: serving-bucket-pvc

    RAM ディスク

    apiVersion: v1
kind: Pod
metadata:
  name: gcs-fuse-csi-example-pod
  namespace: NAMESPACE
  annotations:
    gke-gcsfuse/volumes: "true"
    gke-gcsfuse/cpu-limit: "0"
    gke-gcsfuse/memory-limit: "0"
    gke-gcsfuse/ephemeral-storage-limit: "0"
spec:
  containers:
    # Your workload container spec
    ...
    volumeMounts:
    - name: serving-bucket-vol
      mountPath: /serving-data
      readOnly: true
  serviceAccountName: KSA_NAME 
  volumes:
    - name: gke-gcsfuse-cache # gcsfuse file cache backed by RAM Disk
      emptyDir:
        medium: Memory 
  - name: serving-bucket-vol
    persistentVolumeClaim:
      claimName: serving-bucket-pvc

  4. マニフェストをクラスタに適用します。

    kubectl apply -f POD_FILE_PATH

    POD_FILE_PATH は、YAML ファイルのパスに置き換えます。

ボリューム属性を構成する

ボリューム属性を使用すると、Cloud Storage FUSE CSI ドライバの特定の動作を構成できます。

Cloud Storage FUSE CSI ドライバでは、Cloud Storage FUSE 構成ファイルを直接指定できません。Cloud Storage FUSE CSI ボリューム属性を使用して、構成ファイル内の一部のフィールドを構成できます。CSI ドライバは、ボリューム属性値を構成ファイルのフィールドに変換します。

サポートされているボリューム属性の完全なリストについては、ボリューム属性のリファレンスをご覧ください。

ボリューム属性は、次の方法で指定できます。

  • 永続ボリュームを使用する場合、PersistentVolume マニフェストの spec.csi.volumeAttributes フィールド。
  • CSI エフェメラル ボリュームを使用する場合、spec.volumes[n].csi.volumeAttributes フィールド。

マニフェストでは、ボリューム属性を Key-Value ペアとして指定できます。次に例を示します。

volumeAttributes:
  mountOptions: "implicit-dirs"
  fileCacheCapacity: "-1"
  gcsfuseLoggingSeverity: warning

Cloud Storage FUSE 指標

GKE Monitoring API で、次の Cloud Storage FUSE 指標を使用できるようになりました。ラベル、タイプ、単位など、Cloud Storage FUSE 指標の詳細については、GKE システム指標をご覧ください。これらの指標は、Cloud Storage FUSE を使用する Pod ごとに使用でき、指標を使用してボリュームとバケットごとに分析情報を構成できます。

指標はデフォルトで無効になっています。有効にするには、ボリューム属性 disableMetrics を「false」に設定します。

ファイル システム指標

ファイル システム指標は、オペレーション数、エラー、処理速度など、ファイル システムのパフォーマンスと健全性をトラッキングします。これらの指標は、ボトルネックを特定してパフォーマンスを最適化するのに役立ちます。

  • gcsfusecsi/fs_ops_count
  • gcsfusecsi/fs_ops_error_count
  • gcsfusecsi/fs_ops_latency

Cloud Storage 指標

データ量、速度、リクエスト アクティビティなどの Cloud Storage 指標をモニタリングして、アプリケーションが Cloud Storage バケットとどのようにやり取りしているかを把握できます。このデータは、読み取りパターンの改善やリクエスト数の削減など、最適化の対象となる領域を特定するのに役立ちます。

  • gcsfusecsi/gcs_download_bytes_count
  • gcsfusecsi/gcs_read_count
  • gcsfusecsi/gcs_read_bytes_count
  • gcsfusecsi/gcs_reader_count
  • gcsfusecsi/gcs_request_count
  • gcsfusecsi/gcs_request_latencies

ファイル キャッシュ指標

データの読み取り量、速度、キャッシュ ヒット率などのファイル キャッシュ指標をモニタリングして、Cloud Storage FUSE とアプリケーションのパフォーマンスを最適化できます。これらの指標を分析して、キャッシュ戦略を改善し、キャッシュ ヒットを最大化します。

  • gcsfusecsi/file_cache_read_bytes_count
  • gcsfusecsi/file_cache_read_latencies
  • gcsfusecsi/file_cache_read_count

パフォーマンス チューニングのベスト プラクティス

このセクションでは、Cloud Storage FUSE CSI ドライバのパフォーマンス チューニングと最適化に推奨される手法について説明します。

  • 階層型名前空間（HNS）バケットを活用する: HNS バケットを選択すると、初期の秒間クエリ数（QPS）が大幅に 8 倍増加します。この選択により、迅速かつアトミックなディレクトリ名変更も容易になります。これは、Cloud Storage FUSE による効率的なチェックポイント作成の重要な要件です。HNS バケットは、1 秒あたり 40,000 件のオブジェクト読み取りリクエストと 8,000 件のオブジェクト書き込みリクエストをサポートすることで、ファイルのようなエクスペリエンスを実現します。これは、フラット バケットが提供する 1 秒あたり 8,000 件のオブジェクト読み取りリクエストと 1,000 件のオブジェクト書き込みリクエストと比較して大幅な改善です。

  • 可能な場合は特定のディレクトリをマウントする: ワークロードでバケット内の特定のディレクトリにアクセスする場合は、マウント時に --only-dir フラグを使用します。この集中的なアプローチでは、指定されたパス内のすべてのファイルまたはディレクトリに対する list+stat 呼び出しを含む LookUpInode 呼び出しのスコープが制限されるため、リスト呼び出しが高速化されます。マウントを必要なサブディレクトリに絞り込むことで、これらの呼び出しを最小限に抑え、パフォーマンスを向上させることができます。

  • メタデータ キャッシュを最適化する: メタデータ キャッシュを構成して容量を最大化し、有効期間（TTL）を無限に設定します。この方法では、ジョブの実行中にアクセスされたすべてのメタデータが効果的にキャッシュに保存され、Cloud Storage へのメタデータ アクセス リクエストが最小限に抑えられます。この構成は、Cloud Storage メタデータの繰り返し検索が不要になるため、読み取り専用ボリュームに特に有益です。ただし、これらの大規模なメタデータ キャッシュに関連するメモリ消費量がシステムの機能と一致していることを確認してください。

  • GKE サイドカー リソースを最大化: Cloud Storage FUSE は、GKE 環境のサイドカー コンテナ内で動作します。リソースのボトルネックを防ぐには、サイドカー コンテナの CPU とメモリの使用量の制限を解除します。これにより、Cloud Storage FUSE はワークロードの需要に基づいてリソース使用率をスケーリングし、スロットリングを防ぎ、最適なスループットを確保できます。

  • メタデータ キャッシュに事前にデータを入力する: CSI ドライバのメタデータ プリフェッチを有効にします。これにより、メタデータとリストキャッシュが効率的に入力され、Cloud Storage へのメタデータ呼び出しが最小限に抑えられ、最初の実行が高速化されます。多くの ML フレームワークはこれを自動的に実行しますが、カスタム トレーニング コードではこのステップを確実に行う必要があります。詳細については、メタデータ プリフェッチを使用してメタデータ キャッシュに事前入力するをご覧ください。

  • ファイル キャッシュと並列ダウンロードを使用する: 特に、データが繰り返し読み取られるマルチエポック トレーニング ワークロードの場合は、ファイル キャッシュ機能を有効にします。ファイル キャッシュは、頻繁にアクセスされるデータをローカル ストレージ（A3 マシンの場合は SSD）に保存し、読み取りパフォーマンスを向上させます。特にサービング ワークロードの場合は、並列ダウンロード機能を補完して、大きなファイルを小さなチャンクに分割し、同時にダウンロードすることで、大きなファイルのダウンロードを高速化します。

  • チェックポイントを最適化する: Cloud Storage FUSE でのチェックポイント処理には、HNS バケットを使用することを強くおすすめします。HNS 以外のバケットを使用する場合は、rename-dir-limit パラメータを高い値に設定して、チェックポイント作成中に ML フレームワークでよく使用されるディレクトリ名変更に対応します。ただし、HNS 以外のバケットでのディレクトリの変更は、アトミックではない可能性があり、完了までに時間がかかる場合があります。

  • リスト キャッシュを有効にする: --kernel-list-cache-ttl-secs フラグを使用してリスト キャッシュを有効にすると、パフォーマンスがさらに向上します。この機能は、ディレクトリとファイルのリストキャッシュをキャッシュに保存し、ls オペレーションの速度を向上させます。リスト キャッシュは、AI/ML トレーニング シナリオで一般的に発生する、ディレクトリ全体の一覧取得の繰り返しを含むワークロードに特に有益です。データの整合性を維持するには、読み取り専用マウントとともにリスト キャッシュを使用することをおすすめします。

次のステップ