ファイルゲートウェイで RefreshCache 操作に時間がかかるのはなぜですか?

解決方法

RefreshCache 操作は、ゲートウェイがオブジェクトを最後に識別してキャッシュした時点以降の Amazon Simple Storage Service (Amazon S3) オブジェクトの変更 (更新、アップロード、削除) を識別します。この操作を実行するために、ファイルゲートウェイは S3 バケットで再帰的な LIST 操作を実行し、LIST 操作から戻ってくるすべてのオブジェクトに対して HEAD オブジェクト操作を実行します。HEAD 操作は、メタデータを取得し、ファイルゲートウェイキャッシュに格納します。

次の要因は、RefreshCache 操作が完了するまでにかかる時間に影響する可能性があります。

• S3 バケット内に多数のオブジェクトがある場合、RefreshCache の実行時間が長くなります。これは、ファイルゲートウェイがバケット内のすべてのオブジェクトに対して HEAD オブジェクトを実行するためです。
• RefreshCache 操作は、ファイルゲートウェイ内の個々のファイル共有に固有です。1 つのファイル共有は、いつでも 2 つの RefreshCache API 操作をサポートします。キャッシュの更新を開始するためにさらに多くのリクエストを送信すると、進行中の操作が完了する前であっても、さらに多くの操作がトリガーされます。これにより、InvalidGatewayRequestException エラーが発生する場合があります。
• S3 バケットは、プレフィックスごとに 1 秒あたり 3,500 の PUT/COPY/POST/DELETE リクエスト、または 5,500 の GET/HEAD リクエストに対応できます。これらのサポートされているリクエストレートは、ファイルゲートウェイが S3 バケットに対して行ったリクエストにも適用されます。これは、RefreshCache 操作の完了速度に影響します。S3 バケットがファイルゲートウェイ以外のサービスでも使用されている場合、RefreshCache の実行時間が長くなる可能性があります。

RefreshCache 操作の実行時間を短縮するには、次の方法を検討してください。

• バケット内のオブジェクトの数を減らすことができます。
• バケット全体に対して 1 つのファイル共有を使用する代わりに、S3 バケット内の個別のプレフィックスに対応する複数のファイル共有をデプロイできます。
  注: ファイルゲートウェイごとに最大 10 個のファイル共有を作成できます。RefreshCache 操作はファイル共有ごとに実行されるため、このアプローチは個々の RefreshCache 操作を完了するのにかかる時間を短縮できます。
• S3 バケット全体に対して使用しているファイル共有が 1 つの場合は、新しいオブジェクトで更新されるバケットの特定のプレフィックスまたはフォルダに RefreshCache 操作を集中させることを検討してください。これにより、操作の範囲が小さくなり、実行時間が短縮されます。AWS コマンドラインインターフェイス (AWS CLI) または Storage Gateway API を使用して操作を実行するときに、RefreshCache 操作を特定のフォルダに設定できます。このオプションは、現在、Storage Gateway コンソールでは使用できません。
  注: AWS CLI コマンドの実行時にエラーが発生した場合は、AWS CLI の最新バージョンを使用していることを確認してください。
• オフピーク時に、S3 バケットへの他のリクエストに対して RefreshCache 操作を実行できます。AWS Lambda と Amazon CloudWatch を使用して、タイマーで操作をトリガーできます。

関連情報

AWS Storage Gateway でのファイルゲートウェイのキャッシュ更新プロセスの自動化