Storage Gateway コンソールを使用して自動キャッシュ更新スケジュールを設定する Amazon CloudWatch ルール AWS Lambda でを使用して自動キャッシュ更新スケジュールを設定する Storage Gateway コンソールを使用して手動キャッシュ更新を実行する Storage Gateway API を使用して手動キャッシュ更新を実行する

Amazon S3 バケットオブジェクトキャッシュの更新

NFS または SMB クライアントがファイルシステムオペレーションを実行すると、ゲートウェイはファイル共有に関連付けられた Amazon S3 オブジェクトキャッシュ内のオブジェクトのインベントリを維持します。ゲートウェイはこのキャッシュされたインベントリを使用して、Amazon S3 リクエストのレイテンシーと頻度を減らします。このオペレーションでは、S3 File Gateway キャッシュストレージにファイルはインポートされません。キャッシュされたインベントリは、Amazon S3 オブジェクトキャッシュ内のオブジェクトのインベントリの変更を反映するようにのみ更新されます。

ファイル共有の S3 バケットオブジェクトキャッシュを更新するには、次のリストからユースケースに最適な方法を選択し、対応する以下の手順を実行します。

注記

使用する方法に関係なく、ディレクトリを初めて一覧表示すると、ゲートウェイは Amazon S3 からディレクトリのメタデータコンテンツを一覧表示します。ディレクトリの初期化に必要な時間は、そのディレクトリのエントリ数に比例します。

トピック

Storage Gateway コンソールを使用して自動キャッシュ更新スケジュールを設定する
Amazon CloudWatch ルール AWS Lambda でを使用して自動キャッシュ更新スケジュールを設定する
Storage Gateway コンソールを使用して手動キャッシュ更新を実行する
Storage Gateway API を使用して手動キャッシュ更新を実行する

Storage Gateway コンソールを使用して自動キャッシュ更新スケジュールを設定する

次の手順では、指定した有効期限 (TTL) 値に基づいて自動キャッシュ更新スケジュールを設定します。TTL ベースのキャッシュ更新スケジュールを設定する前に、次の点を考慮してください。

TTL は、特定のディレクトリの最後のキャッシュ更新からの時間の長さとして測定されます。
TTL ベースのキャッシュ更新は、指定された TTL 期間が終了した後に特定のディレクトリにアクセスした場合にのみ発生します。
更新は再帰的ではありません。アクセスされる特定のディレクトリでのみ発生します。
更新では、TTL の有効期限が切れてから同期されていないディレクトリに対してのみ Amazon S3 API コストが発生します。
- ディレクトリは、NFS または SMB アクティビティによってアクセスされる場合にのみ同期されます。
- 同期は、指定した TTL 期間よりも頻繁に発生することはありません。
TTL ベースのキャッシュ更新の設定は、ゲートウェイと Amazon S3 バケット間のワークフローの外部で、Amazon S3 バケットのコンテンツを頻繁に直接更新する場合にのみ推奨されます。
有効期限が切れた TTLs を持つディレクトリにアクセスする NFS および SMB オペレーションは、ゲートウェイがディレクトリの内容を更新する間ブロックされます。

注記
キャッシュの更新によりディレクトリアクセスオペレーションがブロックされる可能性があるため、デプロイに実用的な最長の TTL 期間を設定することをお勧めします。

Storage Gateway コンソールを使用して自動キャッシュ更新スケジュールを設定するには

