2023. 3. 26. 21:58ㆍBACKEND/AWS
AWS S3에 대한 이해부터 활용까지 이해하는 것이 본 포스팅의 목표입니다.
===== AWS S3, 제대로 이해하기 Series. =====
✔️ AWS S3, 제대로 이해하기 - S3 Basics
✔️ AWS S3, 제대로 이해하기 - Storage Classes
✔️ AWS S3, 제대로 이해하기 - Lifecycle
👉🏻 AWS S3, 제대로 이해하기 - Replication & Event Notification
Replication
S3의 Replication은 특정 버킷(Source Bucket)에서 다른 버킷(Target Bucket)으로 비동기 방식의 복제를 지원하는 기능입니다.
S3의 복제를 위해서는 반드시 버저닝이 활성화되어야 합니다. 버킷 복제는 서로 다른 AWS 계정 간에도 사용할 수 있습니다.
아마존 S3의 복제 기능을 살펴보도록 하겠습니다. S3 버킷의 Management Tab을 선택하면 Replication rules를 확인할 수 있습니다.
지금부터 Replicatoin rules를 설정해보며 기능을 깊이 알아보도록 하겠습니다.
먼저, 아래와 같이 Replication Rule을 하나 생성합니다. 해당 실습에서는 prefix로 log/ 를 지정했는데, 해당 버킷의 log/ 하위 객체들을 대상으로 복제가 이루어짐을 의도한 것입니다.
Prefix로 log/ 이하의 데이터를 복제하게끔 만들었기 때문에 S3 버킷의 log/ 하위에 파일을 하나 업로드해보겠습니다.
Source Bucket인 s3-bucket-example-gngsn 버킷의 log/ 아래에 {current-time}.log 파일 하나를 업로드 했습니다.
Replication Rule 에 의해 Target Bucket인 s3-bucket-example-gngsn-logging에 동일한 파일이 복제되어야 하는데요.
한 번 확인해보겠습니다.
복제는 즉각적으로 이루어지지 않아 어느정도 복제 지연을 기다려야 합니다. 위의 케이스는 1분이 안되어서 복제가 된 것을 확인할 수 있었습니다. 업로드된 객체를 확인해보니, Version ID가 NPpqsJSN0eJWB0s11mfrcXtjwigX6_QV인 것을 확인할 수 있고, 복제 타겟 버킷인 s3-bucket-example-gngsn-logging에 동일한 Version ID가 생성되었습니다.
# Versioning Object Replication
이후 버전 객체에 대해서는 어떻게 될까요?
새로운 버전의 객체를 만들기 위해 동일한 파일을 업로드 해보겠습니다.
마찬가지로, 어느 정도 지난 후에 확인하면 새로 생성된 객체의 버전에 맞게 객체가 복제되었습니다.
버킷 복제에 대해서 몇 가지 생각해볼 내용이 있습니다.
몇 가지 의문 사항을 나열해볼테니 같이 생각해봅시다.
# S3 Batch Replication: 기존 객체 복제
먼저, 버킷을 사용하다가 중간에 Replication Rules를 활성화하면, 기존의 객체 및 데이터는 어떻게 될까요?
버킷 속성의 복제를 활성화한 후에는, 새롭게 등록되는 객체만 복제 대상이 됩니다.
만약 기존의 객체를 복제하고 싶다면, S3 배치 복제 기능인 S3 Batch Replication을 사용해야 합니다.
S3 배치 복제는 기존 객체부터 복제에 실패한 객체까지 복제할 수 있습니다.
# Delete Marker Replication
두 번째 의문점은 Versioning되는 객체에 대한 복제가 이루어진다면, 삭제 마커 또한 같이 생성될까요?
(버저닝 객체를 삭제했을 때, 실제 삭제되는 것이 아니라 해당 버전에 삭제 마커가 생성됨)
기본적으로 삭제 마커가 복제되지 않습니다. 하지만, 삭제 마커를 선택적으로 복제를 선택할 수 있습니다.
Replication Rule 설정 시 Delete marker replication 옵션이 있었는데요. 해당 옵션이 활성화 되어 있다면 삭제 마커 또한 복제할 수 있습니다. 기존의 Replication Rule을 수정해서 Delete Marker까지 복제 되는 것을 확인해보겠습니다.
버킷의 Replication Rule을 수정하여 Delete marker replication 옵션을 활성화시켰습니다.
이제 업로드한 객체를 삭제해보겠습니다. 물론 삭제를 해도 Versioning 이 활성화되어 있기 때문에 Delete Marker가 생성되겠죠.
이제 복제 타겟 버킷을 확인합니다.
Delete Marker 까지 복제된 것을 확인할 수 있습니다.
단, 특정 Version ID로 삭제하는 경우에는 Delete Marker가 복제되지 않고 원본 버켓에서만 영구 삭제됩니다. 누군가 악의를 품고 한 버킷에서 다른 버킷으로 ID 삭제 마커를 복제하면 안 되기 때문입니다.
시간이 흐른 후 타겟 버킷을 확인해보면, 복제 버킷에서는 해당 버전이 그대로 남는 것을 확인할 수 있습니다.
그렇다면 원본 버킷의 Delete Marker를 삭제하면 어떻게 될까요?
결론적으로, 위와 동일하게 원본 버킷의 Delete Marker를 삭제해도 복제 버킷의 Delete Marker는 삭제되지 않습니다.
직접 확인해보기 위해 먼저, 원본 버킷에 생성된 Delete Marker를 지웠습니다.
1분 정도 지난 이후, 복제 타깃 버킷을 확인해보니 Delete Marker가 그대로 인 것을 확인할 수 있습니다.
# Chaining Replication X
마지막으로 체이닝 복제는 불가합니다.
A 버킷 객체를 B 버킷에 복제하는 Rule를 정의하고,
B 버킷 객체를 C 버킷에 복제하는 Rules를 정의한다고 해서,
A 버킷의 객체가 C 버킷으로 복제되지 않습니다.
Cross-Region Replication
: CRR, 교차 리전 간 복제
특정 리전에 S3 버킷이 있을 때, 다른 리전의 S3 버킷에 복제하는 것을 의미합니다.
가령, ap-northeast-2 리전에 S3 버킷이 있고, 이를 us-east-2 리전의 S3 버킷에 비동기 복제를 해야 하는 상황에 적합합니다. 소스 버킷과 복제 대상 버킷 둘 모두 버전 관리 기능이 활성화되어야 합니다.
Use cases
: compliance, lower latency access, replication across accounts
CRR은 여러 Region에 분포되어 있어야 성능이나 기능 상 유리할 때 사용합니다.
가령, 사용 사례는 법규나 내부 체제 관리(compliance)일 때 여러 리전 S3로 분산시킬 수 있고,
여러 서버에서 S3 객체를 접근할 때 발생할 스 있는 지연 시간(lower latency access)을 줄일 수 있습니다. 가령, 한국과 싱가포르, 프랑스 리전에 서버를 단독 리전의 S3에 접근하는 것보다 각각 한국, 싱가포르, 프랑스 리전의 S3로 복제해 접근하면 훨씬 빨라집니다.
마지막으로 계정 간 복제(across accounts)에도 쓸 수 있습니다.
Same-Region Replication
: 같은 리전으로 복제
쉽게 구분하면, CRR은 이름 그대로 두 리전이 달라야 하며, 반대로 SRR은 같은 리전이어야 합니다
Use cases
: log aggregation, live replication between production and test accounts.
SRR은 다수의 S3 버킷간의 로그를 통합할 때나, 개발 환경이 별도로 있어 운영 환경과 개발 환경간의 실시간 복제를 필요로 할 때 사용될 수 있습니다.
S3 Event Notifications
Amazon S3에서 이벤트가 발생하는데, 객체의 생성, 삭제, 복원, 복제 등의 모든 이벤트를 일컫습니다.
알림 설정은 객체의 구분을 위해 Prefix나 Tags로 필터링할 수도 있습니다. 예를 들어 .jpg 로 끝나는 객체를 필터링할 수 있죠.
또, 다른 AWS 서비스와 통합할 수 있습니다.
가령, 사진의 섬네일을 생성하려고 한다면, 이에 대한 이벤트 알림을 만들어서 다른 AWS 수신 서비스로 보낼 수 있습니다.
이 때 수신 서비스는 SNS, SQS 대기열이나 Lambda 함수가 될 수도 있습니다.
이벤트 전달 시간은 일반적으로 몇 초밖에 안 걸리지만 가끔 1분 이상 걸릴 수도 있습니다.
실제 SQS로 이벤트를 전송해보는 과정을 살펴보겠습니다.
1. SQS 생성
먼저 SQS의 새로운 Queue를 생성합니다.
2. SQS 정책 설정
그리고 S3에서 보내는 이벤트를 받아야 하는데, 이 때 필요한 SQS 접근 정책을 설정해야 합니다. 생성한 Queue의 Access policy를 수정합니다.
정책은 AWS 정책 생성기를 통해 제작합니다.
S3가 SQS Queue에 접근하기 위해서는 아래와 같은 설정이 필요합니다.
✔️ Principal: *
✔️ AWS Service: Amazon SQS
✔️ Actions: SendMessage
✔️ ARN: 생성한 SQS ARN
✔️ Condition (optional)
- Condition: ArnEquals
- Key: aws::SourceArn
- Value: SQS Queue에 메세지를 보낼 AWS S3의 ARN
생성한 정책 JSON을 SQS의 Access policy에 입력 후 저장합니다.
3. S3 Event notification 생성
설정이 끝났으면, S3의 Event notification을 생성합니다.
설정 시 Event types 를 Object Creation의 모든 Action으로 선택했기 때문에 해당 버킷에 객체가 생성될 때마다 이벤트가 발생하여 SQS로 전달됩니다.
4. S3 Event notification 테스트
그럼, 이제 실제로 이벤트가 SQS로 잘 전달되는지 확인해보겠습니다.
어느 정도 시간이 지나고 난 후 SQS를 확인하면 아래와 같이 이벤트가 발생한 것을 확인할 수 있습니다.
Poll for messages을 클릭하여 확인할 수 있습니다.
Amazon EventBridge
최근에 S3 이벤트 알림은 Amazon EventBridge와 통합되었습니다.
S3 속성의 Amazon EventBridge을 활성화하면 S3의 거의 모든 이벤트가 Amazon EventBridge로 모이게 됩니다. 더 자세한 사항은 AWS Official Blog를 확인하세요.
EventBridge는 필터링 옵션을 이전보다 훨씬 더 심화시켜 사용할 수 있어요
메타데이터, 객체 크기 그리고 이름 등으로 필터링할 수 있고, 동시에 여러 수신지로 보낼 수도 있습니다.
가령 Kinesis Streams나 Firehose에도 보낼 수 있고, EventBridge에서 제공하는 기능을 사용할 수도 있습니다. 이벤트를 보관(archive)하거나 재생할 수 있고 안정적으로 전송할 수 있습니다.
'BACKEND > AWS' 카테고리의 다른 글
| AWS VPC, 제대로 이해하기 1: Hands-On (0) | 2023.04.18 |
|---|---|
| AWS VPC, 제대로 이해하기 1 (0) | 2023.04.17 |
| AWS S3, 제대로 이해하기 - Lifecycle Rules (2) | 2023.03.23 |
| AWS S3, 제대로 이해하기 - Storage Classes (0) | 2023.03.12 |
| AWS S3, 제대로 이해하기 - S3 Basics (2) | 2023.02.26 |
Backend Software Engineer
Gyeongsun Park