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
フィールドは-1
の値に設定されています。これにより、キャッシュに保存されたデータは、cache-dir
の値として指定したディレクトリの空き容量がすべて占有されるまで増加します。ファイル キャッシュ データを格納するディレクトリは、
cache-dir
フィールドを使用して指定できます。ファイル キャッシュを有効にするには、キャッシュ ディレクトリを指定する必要があります。キャッシュに保存されたデータが無効になる時間を制御するには、
ttl-secs
フィールドを使用します。デフォルトでは、ttl-secs
フィールドは60
に設定され、60 秒が指定されます。この値を増やすことをおすすめします。キャッシュに保存されたデータの無効化の制御の詳細については、キャッシュ データの無効化の構成をご覧ください。キャッシュに保存されたデータのエビクションの詳細については、エビクションをご覧ください。
ランダム読み取りと部分読み取り
最初のファイル読み取りオペレーションがファイルの先頭、つまりオフセット 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 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 の静的マウントをご覧ください。
特定のフォルダまたはディレクトリのみをキャッシュに保存する: バケット全体をマウントするのではなく、
–only-dir
オプションを使用して、特定のバケットレベルのフォルダのみをマウントしてキャッシュに保存できます。詳細については、バケット内のディレクトリをマウントするをご覧ください。
統計情報のキャッシュ保存の概要
Cloud Storage FUSE 統計情報キャッシュは、オブジェクト メタデータのキャッシュです。サイズ、変更時間、権限などのファイル属性に固有のオペレーションのパフォーマンスを向上させます。統計キャッシュを使用すると、Cloud Storage に統計オブジェクト リクエストを送信する代わりに、キャッシュに保存されたデータを使用してオペレーションを実行するため、レイテンシが短縮されます。デフォルトでは、統計キャッシュは stat-cache-max-size-mb
の値が 32 MB で、ttl-secs
の値が 60
秒に設定されています。両方の値を大きくすることをおすすめします。統計キャッシュ保存の詳細については、GitHub の Semantics のドキュメントをご覧ください。
型のキャッシュ保存の概要
Cloud Storage FUSE 型キャッシュは、ファイルまたはディレクトリの存在に固有のメタデータ オペレーションのパフォーマンスを高速化するメタデータ キャッシュです。型キャッシュを使用すると、ファイルまたはディレクトリが存在するかどうかの情報をローカルに保存することで、この情報を確認するために Cloud Storage に送信されるリクエストの数を減らすことによって、レイテンシを短縮できます。デフォルトでは、型キャッシュは type-cache-max-size-mb
の値が 4 MB、ttl-secs
の値が 60
秒に設定されています。両方の値を大きくすることをおすすめします。型キャッシュ保存の詳細については、GitHub の Semantics のドキュメントをご覧ください。
リスト キャッシュ保存の概要
Cloud Storage FUSE リスト キャッシュは、ディレクトリとファイルリスト、または ls
のレスポンス用のキャッシュです。これにより、リスト オペレーションの速度が向上します。リスト キャッシュは、AI / ML トレーニングの実行など、実行の一部としてディレクトリ全体の一覧取得を繰り返すワークロードに特に便利です。
リスト キャッシュはページ キャッシュのメモリに保持され、メモリの可用性に基づいてカーネルによって制御されます。これは、マシンのメモリに保持され、Cloud Storage FUSE によって制御される統計情報キャッシュや型キャッシュとは対照的です。
リスト キャッシュ保存の有効化
リスト キャッシュはデフォルトで無効になっており、自動的に 0
の値に設定されます。リスト キャッシュを有効にするには、--kernel-list-cache-ttl-secs
CLI フラグまたは kernel-list-cache-ttl-secs
フィールドに次のいずれかの値を設定します。
正の値。ディレクトリ リスト レスポンスをカーネルのページ キャッシュに保持する TTL(秒単位)を表します。
-1
。エントリの有効期限をバイパスし、キャッシュから利用可能な場合に、キャッシュからリスト レスポンスを返します。
リスト キャッシュ保存を有効にして構成する方法については、Cloud Storage FUSE 構成ファイルをご覧ください。
キャッシュの無効化の構成
以降のセクションでは、すべてのキャッシュ タイプに対してキャッシュの無効化を構成する方法について説明します。キャッシュの無効化は有効期間(TTL)で制御されます。TTL が期限切れになると、キャッシュに保存されたデータは無効になります。
ファイル、統計情報、型のキャッシュ保存の無効化
ttl-secs
フィールドに、Cloud Storage から取得され、キャッシュに保存されたメタデータの使用期間を指定します。
ttl-secs
は、Cloud Storage FUSE 構成ファイルで構成できます。
ttl-secs
の値を 0
より大きく指定すると、ファイル キャッシュのメタデータは、指定した時間だけ有効になります。ttl-secs
のデフォルト値は 60
です。ファイル キャッシュ保存の場合、整合性確保の必要性とのバランスを取りながら、繰り返しの読み取りにかかると予測される間隔に基づいて ttl-secs
値を増やすことをおすすめします。データ変更の重要度と頻度に基づいて、ワークロードで許容される範囲で ttl-secs
値を設定することをおすすめします。メタデータ エントリが無効になると、後続の読み取りが Cloud Storage からクエリされます。
ttl-secs
フラグでは、秒数を表す値を指定できるほか、0
と -1
の値も指定できます。
ttl-secs
の値が0
: 値0
を入力すると、ttl-secs
フラグによって、キャッシュの整合性が保たれているか確認するために Cloud Storage のデータ提供元のファイルを検証するメタデータ取得呼び出しが Cloud Storage に対し発行され、最新のファイルが読み込まれているかが確認されます。キャッシュ内のファイルが最新である場合、ファイルがキャッシュから直接提供されます。最初にメタデータを確認するために Cloud Storage に対する呼び出しを行う必要があるため、0 以外のttl-secs
値を指定した場合よりもパフォーマンスが低下します。ファイルがキャッシュに存在し、変更されていない場合、メタデータ取得呼び出し後にキャッシュからファイルが整合性を保たれた状態で提供されます。ttl-secs
の値が-1
:-1
の値を入力すると、キャッシュが使用可能な場合にファイルが必ずキャッシュから読み取られます。その場合、整合性チェックは行われません。整合性チェックを行わずにファイルを提供すると、整合性のないデータが提供される場合があるため、この方法は、データが変化しないジョブで実行されるワークロードにのみ一時的に使用してください。たとえば、同じデータが複数のエポックで変更なしで読み取られる ML トレーニングでは、-1
の値を使用すると便利です。
リスト キャッシュの無効化
kernel-list-cache-ttl-secs
の値を 0
より大きく指定すると、ディレクトリ リストのレスポンスはカーネルのページ キャッシュに保持され、指定した期間、有効になります。デフォルトでは、リスト キャッシュは無効に設定され、値は 0
に設定されています。-1
の値を指定すると、Cloud Storage FUSE はリスト キャッシュの有効期限を無効にし、キャッシュから利用可能であれば、キャッシュからリスト レスポンスを返します。
キャッシュ保存されたデータの読み取りパス
Cloud Storage FUSE キャッシュは、キャッシュに取り込まれた後の反復読み取りを高速化します。初回読み取りとキャッシュミスは、どちらも Cloud Storage に直接送信され、通常の Cloud Storage ネットワークのレイテンシの影響を受けます。
考慮事項
ファイル、統計情報、型、リストのキャッシュ保存を有効にして Cloud Storage FUSE を使用すると、パフォーマンスは向上しますが、整合性が低下します。詳しくは、GitHub のセマンティクスのドキュメントをご覧ください。
ファイル キャッシュ エントリが TTL に基づいてまだ期限切れになっておらず、ファイルがキャッシュにある場合、Cloud Storage にリクエストが発行されることなく、ローカル クライアント キャッシュからオペレーション全体が処理されます。
ファイル キャッシュ エントリが TTL に基づいて期限切れになった場合、最初に Cloud Storage に対してメタデータ取得呼び出しが行われます。ファイルがキャッシュにない場合は、Cloud Storage からファイルが取得されます。どちらのオペレーションもネットワーク レイテンシの影響を受けます。メタデータ エントリが無効になっていても、ファイルがキャッシュに存在し、そのオブジェクト生成が変更されていない場合は、データが有効かどうかを確認するためにメタデータ取得呼び出しが実行されてからでなければ、ファイルがキャッシュから提供されません。
Cloud Storage FUSE クライアントがキャッシュに保存されたファイルまたはそのメタデータを変更すると、ファイルはすぐに無効になり、同じクライアントによるその後の読み取りで整合性が保証されます。ただし、複数のクライアントが同じファイルまたはそのメタデータにアクセスし、そのエントリがキャッシュに保存されている場合は、そのクライアントの TTL 設定によってファイルが無効になるまで、ファイルまたはメタデータのキャッシュ保存バージョンが読み取られ、更新されたバージョンは読み取られません。
次のステップ
ファイルのキャッシュ保存の使用と構成の方法を学習する。