翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon S3 バケットのオブジェクトキャッシュの更新
NFS または SMB クライアントがファイルシステムオペレーションを実行すると、ゲートウェイはファイル共有に関連付けられた S3 オブジェクトキャッシュ内のインベントリを維持します。ゲートウェイは、このキャッシュされた在庫表を使用して、Amazon S3 リクエストのレイテンシーと頻度を減らします。このオペレーションでは、S3 ファイルゲートウェイのキャッシュストレージにファイルをインポートしません。キャッシュされたインベントリを更新するだけで、S3 オブジェクトキャッシュ内のオブジェクトのインベントリに変更が反映されます。
ファイル共有の S3 バケットオブジェクトキャッシュを更新するには、次のリストからユースケースに最適な方法を選択し、対応する以下の手順を実行します。
**注記**
使用する方法に関係なく、ディレクトリを初めて一覧表示すると、ゲートウェイは Amazon S3 からディレクトリのメタデータコンテンツを一覧表示します。ディレクトリの初期化に必要な時間は、そのディレクトリのエントリ数に比例します。
**Topics**
+ [Storage Gateway コンソールを使用して自動キャッシュ更新スケジュールを設定する](#auto-refresh-console-procedure)
+ [Amazon CloudWatch ルール AWS Lambda で を使用して自動キャッシュ更新スケジュールを設定する](#auto-refresh-lambda-procedure)
+ [Storage Gateway コンソールを使用して手動キャッシュ更新を実行する](#manual-refresh-console-procedure)
+ [Storage Gateway API を使用して手動キャッシュ更新を実行する](#manual-refresh-api-procedure)
## 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 コンソールを使用して自動キャッシュ更新スケジュールを設定するには**
1. Storage Gateway コンソール ([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/)) を開きます。
1. [**File shares (ファイル共有)**] を選択します。
1. 更新スケジュールを設定するファイル共有を選択します。
1. [**Actions (アクション)**] で、[**Edit share settings (共有の設定の編集)**] をクリックします。
1. [**S3 からのキャッシュを自動化で更新する**] のチェックボックスをオンにし、有効期限 (Time To Live = TTL) を使用してファイル共有のキャッシュ更新を実行する時間を日、時間、分で指定します。TTL は、ディレクトリにアクセスすると、ファイルゲートウェイが最初にそのディレクトリのコンテンツを Amazon S3 バケットから更新するようになる、最後の更新からの期間です。
1. **[Save changes]** (変更の保存) をクリックします。
## Amazon CloudWatch ルール AWS Lambda で を使用して自動キャッシュ更新スケジュールを設定する
**Amazon CloudWatch ルール AWS Lambda で を使用して自動キャッシュ更新スケジュールを設定するには**
1. S3 ファイルゲートウェイで使用されている S3 バケットを特定します。
1. *[Event (イベント)]* セクションが空白であることを確認します。このセクションは、後で自動的に入力されます。
1. IAM ロールを作成し、Lambda 関数 `lambda.amazonaws.com` との信頼関係を許可します。
1. 以下のポリシーを使用します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "StorageGatewayPermissions",
"Effect": "Allow",
"Action": "storagegateway:RefreshCache",
"Resource": "*"
},
{
"Sid": "CloudWatchLogsPermissions",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:CreateLogGroup",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
```
------
1. Lambda コンソールから Lambda 関数を作成します。
1. 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'
```
1. **[Execution role]** (実行ロール) で、作成した IAM ロールを選択します。
1. オプションで、Amazon S3 のトリガーを追加し、イベント (**ObjectCreated** または **ObjectRemoved**) を選択します。
**注記**
`RefreshCache` では、新しいプロセスを開始する前に、前のプロセスを完了する必要があります。バケット内で多数のオブジェクトを作成または削除すると、パフォーマンスが低下する可能性があります。このため、S3 トリガーは使用しないことをお勧めします。代わりに、以下で説明する Amazon CloudWatch ルールを使用します。
1. CloudWatch コンソールで CloudWatch ルールを作成し、スケジュールを追加します。通常は、30 分間の*固定レート*の設定が推奨されます。ただし、S3 バケットが大規模な場合は、これを 1～2 時間にすることも可能です。
1. CloudWatch イベントのための新しいトリガーを追加し、作成したルールを選択します。
1. Lambda 設定を保存します。**[テスト]** を選択します。
1. **[S3 PUT]** をクリックし、要件に合わせてテストのカスタマイズを行います。
1. テストが成功します。成功しない場合は、JSON で要件を変更して再テストします。
1. Amazon S3 コンソールを開き、作成したイベントと Lambda 関数の ARN が存在することを確認します。
1. 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 共有に反映されます。
**注記**
何百万ものオブジェクトを含む大規模なバケットで、大きなオブジェクトの作成または削除を更新するキャッシュの場合、更新に数時間かかる場合があります。
1. Amazon S3 コンソールまたは AWS CLIを使用して、オブジェクトを手動で削除します。
1. クライアントにマウントされている NFS 共有を表示します。(キャッシュが更新されたことにより) オブジェクトが消去されていることを確認します。
1. 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 コンソールを使用して手動キャッシュ更新を実行するには**
1. Storage Gateway コンソール ([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/)) を開きます。
1. [**File shares (ファイル共有)**] を選択し、更新を実行するファイル共有を選択します。
1. [**Actions (アクション)**] では、[**Refresh cache (キャッシュを更新)**] を選択します。
更新処理にかかる時間は、ゲートウェイにキャッシュされているオブジェクトの数、および 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](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_RefreshCache.html)」を参照してください。
**注記**
`RefreshCache` リクエストの送信は、キャッシュ更新操作を開始するだけです。キャッシュの更新が完了しても、必ずしもファイルの更新が完了したとは限りません。ゲートウェイのファイル共有で新しいファイルを確認する前にファイルの更新オペレーションが完了したかどうかを判断するには、`refresh-complete` 通知を使用します。これをするには、Amazon CloudWatch Events を介して通知を受け取ることができます。詳細については、「[ファイルオペレーションについての通知を受信する](monitoring-file-gateway.md#get-notification)」を参照してください。