Amazon S3 버킷 객체 캐시 새로 고침 - AWS Storage Gateway

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Amazon S3 버킷 객체 캐시 새로 고침

NFS 또는 SMB 클라이언트가 파일 시스템 작업을 수행하면 게이트웨이는 파일 공유와 연결된 Amazon S3 객체 캐시의 객체 인벤토리를 유지합니다. 게이트웨이는이 캐시된 인벤토리를 사용하여 Amazon S3 요청의 지연 시간과 빈도를 줄입니다. 이 작업은 파일을 S3 File Gateway 캐시 스토리지로 가져오지 않습니다. Amazon S3 객체 캐시의 객체 인벤토리 변경 사항을 반영하도록 캐시된 인벤토리만 업데이트합니다.

파일 공유의 S3 버킷 객체 캐시를 새로 고치려면 다음 목록에서 사용 사례에 가장 적합한 방법을 선택한 다음 아래 해당 절차를 완료합니다.

참고

사용하는 방법에 관계없이 디렉터리를 처음 나열하면 초기화되어 게이트웨이가 Amazon S3에서 디렉터리의 메타 데이터 콘텐츠를 나열합니다. 디렉터리를 초기화하는 데 필요한 시간은 해당 디렉터리의 항목 수에 비례합니다.

Storage Gateway 콘솔을 사용하여 자동 캐시 새로 고침 일정 구성

다음 절차에서는 지정한 TTL(Time To Live) 값을 기반으로 자동 캐시 새로 고침 일정을 구성합니다. 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)을 엽니다.

  2. 파일 공유를 선택합니다.

  3. 새로 고침 일정을 구성할 파일 공유를 선택합니다.

  4. 작업에서 파일 공유 설정 편집을 선택합니다.

  5. 이후 S3에서 자동 캐시 새로 고침의 경우 확인란을 선택하고 TTL(Time To Live)을 사용하여 파일 공유의 캐시를 새로 고치는 시간을 일, 시간 및 분으로 설정합니다. TTL은 마지막 새로 고침 이후 디렉터리에 대한 액세스로 인해 File Gateway가 먼저 Amazon S3 버킷에서 해당 디렉터리의 콘텐츠를 새로 고칩니다.

  6. 변경 사항 저장을 선택합니다.

Amazon CloudWatch 규칙과 AWS Lambda 함께를 사용하여 자동 캐시 새로 고침 일정 구성

Amazon CloudWatch 규칙과 AWS Lambda 함께를 사용하여 자동 캐시 새로 고침 일정을 구성하려면
  1. S3 File Gateway에서 사용하는 S3 버킷을 식별합니다.

  2. 이벤트 섹션이 비어 있는지 확인합니다. 나중에 자동으로 채워집니다.

  3. IAM 역할을 생성하고 Lambda에 대한 신뢰 관계를 허용합니다lambda.amazonaws.com.

  4. 다음 정책을 사용합니다.

    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": "*" } ] }
  5. Lambda 콘솔에서 Lambda 함수를 생성합니다.

  6. 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'
  7. 실행 역할에서 생성한 IAM 역할을 선택합니다.

  8. 선택 사항: Amazon S3에 대한 트리거를 추가하고 ObjectCreated 또는 ObjectRemoved 이벤트를 선택합니다.

    참고

    RefreshCache는 다른 프로세스를 시작하기 전에 한 프로세스를 완료해야 합니다. 버킷에 많은 객체를 생성하거나 삭제하면 성능이 저하될 수 있습니다. 따라서 S3 트리거를 사용하지 않는 것이 좋습니다. 대신 다음에 설명된 Amazon CloudWatch 규칙을 사용합니다.

  9. CloudWatch 콘솔에서 CloudWatch 규칙을 생성하고 일정을 추가합니다. 일반적으로 고정 속도는 30분인 것이 좋습니다. 그러나 대형 S3 버킷에는 1~2시간을 사용할 수 있습니다.

  10. CloudWatch 이벤트에 대한 새 트리거를 추가하고 방금 생성한 규칙을 선택합니다.

  11. Lambda 구성을 저장합니다. 테스트를 선택합니다.

  12. S3 PUT을 선택하고 요구 사항에 맞게 테스트를 사용자 지정합니다.

  13. 테스트가 성공해야 합니다. 그렇지 않은 경우 요구 사항에 맞게 JSON을 수정하고 다시 테스트합니다.

  14. Amazon S3 콘솔을 열고 생성한 이벤트와 Lambda 함수 ARN이 있는지 확인합니다.

  15. Amazon S3 콘솔 또는를 사용하여 S3 버킷에 객체를 업로드합니다 AWS CLI. Amazon 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 공유에는이 업데이트가 반영됩니다.

    참고

    수백만 개의 객체가 있는 대용량 버킷에서 대용량 객체 생성 또는 삭제를 업데이트하는 캐시의 경우 업데이트에 몇 시간이 걸릴 수 있습니다.

  16. Amazon S3 콘솔 또는를 사용하여 객체를 수동으로 삭제합니다 AWS CLI.

  17. 클라이언트에 탑재된 NFS 공유를 확인합니다. 객체가 사라졌는지 확인합니다(캐시가 새로 고쳐졌기 때문).

  18. CloudWatch 로그를 확인하여 이벤트를 사용한 삭제 로그를 확인합니다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)을 엽니다.

  2. 파일 공유를 선택한 다음 새로 고침을 수행할 파일 공유를 선택합니다.

  3. 작업에서 캐시 새로 고침을 선택하십시오.

    새로 고침 프로세스에 걸리는 시간은 게이트웨이에 캐싱된 객체의 수와 S3 버킷에 추가되거나 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를 사용하여 수동 캐시 새로 고침을 수행하려면
  • HTTP POST 요청을 전송하여 Storage Gateway API를 통해 원하는 파라미터로 RefreshCache 작업을 호출합니다. 자세한 내용은 Storage Gateway API 참조의 RefreshCache를 참조하세요. AWS Storage Gateway

    참고

    RefreshCache 요청을 보내면 캐시 새로 고침 작업만 시작됩니다. 캐시 새로 고침이 완료되었다고 해서 반드시 파일 새로 고침이 완료되었음을 의미하지는 않습니다. 게이트웨이 파일 공유에서 새 파일을 확인하기 전에 파일 새로 고침 작업이 완료되었는지 확인하려면 refresh-complete 알림을 사용하십시오. 이렇게 하려면 Amazon CloudWatch 이벤트를 통해 알림을 받도록 구독할 수 있습니다. 자세한 내용은 파일 작업에 대한 알림 받기 단원을 참조하십시오.