Storage Gateway コンソール (https://console.aws.amazon.com/storagegateway/home) を開きます。
ファイル共有を選択します。
更新スケジュールを設定するファイル共有を選択します。
アクション で、ファイル共有設定の編集 を選択します。
S3 からのキャッシュの自動更新については、チェックボックスをオンにし、有効期限 (TTL) を使用してファイル共有のキャッシュを更新する時間を日、時間、分単位で設定します。TTL は、ディレクトリにアクセスすると、ファイルゲートウェイが最初に Amazon S3 バケットからそのディレクトリのコンテンツを更新するまでの長さです。
[Save changes] (変更の保存) をクリックします。

Amazon CloudWatch ルール AWS Lambda でを使用して自動キャッシュ更新スケジュールを設定する

Amazon CloudWatch ルール AWS Lambda でを使用して自動キャッシュ更新スケジュールを設定するには

S3 ファイルゲートウェイで使用される S3 バケットを特定します。
[Event] (イベント) セクションが空白であることを確認します。このセクションは、後で自動的に入力されます。
IAM ロールを作成し、Lambda 関数 lambda.amazonaws.com との信頼関係を許可します。

以下のポリシーを使用します。

Lambda コンソールから Lambda 関数を作成します。

Lambda タスクに次の関数を使用します。


import json
import boto3
client = boto3.client('storagegateway')
def lambda_handler(event, context):
    print(event)
    response = client.refresh_cache(
        FileShareARN='arn:aws:storagegateway:ap-southeast-2:672406474878:share/share-E51FBS9C'
    )
    print(response)
    return 'Your FileShare cache has been refreshed'

[Execution role] (実行ロール) で、作成した IAM ロールを選択します。
オプションで、Amazon S3 のトリガーを追加し、イベント (ObjectCreated または ObjectRemoved) を選択します。

注記
RefreshCache では、新しいプロセスを開始する前に、前のプロセスを完了する必要があります。バケット内で多数のオブジェクトを作成または削除すると、パフォーマンスが低下する可能性があります。このため、S3 トリガーは使用しないことをお勧めします。代わりに、以下で説明する Amazon CloudWatch ルールを使用します。
CloudWatch コンソールで CloudWatch ルールを作成し、スケジュールを追加します。通常は、30 分間の固定レートの設定が推奨されます。ただし、大きな S3 バケットでは 1～2 時間を使用できます。
CloudWatch イベントのための新しいトリガーを追加し、作成したルールを選択します。
Lambda 設定を保存します。[テスト] を選択します。
[S3 PUT] をクリックし、要件に合わせてテストのカスタマイズを行います。
テストが成功します。成功しない場合は、JSON で要件を変更して再テストします。
Amazon S3 コンソールを開き、作成したイベントと Lambda 関数 ARN が存在することを確認します。

Amazon S3 コンソールまたは AWS CLIを使用して、オブジェクトをソース S3 バケットにアップロードします。

CloudWatch コンソールは、次のような CloudWatch 出力を生成します。


{
    u'Records': [
        {u'eventVersion': u'2.0', u'eventTime': u'2018-09-10T01:03:59.217Z', u'requestParameters': {u'sourceIPAddress': u'MY-IP-ADDRESS'}, 
        u's3': {u'configurationId': u'95a51e1c-999f-485a-b994-9f830f84769f', u'object': {u'sequencer': u'00549CC2BF34D47AED', u'key': u'new/filename.jpeg'}, 
        u'bucket': {u'arn': u'arn:aws:s3:::amzn-s3-demo-bucket', u'name': u'MY-GATEWAY-NAME', u'ownerIdentity': {u'principalId': u'A3OKNBZ72HVPP9'}}, u's3SchemaVersion': u'1.0'}, 
        u'responseElements': {u'x-amz-id-2': u'76tiugjhvjfyriugiug87t890nefevbck0iA3rPU9I/s4NY9uXwtRL75tCyxasgsdgfsq+IhvAg5M=', u'x-amz-request-id': u'651C2D4101D31593'}, 
        u'awsRegion': u'MY-REGION', u'eventName': u'ObjectCreated:PUT', u'userIdentity': {u'principalId': u'AWS:AROAI5LQR5JHFHDFHDFHJ:MY-USERNAME'}, u'eventSource': u'aws:s3'}
    ]
}

Lambda 呼び出では、次のように出力されます。


{
    u'FileShareARN': u'arn:aws:storagegateway:REGION:ACCOUNT-ID:share/MY-SHARE-ID', 
        'ResponseMetadata': {'RetryAttempts': 0, 'HTTPStatusCode': 200, 'RequestId': '6663236a-b495-11e8-946a-bf44f413b71f', 
            'HTTPHeaders': {'x-amzn-requestid': '6663236a-b495-11e8-946a-bf44f413b71f', 'date': 'Mon, 10 Sep 2018 01:03:59 GMT', 
                'content-length': '90', 'content-type': 'application/x-amz-json-1.1'
        }
    }
}

この更新は、クライアントにマウントされた NFS 共有に反映されます。

注記

何百万ものオブジェクトを含む大規模なバケットで、大きなオブジェクトの作成または削除を更新するキャッシュの場合、更新に数時間かかる場合があります。

Amazon S3 コンソールまたは AWS CLIを使用して、オブジェクトを手動で削除します。
クライアントにマウントされている NFS 共有を表示します。(キャッシュが更新されたことにより) オブジェクトが消去されていることを確認します。

CloudWatch Logs をチェックして、イベント ObjectRemoved:Delete での削除に関するログを確認します。


{
    u'account': u'MY-ACCOUNT-ID', u'region': u'MY-REGION', u'detail': {}, u'detail-type': u'Scheduled Event', u'source': u'aws.events', 
    u'version': u'0', u'time': u'2018-09-10T03:42:06Z', u'id':  u'6468ef77-4db8-0200-82f0-04e16a8c2bdb', 
    u'resources': [u'arn:aws:events:REGION:MY-ACCOUNT-ID:rule/FGw-RefreshCache-CW']
}

注記

Cron ジョブまたはスケジュールされたタスクの場合、CloudWatch ログのイベントは u'detail-type': u'Scheduled Event' になります。

Storage Gateway コンソールを使用して手動キャッシュ更新を実行する

Storage Gateway コンソールを使用して手動キャッシュ更新を実行するには

Storage Gateway コンソール (https://console.aws.amazon.com/storagegateway/home) を開きます。
ファイル共有を選択し、更新を実行するファイル共有を選択します。
[アクション] では、[キャッシュを更新] を選択します。

更新処理にかかる時間は、ゲートウェイにキャッシュされているオブジェクトの数、および S3 バケットに対して追加または削除されたオブジェクトの数によって異なります。

Storage Gateway API を使用して手動キャッシュ更新を実行する

次の手順では、Storage Gateway API を使用して手動キャッシュ更新を実行します。API ベースのキャッシュ更新を実行する前に、次の点を考慮してください。

再帰更新または非再帰更新を指定できます。
再帰的な更新は、リソースを大量に消費し、コストが高くなります。
更新には、リクエストで引数として渡すディレクトリと、再帰的な更新を指定した場合のそれらのディレクトリの子孫に対してのみ Amazon S3 API コストが発生します。
更新は、ゲートウェイの使用中に他のオペレーションと同時に実行されます。
- NFS および SMB オペレーションは、オペレーションによってアクセスされるディレクトリの更新がアクティブでない限り、通常、更新中にブロックされません。
- ゲートウェイは、現在のキャッシュコンテンツが古くなっているかどうかを判断できず、鮮度に関係なく NFS および SMB オペレーションに現在のコンテンツを使用します。
- キャッシュ更新はゲートウェイ仮想ハードウェアリソースを利用するため、更新の進行中にゲートウェイのパフォーマンスに悪影響を及ぼす可能性があります。
API ベースのキャッシュ更新の実行は、ゲートウェイと Amazon S3 バケット間のワークフローの外部で、Amazon S3 バケットの内容を直接更新する場合にのみ推奨されます。

注記
ゲートウェイワークフローの外部で Amazon S3 コンテンツを更新する特定のディレクトリがわかっている場合は、これらのディレクトリを API ベースの更新リクエストで指定して、Amazon S3 API のコストとゲートウェイのパフォーマンスへの影響を軽減することをお勧めします。

Storage Gateway API を使用して手動キャッシュ更新を実行するには

Storage Gateway API を使用して HTTP POST リクエストを送信し、目的のパラメータを使用して RefreshCacheオペレーションを呼び出します。詳細については、AWS Storage Gateway API リファレンスのRefreshCache」を参照してください。

注記
RefreshCache リクエストを送信すると、キャッシュ更新オペレーションのみが開始されます。キャッシュの更新が完了しても、必ずしもファイルの更新が完了したとは限りません。ゲートウェイのファイル共有で新しいファイルを確認する前にファイルの更新オペレーションが完了したかどうかを判断するには、refresh-complete 通知を使用します。これを行うには、Amazon CloudWatch イベントを通じて通知を受け取るようにサブスクライブできます。詳細については、「ファイルオペレーションについての通知を受信する」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

NFS ファイル共有アクセスを制限する

S3 オブジェクトロックの使用