Cloud Storage FUSE には、データ取得のパフォーマンスを向上させるため、次の 4 種類のキャッシュ保存機能がオプションとして用意されています。
ファイル キャッシュ保存の概要
Cloud Storage FUSE のファイル キャッシュは、より高速な任意のキャッシュ ストレージからファイルを繰り返し読み取る、クライアント ベースの読み取りキャッシュです。
ファイルのキャッシュ保存のメリット
パフォーマンスの向上: ファイルのキャッシュ保存は、キャッシュ メディアから直接読み取りを行うことで、レイテンシとスループットを改善します。小規模でランダムな I/O オペレーションは、キャッシュから処理することで大幅に高速化できます。
既存の容量を使用する: ファイルのキャッシュ保存では、追加のストレージに対して課金されることなく、キャッシュ ディレクトリにすでにプロビジョニングされているマシン容量を使用できます。これには、
a2-ultragpu、a3-highgpu、Persistent Disk（各 VM で使用されるブートディスク）、メモリ内/tmpfsなどの Cloud GPU マシンタイプにバンドルされているローカル SSD が含まれます。料金の削減: キャッシュ ヒットがローカルで処理されるため、Cloud Storage オペレーションやネットワークの料金が発生しません。
AI と ML のトレーニングの総所有コストの改善: ファイルのキャッシュ保存によりデータの読み込みが速くなるため、Cloud GPU と Cloud TPU の使用率が向上します。トレーニング時間が短縮され、AI と ML のトレーニング ワークロードの費用対効果が高まります。
ファイル キャッシュを有効にして構成する
ファイル キャッシュはデフォルトで無効になっています。Cloud Storage FUSE 構成ファイルを使用して有効にして構成できます。キャッシュの動作は、次のフィールドを使用して制御できます。
max-size-mb: キャッシュ ディレクトリでキャッシュに保存されたデータが占有できる最大容量を制御します。デフォルトでは、max-size-mbフィールドは、キャッシュ ディレクトリの空き容量がすべて占有されるまで、キャッシュに保存されたデータが増加するように設定されています。cache-dir: ファイル キャッシュ データを格納するディレクトリを指定します。ファイル キャッシュを有効にするには、キャッシュ ディレクトリを指定する必要があります。ttl-secs: キャッシュされたデータが古くなり、Cloud Storage から更新する必要があるタイミングを決定します。デフォルトでは、ttl-secsフィールドは、60 秒間操作がないと期限切れになり、Cloud Storage から更新されるように設定されています。この値を増やすことをおすすめします。キャッシュ データの無効化を制御する方法については、キャッシュ データの無効化の構成をご覧ください。キャッシュに保存されたデータのエビクションの詳細については、エビクションをご覧ください。
enable-parallel-downloads: 複数のワーカーを使用して、ファイル キャッシュ ディレクトリをプリフェッチ バッファとして使用し、ファイルを並列でダウンロードすることで、1 GB を超える大規模なファイル（初回読み取りを含む）の読み取りパフォーマンスを高速化します。サービングとチェックポイントの復元オペレーションでは、並列ダウンロードを有効にすることをおすすめします。並列ダウンロードを有効にして構成する方法については、並列ダウンロードを構成するをご覧ください。
ランダム読み取りと部分読み取り
最初のファイル読み取りオペレーションがファイルの先頭、つまりオフセット 0 から開始される場合、Cloud Storage FUSE ファイル キャッシュは、小さな範囲のサブセットからしか読み取らない場合でも、ファイル全体をキャッシュに取り込んで読み込みます。これにより、同じオブジェクトからのその後のランダムまたは部分的な読み取りは、キャッシュから直接処理されます。
ファイルの最初の読み取りオペレーションがオフセット 0 以外の場所から開始された場合、Cloud Storage FUSE は、デフォルトで非同期の完全ファイル取得をトリガーしません。この動作を変更して、Cloud Storage FUSE が最初のランダム読み取り時にキャッシュにファイルを取り込むようにするには、cache-file-for-range-read フラグを true に設定します。同じオブジェクトに対して多くの異なるランダム読み取りまたは部分読み取りのオペレーションが実行される場合は、cache-file-for-range-read フラグを有効にすることをおすすめします。
エビクション
キャッシュに保存されているメタデータとデータのエビクションは、max-size-mb 制限ごとに構成された空きスペースのしきい値に達すると開始される LRU（最も長い間使われていないものを特定する）アルゴリズムに基づいて行われます。エントリが TTL に基づいて期限切れになると、最初に Cloud Storage に対してメタデータ取得呼び出しが行われますが、これはネットワークのレイテンシの影響を受けます。データとメタデータが個別に管理されるため、一方のエンティティがエビクションまたは無効化され、他方のエンティティではこれらが行われない場合があります。
パフォーマンス
Cloud Storage FUSE キャッシュは、選択したストレージ（ローカル SSD、Persistent Disk、インメモリ tmpfs、Filestore など）でバックアップされたユーザー指定ディレクトリを使用します。Cloud Storage FUSE キャッシュのパフォーマンスは、キャッシュにより使用される、基盤となるストレージと一致し、オーバーヘッドが最小限に抑えられます。
パフォーマンスを最大限に高め、キャッシュ スラッシングを回避するため、データセット全体がキャッシュ容量に収まるようにしてください。また、キャッシュ メディアが提供できる最大容量とパフォーマンスも考慮してください。プロビジョニングされたキャッシュのパフォーマンス、容量の上限、またはその両方に達した場合は、Cloud Storage FUSE よりも上限がはるかに高い Cloud Storage から直接読み取ることをおすすめします。
永続性
Cloud Storage FUSE キャッシュは、マウント解除時に保持されず、再起動します。ファイル キャッシュの場合、キャッシュからファイルを提供するために必要なメタデータ エントリはマウント解除と再起動時に削除されますが、ファイル キャッシュ内のデータはファイル ディレクトリに残っている可能性があります。マウントを解除するか再起動した後に、ファイル キャッシュ ディレクトリ内のデータを削除する必要があります。
セキュリティ
キャッシュ保存を有効にすると、Cloud Storage FUSE は、cache-dir フィールドを使用して指定したキャッシュ ディレクトリをキャッシュの基盤となるディレクトリとして使用し、Cloud Storage バケットのファイルを暗号化されていない形式で保持します。このキャッシュ ディレクトリにアクセスできるユーザーまたはプロセスは、これらのファイルにアクセスできます。このディレクトリへのアクセスを制限することをおすすめします。
ファイル キャッシュへの直接アクセスまたは複数アクセス
Cloud Storage FUSE 以外のプロセスを使用してキャッシュ ディレクトリ内のファイルにアクセスしたり、ファイルを変更したりすると、データが破損するおそれがあります。Cloud Storage FUSE キャッシュは、実行中の各 Cloud Storage FUSE プロセスに固有であり、同じマシンまたは別のマシンで実行されている別の Cloud Storage FUSE プロセスを認識しません。そのため、異なる Cloud Storage FUSE プロセスで同じキャッシュ ディレクトリを使用することはおすすめしません。
複数の Cloud Storage FUSE プロセスを同じマシンで実行する必要がある場合は、各 Cloud Storage FUSE プロセスが独自のキャッシュ ディレクトリを取得するか、次のいずれかの方法でデータが破損しないようにする必要があります。
共有キャッシュを使用してすべてのバケットをマウントする: 動的マウントを使用して、アクセス可能なすべてのバケットを共有キャッシュにより 1 つのプロセスでマウントします。詳細については、Cloud Storage FUSE の動的マウントをご覧ください。
特定のバケットでキャッシュを有効にする: 静的マウントを使用して、指定したバケットでのみキャッシュ保存を有効にします。詳細については、Cloud Storage FUSE の静的マウントをご覧ください。
特定のフォルダまたはディレクトリのみをキャッシュに保存する: バケット全体をマウントするのではなく、特定のバケットレベルのフォルダのみをマウントしてキャッシュに保存します。詳細については、バケット内のディレクトリをマウントするをご覧ください。
統計情報のキャッシュ保存の概要
Cloud Storage FUSE 統計情報キャッシュは、オブジェクト メタデータのキャッシュです。サイズ、変更時間、権限などのファイル属性に固有のオペレーションのパフォーマンスを向上させます。統計キャッシュを使用すると、レイテンシが短縮されます。Cloud Storage に統計オブジェクト リクエストを送信する代わりに、キャッシュに保存されたデータを使用してオペレーションを実行するからです。統計キャッシュ保存の詳細については、GitHub の Semantics のドキュメントをご覧ください。
統計キャッシュはデフォルトで有効になっており、Cloud Storage FUSE 構成ファイルを使用して構成できます。キャッシュの最大サイズは stat-cache-max-size-mb フィールドで制御されます。デフォルト値は 32（32 MB）です。キャッシュの TTL は ttl-secs フィールドで制御されます。デフォルト値は 60（60 秒）です。
ベスト プラクティス
ワークロードに含まれるファイル数が 20,000 までの場合は、統計キャッシュ保存の stat-cache-max-size-mb フィールドにデフォルト値の 32 を使用することをおすすめします。ワークロードのファイル数が 20,000 を超える場合は、6,000 ファイル増えるごとに stat-cache-max-size-mb 値を 10 ずつ増やします（ファイルあたり約 1,500 バイト）。
stat-cache-max-size-mb はマウントレベルの上限であり、実際のメモリ使用量は指定値を下回る場合があります。また、stat-cache-max-size-mb を -1 に設定して、統計情報キャッシュが必要なだけメモリを使用できるようにすることもできます。
型のキャッシュ保存の概要
Cloud Storage FUSE 型キャッシュは、ファイルまたはディレクトリの存在に固有のメタデータ オペレーションのパフォーマンスを高速化するメタデータ キャッシュです。型キャッシュを使用すると、レイテンシを短縮できます。ファイルまたはディレクトリが存在するかどうかの情報をローカルに保存することで、この情報を確認するために Cloud Storage に送信されるリクエストの数が減るためです。型キャッシュ保存の詳細については、GitHub の Semantics のドキュメントをご覧ください。
型キャッシュはデフォルトで有効になっており、Cloud Storage FUSE 構成ファイルを使用して構成できます。キャッシュの最大サイズは type-cache-max-size-mb フィールドで制御されます。デフォルト値は 4（4 MB）です。キャッシュの TTL は ttl-secs フィールドで制御されます。デフォルト値は 60（60 秒）です。
ベスト プラクティス
マウントするバケットの 1 つのディレクトリ内にあるファイルの最大数が 20,000 以下の場合は、型キャッシュ保存の type-cache-max-size-mb フィールドにデフォルト値の 4 を使用することをおすすめします。マウントする 1 つのディレクトリ内のファイルの最大数が 20,000 を超える場合は、5,000 ファイルごとに type-cache-max-size-mb 値を 1 ずつ増やします（ファイルあたり約 200 バイト）。
type-cache-max-size-mb はマウントレベルの上限であり、実際のメモリ使用量は指定値を下回る場合があります。また、type-cache-max-size-mb 値を -1 に設定して、タイプ キャッシュが必要なだけメモリを使用できるようにすることもできます。
リスト キャッシュ保存の概要
Cloud Storage FUSE リスト キャッシュは、ディレクトリとファイルリスト、または ls のレスポンス用です。これにより、リスト オペレーションの速度が向上します。リスト キャッシュは、AI / ML トレーニングの実行など、実行の一部としてディレクトリ全体の一覧取得を繰り返すワークロードに特に便利です。
リスト キャッシュはページ キャッシュのメモリに保持され、メモリの可用性に基づいてカーネルによって制御されます。これは、マシンのメモリに保持され、Cloud Storage FUSE によって制御される統計情報キャッシュや型キャッシュとは対照的です。
リスト キャッシュ保存を有効にする
リスト キャッシュはデフォルトで無効になっています。リスト キャッシュを有効にするには、kernel-list-cache-ttl-secs フィールドに次のいずれかの値を設定します。
正の値。ディレクトリ リスト レスポンスをカーネルのページ キャッシュに保持する有効期間（TTL）を秒単位で表します。
-1。エントリの有効期限をバイパスし、キャッシュから利用可能な場合に、キャッシュからリスト レスポンスを返します。
リスト キャッシュを有効にして構成するには、Cloud Storage FUSE 構成ファイルをご覧ください。
キャッシュの無効化を構成する
以降のセクションでは、すべてのキャッシュ タイプに対してキャッシュの無効化を構成する方法について説明します。
ファイル、統計情報、型のキャッシュ保存の無効化
ファイル キャッシュ、統計情報キャッシュ、型のキャッシュの場合、ttl-secs フィールドには、キャッシュに保存されるメタデータの TTL（Cloud Storage から取得されてから期限切れになるまでの期間）を秒単位で指定します。
ttl-secs は、Cloud Storage FUSE 構成ファイルで構成できます。
ttl-secs フィールドはデフォルトで 60 に設定されています。ttl-secs の値を 0 より大きく指定すると、ファイル キャッシュのメタデータは、指定した時間だけ有効になります。ファイル キャッシュの場合、整合性確保の必要性とのバランスを取りながら、繰り返しの読み取りにかかると予測される間隔に基づいて ttl-secs 値を増やすことをおすすめします。データ変更の重要度と頻度に基づいて、ワークロードで許容される範囲で ttl-secs 値を設定することをおすすめします。メタデータ エントリが無効になると、後続の読み取りが Cloud Storage からクエリされます。
キャッシュに保存されたメタデータが期限切れになり、更新が必要になるまでの時間（TTL）を秒単位で指定できるほか、次の値を使用してファイルの読み取り方法を指定することもできます。
ttl-secsの値が0: Cloud Storage に対してGETメタデータ呼び出しを発行し、キャッシュの整合性が保たれているか確認するために、Cloud Storage のデータ提供元のファイルを検証することで、最新のデータを含むファイルが読み込まれるようにします。キャッシュ内のファイルが最新である場合、ファイルがキャッシュから直接提供されます。0以外の値を指定すると、最初にメタデータを確認するために Cloud Storage に対する呼び出しを行う必要があるため、パフォーマンスが低下する可能性があります。ファイルがキャッシュに存在し、変更されていない場合、GETメタデータ呼び出し後にキャッシュからファイルが整合性を保たれた状態で提供されます。ttl-secsの値が-1: キャッシュが使用可能な場合にファイルが必ずキャッシュから読み取られます。その場合、整合性チェックは行われません。整合性チェックを行わずにファイルを提供すると、整合性のないデータが提供される場合があるため、この方法は、データが変化しないジョブで実行されるワークロードにのみ一時的に使用してください。たとえば、同じデータが複数のエポックで変更なしで読み取られる ML トレーニングでは、-1の値を使用すると便利です。
リスト キャッシュの無効化
リスト キャッシュの無効化は、kernel-list-cache-ttl-secs フィールドを使用して 0 より大きい値を指定することで設定されます。ディレクトリ リストのレスポンスはカーネルのページ キャッシュに保持され、指定した期間、有効になります。デフォルトでは、リスト キャッシュは無効に設定され、値は 0 に設定されています。-1 の値を指定すると、Cloud Storage FUSE はリスト キャッシュの有効期限を無効にし、キャッシュから利用可能であれば、キャッシュからリスト レスポンスを返します。
キャッシュ保存されたデータの読み取りパス
Cloud Storage FUSE キャッシュは、キャッシュに取り込まれた後の反復読み取りを高速化します。初回読み取りとキャッシュミスは、どちらも Cloud Storage に直接送信され、通常の Cloud Storage ネットワークのレイテンシの影響を受けます。
ワークロードを実行する前に、マウントされたバケット内のファイルを再帰的にリストして、統計キャッシュと型キャッシュに事前にデータを入力し、高速なバッチ処理で初回実行時のパフォーマンスを改善することをおすすめします。
ls -R MOUNT_POINT > /dev/null
考慮事項
ファイル キャッシュ、統計情報キャッシュ、型キャッシュ、リスト キャッシュを有効にすると、パフォーマンスは向上しますが、整合性が低下します。これは通常、変更率の高い複数のクライアントを使用して同じバケットにアクセスする場合に発生します。整合性への影響を軽減するため、バケットを読み取り専用としてマウントすることをおすすめします。キャッシュ保存の動作の詳細については、GitHub の Cloud Storage FUSE セマンティクスのドキュメントをご覧ください。
ファイル キャッシュ エントリが TTL に基づいてまだ期限切れになっておらず、ファイルがキャッシュにある場合、Cloud Storage にリクエストが発行されることなく、ローカル クライアント キャッシュからオペレーション全体が処理されます。
ファイル キャッシュ エントリが TTL に基づいて期限切れになった場合、最初に Cloud Storage に対してメタデータ取得呼び出しが行われます。ファイルがキャッシュにない場合は、Cloud Storage からファイルが取得されます。どちらのオペレーションもネットワーク レイテンシの影響を受けます。メタデータ エントリが無効になっていても、ファイルがキャッシュに存在し、そのオブジェクト生成が変更されていない場合は、データが有効かどうかを確認するためにメタデータ取得呼び出しが実行されてからでなければ、ファイルがキャッシュから提供されません。
Cloud Storage FUSE クライアントがキャッシュに保存されたファイルまたはそのメタデータを変更すると、ファイルはすぐに無効になり、同じクライアントによるその後の読み取りで整合性が保証されます。ただし、複数のクライアントが同じファイルまたはそのメタデータにアクセスし、そのエントリがキャッシュに保存されている場合は、そのクライアントの TTL 設定によってファイルが無効になるまで、ファイルまたはメタデータのキャッシュ保存バージョンが読み取られ、更新されたバージョンは読み取られません。
次のステップ
ファイルのキャッシュ保存の使用と構成の方法を学習する。