このページでは、Cloud Storage FUSE のパフォーマンス（レイテンシ、帯域幅、再試行）と、Cloud Storage FUSE を使用する際のベスト プラクティスについて説明します。
読み取りと書き込み
Cloud Storage FUSE は、ランダムな読み書きワークロードよりも、順次読み書きワークロードに対して優れたパフォーマンスを発揮します。Cloud Storage FUSE は、ヒューリスティックを使用して、ファイルがいつ読み取られるかを検知します。これにより、Cloud Storage FUSE は同じ TCP 接続を使用して Cloud Storage に対してサイズの大きい読み取りリクエストを発行し、読み取りリクエストの発行回数を少なくします。
順次読み取りのパフォーマンスを最適化するには、5 MB から 200 MB の容量のファイルをアップロードして読み取ることをおすすめします。ランダム読み取りのパフォーマンスを最適化するには、約 2 MB のサイズのファイルをアップロードして読み取ることをおすすめします。
キャッシュ
ファイル、統計情報、タイプ、または 3 つのキャッシュ タイプをすべて有効にして Cloud Storage FUSE を使用すると、パフォーマンスが向上し、コストが削減されますが、整合性が低下する可能性があります。
統計情報とタイプのキャッシュ
統計情報キャッシュとタイプ キャッシュを使用すると、同じファイルを繰り返し読み取るときに、Cloud Storage に対するシリアル呼び出しの回数を減らし、パフォーマンスを向上させることができます。統計情報キャッシュとタイプ キャッシュは、読み取りが繰り返し行われ、キャッシュ保存のメリットがある可能性のあるファイルの数に応じて設定します。キャッシュのおおよそのサイズはファイル数で表すことができます。各キャッシュ タイプでは、次の上限をおすすめします。
stat-cache-max-size-mb: ワークロードに 20,000 ファイルが含まれる場合は、デフォルト値の32を使用します。ワークロードのファイルが 20,000 ファイルを超える場合は、6,000 ファイルを追加するごとにstat-cache-max-size-mb値を 10 ずつ増やします（ファイルあたり約 1,500 バイト）。stat-cache-max-size-mbはマウントレベルの上限であり、実際のメモリ使用量は指定値を下回る場合があります。また、stat-cache-max-size-mbを-1に設定して、統計情報キャッシュが必要なだけメモリを使用できるようにすることもできます。type-cache-max-size-mb: マウントするバケットの 1 つのディレクトリ内にあるファイルの最大数が 20,000 以下の場合は、デフォルト値の4を使用します。マウントする 1 つのディレクトリ内のファイルの最大数が 20,000 を超える場合は、5,000 ファイルごとにtype-cache-max-size-mbを1増やします（ファイルあたり約 200 バイト）。type-cache-max-size-mbはマウントレベルの上限であり、実際のメモリ使用量は指定値を下回る場合があります。また、type-cache-max-size-mb値を-1に設定して、タイプ キャッシュが必要なだけメモリを使用できるようにすることもできます。
ワークロードを実行する前に、マウントされたバケットに ls -R を渡して完全なリストを作成し、高速なバッチ処理でタイプ キャッシュに事前に入力して、最初の実行時のパフォーマンスを改善することをおすすめします。
ファイル キャッシュのベスト プラクティス
パフォーマンスを最大限に高め、キャッシュ スラッシングを回避するため、データセット全体がキャッシュ容量に収まるようにしてください。また、キャッシュ メディアが提供できる最大容量とパフォーマンスも考慮してください。プロビジョニングされたキャッシュのパフォーマンス、容量の上限、またはその両方に達した場合は、Cloud Storage FUSE よりも上限がはるかに高い Cloud Storage から直接読み取ることをおすすめします。
IOPS（秒間クエリ数）
1 秒あたりの入出力オペレーション（IOPS）（Cloud Storage では「秒間クエリ数」とも呼ばれる）が高いワークロードの場合、Filestore は Cloud Storage FUSE よりも優れたオプションとなります。また、Filestore は、単一のファイル システムで非常に高い IOPS を実現し、レイテンシを低く抑えるのに適したオプションです。
また、高い IOPS と低レイテンシを提供する場合は、Cloud Storage FUSE のファイル キャッシュ機能を使用して、基盤となるキャッシュ メディアのパフォーマンス特性を基に構築することもできます。
レイテンシとスループット
Cloud Storage FUSE のレイテンシは、ローカル ファイル システムよりも長くなっています。小さなファイルを 1 つずつ読み書きすると、複数の API 呼び出しが発生するため、スループットが低下します。複数の大きなファイルを一度に読み書きすると、スループットが向上する場合があります。Cloud Storage FUSE のファイル キャッシュ機能を使用すると、小規模なランダム I/O のパフォーマンスを改善できます。
Cloud Storage FUSE のファイル システム レイテンシは rsync に影響します。これにより、ファイルの読み取りと書き込みは一度に 1 つしか行われません。バケット間で複数のファイルを並行して転送するには、gcloud storage rsync を実行して Google Cloud CLI を使用します。詳細については、rsync のドキュメントをご覧ください。
最大スループットを達成する
スループットを最大限に引き出すには、十分な CPU リソースを備えたマシンを使用してスループットを向上させ、ネットワーク インターフェース カード（NIC）を飽和状態にします。CPU リソースが不足していると、Cloud Storage FUSE スロットリングが発生する可能性があります。
Google Kubernetes Engine を使用していて、ワークロードでスループットの向上が必要な場合は、Cloud Storage FUSE サイドカー コンテナへの CPU 割り当てを増やします。サイドカー コンテナで使用されるリソースを増やすか、無制限のリソースを割り当てることができます。
利用可能な CPU コア数に応じてスレッド数を設定します。コアまたはスレッドの数が 100 より大きい場合は、–max-cons-per-host を同じ値に変更します。ML フレームワークでは通常、num_workers を使用してスレッド数を定義します。
レート制限
Cloud Storage FUSE が Cloud Storage に送信するトラフィックのレートを制限するには、gcsfuse コマンドの一部として次のオプションを使用できます。
--limit-ops-per-secオプションは、Cloud Storage FUSE が Cloud Storage にリクエストを送信するレートを制御します。--limit-bytes-per-secオプションは、Cloud Storage FUSE が Cloud Storage からデータをダウンロードする帯域幅を制御します。
これらのオプションの詳細については、gcsfuse コマンドラインのドキュメントをご覧ください。
すべてのレート制限は概算で、8 時間の時間枠にわたって実行されます。デフォルトでは、レート制限は適用されません。
アップロード手順の制御
デフォルトでは、Cloud Storage FUSE から Cloud Storage へのリクエストが失敗した場合、このリクエストは指定された最大バックオフ期間まで指数バックオフで再試行されます。この期間のデフォルト値は 30s（30 秒）です。バックオフ時間が指定の最大時間を超えると、指定された最大時間で再試行が続行されます。--max-retry-sleep オプションを gcsfuse 呼び出しの一部として使用して、バックオフ期間を指定できます。
--max-retry-sleep オプションの詳細については、gcsfuse コマンドラインのドキュメントをご覧ください。
ディレクトリのセマンティクス
Cloud Storage はフラットな名前空間で動作します。つまり、ディレクトリが実際には Cloud Storage 内には存在しません。ディレクトリは、スラッシュ（/）で終わるオブジェクト名で表現されます（たとえば、オブジェクト名 my-bucket/directory/file.txt で、my-bucket/directory/ はディレクトリを表します）。オブジェクト名の一部として存在し、実際のオブジェクトとして存在しないディレクトリは、暗黙的に定義されたディレクトリと呼ばれます。
デフォルトでは、暗黙的に定義されたディレクトリを含むバケットをマウントすると、Cloud Storage FUSE はそれらのディレクトリを推測できず、アクセスもできません。Cloud Storage FUSE は、明示的に定義されたディレクトリのみを推測できます。これは、ディレクトリは Cloud Storage バケット内の実際のオブジェクトとして存在することを意味します。
たとえば、オブジェクト my-bucket/directory/file1.txt を含む my-bucket という名前のバケットをマウントするとします。バケット マウント ポイントで ls を実行すると、directory が Cloud Storage 内のオブジェクトとして存在しないため、Cloud Storage FUSE は my-bucket/directory/ ディレクトリまたはその中の file1.txt オブジェクトにアクセスできません。Cloud Storage FUSE がディレクトリとその中のオブジェクトを推測できるようにするには、mkdir コマンドを使用してローカル ファイル システムでディレクトリを作成するか、gcsfuse コマンドに --implicit-dirs オプションを含めてディレクトリを明示的に定義します。
既存の接頭辞を使用してバケットをマウントする方法など、ディレクトリ セマンティクスの詳細については、GitHub ドキュメントのファイルとディレクトリをご覧ください。--implicit-dirs オプションの詳細については、Cloud Storage FUSE コマンドラインのドキュメントをご覧ください。
オブジェクトを一覧表示する際の考慮事項
マウントされたバケット内のすべてのオブジェクト（ls の実行など）を一覧表示すると、Cloud Storage FUSE は Cloud Storage の Objects: list API を呼び出します。この API は結果をページ分けします。つまり、バケット内のオブジェクトの数によっては、Cloud Storage FUSE で複数の呼び出しを発行しなければならない場合があります。これにより、一覧表示オペレーションの費用が高くなり、処理に時間がかかる場合があります。
ベンチマーク
Cloud Storage FUSE の負荷テストを実行する手順については、GitHub ドキュメントのパフォーマンス ベンチマークをご覧ください。
ロギング
ログ ローテーションなど、Cloud Storage FUSE アクティビティのロギングを構成するには、Cloud Storage FUSE 構成ファイルの logging キーの下でフィールドを指定します。デフォルトでは、ログファイルはローテーションされ、約 1 GiB の容量を消費します。