143. S3 MFA Delete
이제 MFA-삭제를 자세히 살펴보겠습니다
MFA-삭제는 MFA라고 하는 다요소 인증을 사용해 사용자로 하여금 장치에서 코드를 생성하도록 하는데요, 장치는 휴대전화 혹은 하드웨어 키 등이 되겠죠. S3에서 중요한 작업 전 이뤄지는 과정입니다
MFA-삭제를 사용하려면 먼저 S3 버킷에서 버저닝을 활성화해야 하는데요. 이 부분은 다들 알고 계시죠
MFA가 필요한 경우는
- 영구적으로 객체 버전을 삭제하거나
- 버킷에서 버저닝을 중단하는 경우입니다
MFA를 사용해야 하는 중요하고 파괴적인 작업들이죠
MFA를 사용할 필요가 없습니다
- 하지만 버저닝을 활성화하거나
- 삭제된 버전을 목록화할 때
- 혹은 마커를 붙여서 버전을 삭제하는 경우 등에는
MFA-삭제에는 한 가지 중요한 점이 있는데요. 오직 루트 계정인 버킷 소유자만이 활성화 및 비활성화를 할 수 있습니다. 즉, 관리자 계정이 있어도 MFA-삭제를 활성화하지 못합니다. 루트 계정을 사용해야만 하죠
게다가 결코 쉬운 작업이 아니라서 현재는 CLI를 통해서만 MFA-삭제를 사용합니다. 설정하기 정말 어렵지만 어떻게 하는지 보여드릴 겁니다. 루트 자격 증명을 사용해야 하는데 현재는 콘솔에서는 불가능한 작업이고 CLI를 통해서만 할 수 있죠 함께 살펴 보도록 하겠습니다.
직접 실습을 하실 필요는 없고 굉장히 어렵고 힘든 작업이라 그냥 제가 하는 걸 보시기만 하세요. 루트 계정만이 MFA 삭제를 활성화 및 비활성화할 수 있다는 점만 이해하시면 됩니다. 그리고 MFA는 영구적인 객체 버전 삭제나 버킷의 버저닝을 중단하는 경우에만 사용되죠.
143. S3 MFA Delete 실습(실습)
144. S3 기본 암호화 + 실습
이번 강의에서 다룰 내용은 S3 기본 암호화입니다
S3 버킷에 객체를 푸시하고 객체가 암호화되도록 하기 위해서는 버킷 정책을 사용해 암호화를 강제할 수 있습니다.
버킷 정책을 사용하면 API 호출에서 암호화 헤더가 지정되지 않은 채 Amazon S3에 도달하면, 요청이 거부됩니다. 따라서 사용자의 S3 버킷에 푸시되는 모든 객체를 암호화하는 효과를 가져옵니다.
이런 방법 외에 다른 방법도 있는데요. Amazon S3의 기본 암호화 옵션을 사용하는 겁니다. 암호화되지 않은 객체를 Amazon S3에 업로드하면 기본 암호화 옵션을 통해 암호화가 이루어지는 겁니다. 다만 암호화된 객체를 업로드할 때 재암호화가 되지는 않습니다.
중요한 점은 버킷 정책 방식이 기본 암호화보다 먼저 먼저 고려된다는 것입니다. 예를 들어 SSE-S3이라는 암호화 메커니즘을 강제하려면 버킷 정책을 사용해야 하지만 그저 버킷 내 모든 객체를 암호화하는 것이 목적이라면 기본 암호화를 사용해도 됩니다.
그럼 이제 버킷을 생성해 봅시다
s3-default-encryption- stephane-demo
그리고 Create bucket을 클릭합니다
버킷 화면에서 Properties 탭으로 들어가 보면
기본 암호화가 있네요 해당 버킷에 저장되는 새 객체를
자동 암호화한다고 나와 있죠
따라서 이를 활성화시키고 암호화 유형을 선택할 수 있습니다
Amazon SSE-S3를 사용하거나 혹은 SSE-KMS를 선택하면
사용자 키를 지정할 수 있죠
여기서는 SSE-S3를 선택하고
변경 내용을 저장합니다
그러면 예상되시겠지만 이제 예를 들어 coffee.jpg 파일을
업로드하려 하면 보시다시피
암호화 메커니즘을 지정하지 않은 상태입니다
Close를 눌러서 나갑시다 이제 객체로 돌아가서
암호화 필드를 검색해서 찾아보면
여기에 있네요 보시다시피
서버 측 암호화 설정이 해당 객체에 활성화되었습니다
또한 사용 중인 서버 측 암호화는
Amazon SSE-S3입니다
그럼 다른 객체를 업로드해 봅시다 beach.jpg 파일입니다
이번에는 Properties에서 암호화 키를 지정할 겁니다
그러면 기본 암호화 버킷 설정이나
덮어쓰기를 선택할 수 있는데요
덮어쓰기를 선택해서
KMS 키와 aws/s3 KMS 관리 키를 선택하고 Upload를 클릭합니다
그러면 파일을 클릭해 확인해 봅시다
스크롤을 내려서 암호화 부분으로 이동합니다
보시다시피 기본 암호화가 활성화되어 있음에도 불구하고
이 파일은, SSE-KMS 및 아까 우리가 지정했던
KMS 키로 암호화되었습니다
즉 기본 암호화가 모든 파일의 암호화에 적용되는 게 아니라
객체를 암호화하지 않은 채 업로드하면 기본 암호화 메커니즘이 자동으로
암호화를 하는 메커니즘일 뿐인 겁니다
이번 강의는 여기까지입니다 도움이 되었길 바라며
145. S3 액세스 로그
이번 강의에서는 Amazon S3 액세스 로그에 대해 알아 봅니다. 예를 들어 감사 목적으로
모든 액세스를 S3 버킷에 로깅하는 경우
Amazon S3로 보내지는 모든 요청은 계정과 승인 여부에 상관 없이 다른 S3 버킷에 로깅 되어 이후에 분석이 가능합니다.
예를 들어 데이터 분석 도구를 이용해서 분석하거나
나중에 배울 Amazon Athena를 사용해 분석할 수도 있죠.
도면으로 살펴보겠습니다 사용자가 버킷에 요청을 보냅니다. 이 버킷에는 다른 버킷 즉 로깅 버킷으로의 로깅이 활성화되어 있는 상태죠. 따라서 S3 액세스 로그를 활성화하면 로깅 버킷으로 모든 요청이 로깅될 겁니다. 아주 쉽고 간단하죠
로그 형식은 이 링크에 정의되어 있으니 로그를 읽는 방법에 대해 알고 싶으시면 링크를 클릭해 알아 보세요.
로깅 버킷에 대해 알아 두셔야 할 점이 있는데요. 당연해 이야기같지만 한 번은 짚고 넘어 가야 합니다
모니터링 중인 버킷을 로킹 버킷으로 설정하시면 절대로 안 됩니다.
만약 모니터링 버킷을 로깅 버킷으로 사용하게 되면 로깅 루프가 생기게 되고 버킷의 크기가 기하급수적으로 커집니다.
설명은 간단합니다 여기 버킷이 있어요. 애플리케이션 버킷이면서 모든 로그를 수신할 버킷이기도 합니다. 그럼 사용자가 객체를 넣을 때마다 버킷이 자기 내부에 로깅함으로써 로깅 루프가 생성되고 새 객체에 로깅될 새 객체를 생성하고 이는 또 새 객체에 로깅이 되는 무한 로깅 루프가 생기게 되며 버킷 크기가 기하급수적으로 커지게 됩니다. 집에서는 절대 시도해 보지 마세요. 이런 작은 실수로 인해 엄청나게 많은 AWS 비용을 지불하시게 될 겁니다. 애플리케이션 버킷과 로깅 버킷은 꼭 분리하시기 바랍니다.
146. S3 액세스 로그 - 실습(실습)
147. S3 복제(리전 간 및 동일한 리전)
S3 복제인 CRR과 SRR을 살펴볼 차례입니다. CRR은 리전 간 복제를 뜻하고 SRR은 동일 리전 복제를 뜻해요 조금 후 설명해 드리겠습니다.
S3 버킷이 있는데 이 버킷은 eu-west-1에 있습니다. 모든 버킷 콘텐츠를 타 리전 us-east-1에 지속적으로 복제하려 해요. 그렇게 하려는 이유는 eu-west-1에 재해가 발생할 경우를 대비해 다른 리전에 저장하는 거죠. 따라서 내부적으로 비동기식 복제가 이루어져야 합니다. 그러려면 소스 및 대상 버킷에 버저닝을 활성화해야 합니다.
그리고 리전 간 복제, 즉 다른 리전에서 이동하거나 예를 들어 eu-west-1에서 us-east-1로 이동하는 거죠.
혹은 동일 리전 복제인 SRR로 동일 리전에서 이동할 수 있습니다. eu-west-1에서 eu-west-1로요
버킷이 다른 AWS 계정에 있을 수도 있습니다.
그리고 복제는 비동기식이므로 백그라운드에서 이루어질 겁니다.
복제를 실행하려면 S3에 적절한 IAM 권한을 제공해야 해요.
그러므로 CRR의 사용 사례는 규정 준수 및 액세스 시 지연 시간 단축 또는 계정 간 복제 등이 있습니다.
SRR의 경우에는 여러 계정에 걸친 로그 집계와 프로덕션 및 테스트 계정 간의 실시간 복제 또는 재해 복구입니다.
S3 복제에 대해 참고할 내용은
S3 복제를 활성화하면 버킷의 내부에서 활성화한 시점부터 새로운 객체만 복제될 것입니다.
하지만 기존 객체를 복제하려면 S3 배치 복제라는 기능을 사용해요.
- 그러면 기존 객체뿐만 아니라 S3 복제 메커니즘에서 실패한 모든 객체를 복제할 수 있습니다.
S3 버킷에서 DELETE 작업을 할 때는,
- 소스에서 대상 버킷으로 삭제 마커를 복제할지 여부를 선택하는 옵션이 있고요.
- 만약 특정한 버전 ID를 삭제하려고 한다면 악의적인 삭제를 막기 위해 복제되지 않을 겁니다. 타인이 데이터를 영구 삭제하지 못하도록 하기 위해서죠.
마지막으로 연쇄(Chaining) 복제가 존재하지 않습니다.
- 즉 버킷 1이 버킷 2에 복제되고 버킷 2가 버킷 3에 복제되면
- 버킷 1의 객체는 버킷 3으로 복제되지 않지요
148. S3 복제 실습
149. S3 사전 서명된 URL
이번에는 앞서 이야기했던 S3 사전 서명된 URL을 살펴보겠습니다. 이론을 공부했으니 이제 실습을 할 차례죠.
사전 서명된 URL을 생성하려면 SDK 또는 CLI를 사용해야 합니다
- 다운로드의 경우 쉬운 방법으로 CLI를 사용하고, 업로드의 경우는
- 조금 더 어려우며 SDK를 사용해야 하죠. 그래도 쉬운 편입니다 이번 강의에서는 다운로드를 살펴봅니다
사전 서명된 URL을 생성하면 기본적인 만료 시간은 3,600초, 즉 1시간입니다. 시간초과를 변경하려면 명령어 --expires-in에 파라미터, 인자, 그리고 초 단위로 시간을 지정하면 됩니다.
사전 서명된 URL이 사용자에게 제공될 때는 기본적으로 생성한 사람의 권한이 상속됩니다. 즉 객체를 만든 이의 권한이죠 따라서 사용자들은 상황에 따라 GET이나 PUT 권한을 사용할 수 있습니다.
이 기능의 사용에는 다양한 이유가 있죠
- 로그인한 사용자만이 S3 버킷의 프리미엄 영상을 다운로드하도록 승인하거나 즉 로그인한 프리미엄 사용자에게만 약 15분 동안 다운로드가 허용되도록 할 수 있겟죠.
- 또는 파일을 다운로드할 사용자들의 목록이 지속적으로 변경될 경우 사용자가 버킷에 직접 액세스하지 못 하게끔 해야할 겁니다. 굉장히 위험하고 유지 관리도 힘들거든요. 항상 새로운 사용자가 몰리기 때문입니다. 이런 경우에는 동적으로 URL을 생성해 사전 서명을 한 뒤 시간이 지나면서 URL을 URL을 제공하고자 할 수도 있겠죠.
- 아니면 사용자가 버킷의 특정 위치에만 파일을 업로드하도록 일시적으로 승인할 수도 있습니다. 예를 들면 사용자가 여러분의 S3 버킷에 프로필 사진을 직접 업로드하도록 하는 등이죠. 그럴 때 사전 서명된 URL을 생성합니다. 기타 다른 사례도 많이 있지만 이제 다운로드에서 사전 서명된 URL을 만드는 방법을 살펴봅시다.
150. S3 사전 서명된 URL - 실습(실습)
151. S3 스토리지 클래스 + Glacier
이제 Amazon S3의 여러 스토리지 클래스 종류를 살펴봅시다
첫 번째는 범용적으로 쓰이는 Amazon S3 Standard입니다.
두 번째는 Amazon S3 Infrequent Access이고.
세 번째는 Amazon S3 One Zone -Infrequent Access입니다.
그다음 Glacier Instant Retrieval와
Glacier Flexible Retrieval 그리고
Glacier Deep Archive가 있고
마지막으로 Amazon S3 Intelligent Tiering이 있습니다.
이번 강의에서 모든 클래스를 자세히 살펴보겠지만 시험에도 나오는 내용이니 알아두셔야 해요.
Amazon S3에서 객체를 생성할 때 클래스를 선택할 수도 있고 스토리지 클래스를 수동으로 수정할 수도 있어요. 혹은 Amazon S3 수명 주기 구성을 사용해 스토리지 클래스 간에 객체를 자동으로 이동할 수도 있죠.
먼저 클래스를 살펴보기 전에 내구성과 가용성의 개념을 정의해 보죠.
내구성(Durability)은
- Amazon S3로 인해 객체가 손실되는 횟수를 나타내는데요. Amazon S3는 매우 뛰어난 내구성을 제공합니다.9가 11개 즉, 99.999999999%의 내구성을 보장하죠.
- Amazon S3에 천만 개의 객체를 저장했을 때 평균적으로 10,000년에 한 번 객체 손실이 예상됩니다. 내구성이 꽤 높은 편이죠.
- Amazon S3에서 모든 스토리지 클래스의 내구성은 동일합니다
가용성은
- 서비스가 얼마나 용이하게 제공되는지를 나타내며
- 스토리지 클래스에 따라 다릅니다
- 예를 들어 S3 Standard의 가용성은 99.99%인데요. 즉, 1년에 약 53분 동안은 서비스를 사용할 수 없다는 의미죠. 다시 말해 서비스를 사용할 때 몇 가지 에러가 발생한다는 뜻입니다. 따라서 애플리케이션을 개발할 때 이 부분을 고려해 두어야 합니다
S3 Standard의 가용성은 99.99%이며
자주 액세스하는 데이터에 사용됩니다. 기본적으로 사용하는 스토리지 유형이죠
지연 시간이 짧고 처리량이 높으며
AWS에서 두 개의 기능 장애를 동시에 버틸 수 있습니다.
사용 사례로는 빅 데이터 분석 모바일과 게임 애플리케이션 그리고 콘텐츠 배포가 있습니다.
다음은 S3 Infrequent Access입니다
이름에서 알 수 있듯이 자주 액세스하지는 않지만 필요한 경우 빠르게 액세스해야 하는 데이터를 말하죠.
S3 Standard보다 비용이 적게 들지만 검색 비용이 발생합니다.
S3 Standard-IA의 가용성은 99.9%로
- S3 Standard에 비해 약간 떨어지죠
- 사용 사례로는 재해 복구와 백업이 있습니다
Amazon S3 One Zone Infrequent Access는
- One Zone-IA로도 불리는데요 단일 AZ 내에서는 높은 내구성을 갖지만 AZ가 파괴된 경우 데이터를 잃게 됩니다.
- 가용성은 더 낮은 수준인 99.5%입니다
- S3 One Zone-IA의 사용 사례는 온프레미스 데이터를 2차 백업하거나 재생성 가능한 데이터를 저장하는 데 쓰입니다.
다음은 Glacier Storage Classes입니다.
Glacier는 이름에서 알 수 있듯이 콜드 스토리지이고요. 아카이빙과 백업을 위한 저비용 객체 스토리지입니다.
비용에는 스토리지 비용과 검색 비용이 들어갑니다.
Glacier 스토리지에는 세 가지 클래스가 있는데요.
먼저 Amazon S3 Glacier Instant Retrieval은
- 밀리초 단위로 검색이 가능합니다. 예를 들어 분기에 한 번 액세스하는 데이터에 아주 적합하죠
- 최소 보관 기간이 90일이기 때문에 백업이지만 밀리초 이내에 액세스해야 하는 경우 적합니다.
그리고 Glacier Flexible Retrieval이 있는데요. 전에는 Amazon S3 Glacier라고 했지만 티어가 추가되면서 이름이 바뀌었어요. Amazon Glacier Flexible Retrieval에는 세 가지 옵션이 있는데요
- Expedited는 데이터를 1~5분 이내에 받을 수 있고 Standard는 데이터를 돌려받는 데 3~5시간 소요됩니다. Bulk는 무료지만 데이터를 돌려받는 데 5~12시간이 소요되죠.
- 최소 보관 기간은 역시 90일입니다. 여기서 Instant는 즉시 처리된다는 의미이고 Flexible는 데이터를 검색하는 데 최대 12시간까지 기다려야 한다는 의미로 보시면 됩니다.
장기 보관을 위한 Glacier Deep Archive가 있는데요. 여기에는 두 가지 검색 티어가 있습니다.
- 12시간인 Standard와 48시간인 Bulk가 있죠. 데이터를 검색하는데 오래 걸리긴 하지만 비용이 가장 저렴합니다. 게다가 최소 보관 기간도 180일이죠
이처럼 다양한 스토리지 클래스가 있고요. 마지막으로 S3 Intelligent Tiering이라는 것이 있는데요.
이것은 사용 패턴에 따라 액세스된 티어 간에 객체를 이동할 수 있게 해줍니다.
소액의 월별 모니터링 비용과 티어링 비용이 발생하지만 S3 Intelligent-Tiering에는 검색 비용이 없어요.
FrequentAccess 티어는 자동이고 기본 티어입니다.
Infrequent Access 티어는 30일 동안 액세스하지 않는 객체 전용 티어이고
Archive Instant Access 티어도 자동이지만 90일 동안 액세스하지 않는 티어 전용입니다.
Archive Access 티어는 선택 사항이며 90일에서 700일 이상까지 구성할 수 있고
역시 선택 사항인 Deep Archive Access 티어는 180일에서 700일 이상 액세스하지 않는 객체에 구성할 수 있습니다.
S3 Intelligent Tiering은 알아서 객체를 이동시켜 주기 때문에 편하게 스토리지를 관리할 수 있어요.
모든 스토리지 클래스를 비교하는 표인데 숫자를 기억할 필요는 없어요. 각 클래스가 무엇인지만 이해하시면 됩니다. 내구성은 모두 9가 11개 있는 정도고 가용성은 AZ가 적을 수록 낮아지죠. 그리고 최소 저장 기간 등도 여기에서 볼 수 있으니 시간이 되실 때 이 표를 직접 살펴보시기 바랍니다. 내용을 이해하셔야 하지만 암기하실 필요는 없어요.
이건 us-east-1에 대한 예시 가격표인데요. 여기에 모든 스토리지 클래스 비용이 나와있지만 이걸 다 기억하실 필요는 없어요. 시간이 되실 때 내용을 살펴보고 확실하게 이해해 두시면 돼요. 클래스 이름이 무엇인지 이해하고 있다면 각 클래스에 대한 내용도 이해가 가실 거예요.
이번 강의는 여기까지입니다.
152. S3 스토리지 클래스 + Glacier - 실습(실습)
153. S3 수명 주기 규칙
지난 실습에서 보신 것처럼 스토리지 클래스 간 객체의 전환이 가능합니다.
어떤 방식으로 하는 걸까요?
AWS의 웹사이트에 설명을 위한 큰 도표가 나와 있습니다. 복잡하긴 하지만 STANDARD_IA를 보시면 INTELLIGENT-TIERING과 ONEZONE_IA, GLACIER와 DEEP_ARCHIVE 등의 가능한 전환들을 보여주고 있습니다. 보시다시피 GLACIER는 STANDARD_IA로 돌아갈 수 없으며 원하시는 경우에는 객체를 복원하고 복원된 사본을 IA로 복사해야 하죠.
드물게 액세스하는 객체의 경우에는 맨 상단의 STANDARD_IA로 보내고 실시간으로 필요한 게 아닌 아카이브 객체는 기본적으로는 GLACIER나 DEEP_ARCHIVE으로 보내지죠.
객체의 클래스 간 이동은 수동으로 할 수도 있지만 수명 주기 구성을 사용해 자동으로 할 수도 있습니다
시험 대비를 위해서는 알아 두셔야 하는 내용이죠
그럼 수명 주기 규칙이란 뭘까요?
전환 작업은 객체를 한 스토리지 클래스에서 다른 스토리지 클래스로 전환하는 데에 도움을 주는 작업입니다.
- 만약 객체를 생성 60일 후 Standard IA 클래스로 보내고
- 6개월 후에는 아카이빙을 위해 Glacier로 옮긴다고 하면 간단하고 자연스러운 과정이죠.
만료 작업이란 일정 기간이 지난 후 객체를 삭제하는 겁니다.
- 예를 들어 액세스 로그 파일들이 일 년이 지나서 더 이상 필요가 없어지면 파일들이 전부 일 년이 넘었으니 만료, 즉 삭제해 달라고 요청하는 식이죠.
- 파일의 오래된 버전을 삭제하는 데에도 사용됩니다 버저닝을 허용해 계속해서 새로운 파일을 덮어쓰기하고 있는데 60일 이상 지난 이전의 버전은 필요가 없다면 만료 작업을 구성해서 60일이 지난 오래된 버전의 파일이나 객체를 만료시키는 겁니다.
- 완료되지 않은 다중 파트 업로드를 정리하는 데에도 사용됩니다. 분할된 파트가 30일 동안 떠돌고 있고 절대 완료되지 않을 거라면 말이죠. 이러한 파트를 제거하기 위해 만료 작업을 구성하는 겁니다.
특정 접두어에 규칙을 적용할 수도 있습니다. 만약 모든 MP3 파일이 'MP3'라는 폴더에 있거나, 접두어를 가지고 있다면 수명 주기 규칙을 해당 접두어에만 설정할 수도 있습니다. 이런 식으로 버킷 내의 다양한 접두어에 수명 주기 규칙을 적용할 수 있죠.
특정 객체 태그를 위해 규칙을 생성할 수도 있습니다. 예를 들어 'Department: Finance'로 태그된 객체에만 규칙을 적용하고 싶다면 그것도 가능하다는 거죠.
시험에는 이런 식의 문제가 출제되는데 예제를 보면서 함께 생각해 봅시다.
프로필 사진이 Amazon S3에 업로드된 후 EC2의 애플리케이션이 썸네일을 생성합니다. 이 썸네일들은 손쉽게 재생성할 수 있으며 45일간만 보관됩니다. 45일 동안은 원본 사진 파일을 즉시 회수할 수 있으며 이후에는 유저가 최대 6시간까지 기다릴 수 있습니다. 이 솔루션을 어떻게 설계할 수 있을까요? 생각할 시간을 드릴 테니
영상을 잠시 멈춘 뒤 솔루션을 함께 살펴봅시다
S3 원본 사진은 Standard 클래스에 두고 수명 주기 구성을 설정해 45일 후 GLACIER로 보내면 됩니다, 왜 그럴까요? 이후에는 아카이브되어야 하기 때문에 회수를 위해 6시간까지도 기다리게 될 수 있는 거죠.
썸네일은 ONEZONE_IA에 두면 되는데, 이유는 뭘까요? 재생성이 가능하기 때문입니다. 그리고 수명 주기 구성을 통해 45일 후 만료, 혹은 삭제를 시킬 수도 있죠. 이해가 되시죠? 45일 후엔 썸네일이 필요 없으니 삭제하는 거죠 원본 사진을 GLACIER로 보내고 썸네일은 ONEZONE_IA에 저장됩니다. 비용이 절감될 테니까요. AWS에서 전체 AZ를 잃을 상황에 대비해 원본 사진으로부터 쉽게 썸네일을 재생성할 수 있습니다. S3 버킷에 대한 비용 효율이 가장 높은 솔루션이 되겠죠.
두 번째 상황입니다
회사에 일어나는 경우는 드물지만 15일 동안은 삭제된 S3 객체를 즉시 복구할 수 있는 규칙이 있다고 합니다. 그리고 그 이후 최대 1년까지는 삭제한 객체를 48시간 내에 복구할 수 있습니다. 이걸 경제적으로 설계하려면 어떻게 해야 할까요?
한 번 해봅시다 S3 버저닝을 허용해야 할 겁니다. 왜냐하면 파일을 삭제는 하되 복구시키길 원하고 있으니까요. S3 버저닝으로 객체 버전을 가질 수 있으며 삭제된 객체는 삭제 마커를 달고 숨겨져 쉽게 복구할 수 있기 때문입니다.
하지만 최신이 아닌 버전들, 즉 객체의 이전 버전들도 가지게 될 겁니다. 그래서 이 오래된 버전들은 S3_IA로 전환을 시킵니다. 왜냐하면 오래된 버전에 액세스할 일은 아주 드물겠지만 만약 액세스하는 경우에는 복구가 즉시 이뤄져야 하기 때문입니다.
그리고 이 오래된 버전들을 복구할 수 있는 15일의 기간이 지나면 이들을 DEEP_ARCHIVE로 전환시켜서 100일이나 365일 동안 보관하는 겁니다. 이들은 아카이브되어 48시간 내에 복구가 가능합니다. 왜 Glacier를 사용하지 않는 걸까요? Glacier는 비용이 좀 더 비싸며 48시간이라는 시간이 주어졌기 때문에 티어를 DEEP_ARCHIVE까지 올려서 비용을 더 절약할 수 있습니다.
시험에서는 이런 식으로 출제가 됩니다. 문제의 출제 의도를 정확히 파악하고 가장 적합한 스토리지 클래스를 파악하고 어떤 수명 주기 규칙이 적절할지를 찾아 내셔야 하죠.
154. S3 수명 주기 규칙 - 실습(실습)
155.S3 애널리틱스
스토리지 클래스 분석에 한 가지 더 추가하자면
Standard로부터 Standard_IA로 언제 객체를 보낼지 결정하기 위해 S3 애널리틱스를 설정할 수 있습니다. 즉 며칠 후에 객체를 보내는 것이 가장 좋을지 계산하는 것이죠.
ONEZONE_IA 또는 GLACIER에 대해 작동하지는 않습니다. 오직 Standard로부터 Standard_IA로 작동합니다.
그리고 이 보고서를 활성화하면 매일 업데이트되죠.
처음 활성화할 때는 첫 시작까지 24~48시간이 소요됩니다.
따라서 수명 주기 규칙을 구축하거나 개선하기 위한 아주 좋은 첫 번째 단계는 며칠 후에 Standard로부터 Standard_IA로 객체를 이동시키는 것이 현명할지 알아내기 위해 S3 애널리틱스를 활성화 하는 것입니다.
156. S3 퍼포먼스
이제 S3 기준 성능에 대해 알아 볼 차례입니다
기본적으로 Amazon S3는 자동으로 아주 많은 수의 요청을 처리하도록 스케일링이 가능하며 S3에서 첫 바이트를 얻기까지 100-200ms 정도로 지연 시간이 굉장히 짧습니다.제법 빠르죠.
그리고 이를 초당 가능한 요청으로 환산하면 접두어 및 초당 3,500개의 PUT/COPY/POST/DELETE 요청을 처리하며 접두어 및 초당 5,500개의 GET/HEAD 요청을 버킷 내에서 처리하는 속도입니다. 웹사이트에 나와있는 내용인데 정확히 모르실 것 같아 접두부 및 초당의 의미를 설명해 드릴 겁니다. 하지만 결국 아주 고성능이라는 의미죠.
버킷 내의 접두어의 개수에는 제한이 없습니다.
그럼 file이라는 이름의 객체 네 개를 예시로 들어 해당 객체의 접두어를 분석해 보겠습니다.
- 첫 번째는 bucket 내의 folder1/sub1/file에 있습니다. 이 경우에 접두어는 bucket과 file 사이의 뭐든 될 수 있습니다. 이 경우엔 /folder1/sub1이 되는 거죠. 이 파일에 대해서 이 접두어는 초당 3,500개의 PUT과 5,500개의 GET을 얻을 수 있습니다.
- 그리고 다른 파일은 folder1/sub2에 있다고 하면 bucket과 file 사이의 뭐든 접두어가 될 수 있으니 /folder1/sub2가 되는 겁니다. 역시 3,500개의 PUT과 5,500개의 GET을 한 접두부에 대해 얻을 수 있는 겁니다.
- 이렇게 1과 2가 있으면 접두어가 서로 다르죠. 이제 접두어에 대해서는 쉽게 이해가 되실 테니 버킷 내의 접두어 및 초당 3,500개의 PUT과 5,500개의 GET을 얻는다는 규칙도 이해가 가실 겁니다.
다시 말해 이 네 개의 접두어에 읽기 작업을 균일하게 분산시키면 초당 22,000개의 HEAD와 GET 요청을 수행하는 셈이니 아주 좋은 거죠.
이제 S3 성능 제한인 KMS를 알아 봅시다
SSE-KMS를 사용해 객체를 KMS 암호화하는 경우 KMS 제한에 의해 영향을 받을 수 있는데요.
파일을 업로드하면 KMS 제한이 여러분을 대신해 S3에서 GenerateDataKey KMS API를 호출할 것이고
SSE-KMS를 통해 S3에서 파일을 다운로드하는 경우에는 Decrypt KMS-API를 호출하게 됩니다. 그리고 이 두 가지 요청은 KMS 할당량에 집계가 되죠.
예를 들어 유저들이 S3 버킷에 연결하고 SSE-KMS 암호화를 사용해 파일을 업로드/다운로드하려 하는 상황입니다. 그러면 S3 버킷이 API를 호출하고 키를 생성하거나 KMS 키로 해독해 그로부터 결과를 가지고 옵니다.
그래서 KMS는 기본적으로 초당 요청에 대한 할당량을 가지고 있죠. 리전에 따라 요청이 초당 5,500개 또는 10,000개 30,000개일 수도 있습니다.
이보다 많은 양이 필요한 경우에는 서비스 할당량 콘솔을 통해 할댱량 증가를 요청할 수 있습니다. 즉, 초당 10,000개 이상의 요청이 초당 5,500개의 요청을 지원하는 특정 리전에 발생하면 요청이 지나치게 몰리게 되겠죠. 그러므로 KMS가 S3의 성능을 방해하지 않게끔 주의해야겠죠. 이러한 할당량은 일반적인 사용량에 비하면 넉넉하지만, 파일이 아주 많을 때나 S3 버킷을 많이 쓸 때를 대비해 알아 두면 좋겠죠.
이제 S3 성능을 살펴봅시다
최적화를 위한 첫 번째 방법은 분할 업로드입니다
- 100MB가 넘는 파일은 분할 업로드가 권장되며 5GB가 넘는다면 분할 업로드가 필수입니다.
- 분할 업로드는 병렬화를 통해 전송 속도를 높이고 대역폭을 극대화합니다.
도면으로 보는 게 이해에 항상 도움이 되죠. Amazon S3에 업로드하고자 하는 큰 파일이 있습니다. 이 파일을 작은 덩어리의 여러 파트로 나눠서 각 파일을 Amazon S3에 병렬로 업로드합니다. Amazon S3에서는 모든 파트가 업로드되면 이들을 다시 모아 큰 파일로 합쳐 주는 겁니다.
아주 중요하죠 S3 Transfer Acceleration은
- 업로드와 다운로드를 위한 건데요 파일을 AWS의 엣지 로케이션으로 파일을 전송함으로써 전송 속도를 높입니다. 엣지 로케이션에서는 데이터를 대상 리전의 S3 버킷으로 보내 주죠. 리전보다 엣지 로케이션의 수가 더 많은데요. 200개가 넘고 계속 늘고 있죠. 그래프를 보면서 함께 살펴볼 겁니다.
- Transfer Acceleration은 분할 업로드와 호환됩니다
예시를 보시면 파일이 미국에 있는 상태에서 호주에 있는 S3 버킷에 이 파일을 업로드하려 합니다. 이럴 때에는 파일을 미국에 있는 엣지 로케이션에 업로드하는 겁니다. 공용 인터넷을 사용해 아주 빠르게 처리합니다. 그러면 해당 엣지 로케이션에서 호주의 Amazon S3 버킷으로 고속 사설 AWS 네트워크를 통해 파일이 전송됩니다. Transfer Acceleration이라고 불리는 이유는 공용 인터넷을 최소한으로 거치면서 사설 AWS 네트워크의 사용을 최대화하기 때문이죠. Transfer Acceleration를 사용하면 전송 속도를 높일 수 있습니다.
그렇다면 파일을 받는 경우에는 어떨까요? 파일을 가장 효율적으로 읽는 법은 뭘까요?
S3 바이트 범위 가져오기라는 방법이 있습니다. 파일의 특정 바이트 범위를 얻어 GET를 마비시키는 방식이죠.
바이트 범위를 얻는 데 실패한 경우에도 작은 바이트 범위를 얻는 작업을 다시 시도함으로써 실패에 대한 복원성을 가지게 되므로
이 방식은 다운로드의 속도를 높이는 데에 사용되죠
예를 들어 S3에 아주 큰 파일이 있는데 파일의 첫 몇 바이트에 해당하는 파트를 요청한다고 합시다. 그리고 두 번째 파트에 이어 마지막 파트까지가 있겠죠. 이 모든 파트들을 특정 바이트 범위 가져오기로 요청할 겁니다. 바이트 범위라고 불리는 건 파일의 특정 범위만을 요청할 것이기 때문이죠. 그리고 이 요청은 전부 병렬적으로 이루어집니다. 즉, GET를 병렬화해서 다운로드를 가속화시키는 원리인 거죠.
두 번째 사용 사례는 파일의 일부를 회수하는 경우로 만약 S3에 있는 파일의 첫 50바이트가 파일에 대한 정보를 제공하는 헤더라는 사실을 알고 있다면
헤더 요청을 바로 보낼 수 있겠죠. 헤더에 해당하는 첫 50바이트를 바이트 범위 요청으로 전송함으로써 해당 정보를 빠르게 얻을 수 있을 겁니다.
여기까지 S3 성능과 업로드와 다운로드의 가속화 방법 및 기준 성능과 KMS 제한에 대해서도 알아봤습니다. 시험 대비로 꼭 알아 두셔야 하는 내용이죠.
157. S3 셀렉트 & Glacier Select
S3 Select와 Glacier Select에 대한 짧은 이론 강의입니다
적은 데이터, 즉 요청한 데이터의 하위 세트를 SQL을 통해 서버 측 필터링을 수행하여 회수하려 하는 겁니다.
SQL의 쿼리는 꽤 간단하죠. 행과 열로 필터링하는 데에만 사용되며 SQL 명령문은 굉장히 간단합니다. 집계 등의 기능은 수행할 수 없고요.
전체 파일을 회수하는 게 아니라서 클라이언트 측에서는 네트워크와 CPU 비용이 절감되며 S3가 선택과 필터링을 해서 필요한 것만을 전달합니다.
기존에는 Amazon S3에서 모든 데이터를 애플리케이션으로 전송한 후 애플리케이션 측에서 필터링을 한 뒤 원하는 행을 찾아내고 필요한 열만 남기는 방식이었다면 이후에 S3 Select를 사용해 데이터를 요청함으로써 필요한 데이터만을 받을 수 있는 거죠. 필요한 행과 열만을 제공받음으로써 Amazon에 따르면 400% 빠르고 80%까지 저렴하다는 결과를 얻을 수 있죠. 네트워크를 거치는 트래픽의 양이 적고 필터링이 서버 측에서 일어나기 때문입니다.
또 다른 도면을 하나 보시죠 클라이언트가 S3 Select를 통해 CSV 파일에서 일부 행과 열을 요청하고 있습니다. Amazon S3는 서버 측에서 CSV 파일을 필터링해 원하는 행과 열을 찾고 클라이언트에게 필터링 된 데이터를 회신합니다. 확실히 네트워크와 CPU 사용량이 줄고 속도가 빨라지죠.
아주 좋습니다 시험을 대비해 정리하자면 S3에서의 서버 측 데이터 필터링을 줄이려면 S3 Select와 Glacier Select를 떠올리세요. Glacier에서도 작동하는 기능입니다 쿼리가 좀 더 복잡한 경우 S3에서 무서버로 처리되는데 이후의 강의에서 다룰 Amazon Athena죠.
158. S3 이벤트 알림
이제 S3 이벤트 알림을 살펴봅시다. Amazon S3에서 이벤트가 발생하는데요.
이벤트라는 것은 객체가 생성된 경우이거나 객체가 삭제되거나 복원된 경우일 수도 있고 복제가 발생한 경우일 수도 있어요.
이런 이벤트를 필터링할 수도 있죠. 예를 들어 .jpg로 끝나는 객체를 필터링할 수 있죠.
이벤트 알림은 예를 들어 Amazon S3에서 발생하는 특정 이벤트에 자동으로 반응하게 할 수 있는데요. Amazon S3에 업로드되는 사진의 섬네일을 생성하려고 한다면 이에 대한 이벤트 알림을 만들어서 몇 가지 수신지로 보낼 수 있어요. SNS 주제가 될 수도 있고 SQS 대기열이나 Lambda 함수가 될 수도 있죠. 이게 무엇인지는 모르셔도 괜찮아요. 이러한 기능에 대해서는 다음 강의에서 배울 예정이니까요.
원하는 만큼 S3 이벤트를 생성하고 원하는 대상으로 보낼 수 있어요.
이벤트가 대상에 전달되는 시간은 일반적으로 몇 초밖에 안 걸리지만 가끔 1분 이상 걸릴 수도 있어요. 이 세 곳이 여러분이 기억해야 할 주요 목적지이지만
이제 네 번째 목적지가 추가됐어요. 이벤트 알림의 새로운 기능으로 Amazon EventBridge와 통합되었죠.
이벤트가 Amazon S3 버킷으로 이동하면 이벤트 종류와 상관없이 모든 이벤트는 Amazon EventBridge로 모이게 됩니다. EventBridge에 대해선 아직 모르시겠지만 여기서 규칙을 설정할 수 있고 이 EventBridge에서 설정한 규칙을 통해 18개가 넘는 AWS 서비스에 이벤트 알림을 보낼 수 있어요. S3 이벤트 알림 기능을 크게 향상시켜 주죠.
EventBridge에 대해서는 나중에 살펴보겠지만 EventBridge가 있으면 고급 필터링 옵션을 이전보다 훨씬 더 많이 사용할 수 있어요. 메타데이터, 객체 크기 그리고 이름 등으로 필터링할 수 있고
동시에 여러 수신지에 보낼 수도 있죠 예를 들어 단계 함수나 Kinesis Streams 혹은 Firehose에도 보낼 수 있고
Amazon EventBridge에서 제공하는 기능을 사용할 수도 있어요. 이벤트를 보관(archive)하거나 재생할 수 있고 보다 안정적으로 전송할 수 있죠.
새로운 서비스이기 때문에 아직 모르시는 내용이 많겠지만 Amazon S3 이벤트 알림에만 집중할게요. 요점은 Amazon S3에서 발생하는 이벤트에 반응할 수 있다는 겁니다. SQS, SNS, Lambda 또는 Amazon EventBridge로 알림을 보내는 것이죠.
159. S3 이벤트 알림 - 실습(실습)
160. S3 요청자 지불
시험에 나올 수도 있는 기능을 설명드리죠. 바로 S3 요청자 지불입니다. 아주 당연해 보이는 이름이죠.
지금까지 배운 내용으로 보면 일반적으로는 버킷 소유자가 버킷과 관련된 모든 Amazon S3 스토리지 및 데이터 전송 비용을 지불합니다.
예를 들어 봅시다 버킷 셋이 있고 그 안에 객체를 보관하고 있습니다. 그리고 요청자, 즉 사용자가 버킷으로부터 파일을 다운로드합니다. 그러면 네트워킹 비용 역시 버킷 및 객체 소유자에게 청구됩니다.
그러나 수많은 대형 파일이 있고 일부 고객이 이를 다운로드하려고 하면 여러분은 요청자 지불 버킷을 활성화 해야 할 겁니다. 이 경우 버킷 소유자가 아니라 요청자가 객체 데이터 다운로드 비용을 지불하죠
다시 예를 들어 봅시다. 소유자가 여전히 버킷의 객체 스토리지 비용을 부담하겠지만 요청자가 객체를 다운로드하면 이제 그 요청자가 다운로드와 관련된 네트워킹 비용을 지불하게 됩니다.
대량의 데이터 셋을 다른 계정과 공유하려고 할 때 매우 유용하죠.
그렇게 하려면 요청자가 익명이어서는 안됩니다. 요청자가 AWS에서 인증을 받아야 합니다. AWS에서 인증을 받아야 AWS가 객체에 대한 특정 다운로드를 요청한 요청자에게 청구할 수 있기 때문이죠. 이 기능을 기억해두세요 시험에 나올 수 있습니다.
161. Athena 개요
이제 Amazon Athena에 대해 알아보겠습니다
Amazon Athena는 아마존 S3에 저장된 객체에 대해 분석을 수행하는 서버리스 쿼리 서비스입니다.
즉, SQL 언어로 이러한 파일들을 쿼리하지만 로드할 필요는 없는 겁니다. 파일들은 S3에 있고 나머지는 Athena가 알아서 해주죠.
이러한 파일의 포맷은 CSV, JSON, ORC, Avro, Parquet 등 다양합니다. 그리고 Athena는 Presto 엔진 기반이죠.
사용자들이 데이터들을 아마존 S3에 로드하면 Amazon Athena는 이러한 데이터를 쿼리하고 분석합니다. 아주 간단하죠 원하시는 경우 Athena와 더불어 Amazon QuickSight와 같은 보고도 받아 볼 수 있습니다.
Athena의 가격은 스캔된 데이터 TB당 5달러입니다.
압축되거나 컬럼형으로 저장된 데이터를 사용할 경우 비용을 절감할 수 있죠. 데이터를 스캔하는 양이 적어지기 때문입니다
Athena는 다양한 경우에 사용되는데요. 비즈니스 인텔리전스 분석, 보고, VPC나 ELB 로그의 Flow Logs 분석, CloudTrail 로그, 플랫폼 로그 등의 AWS의 로그를 사용할 경우 Athena가 아주 유용하죠.
시험에서 SQL 사용, 데이터 분석 서버리스 등의 키워드가 나오면 Amazon Athena를 생각해 보시면 됩니다.
162. Athena 실습(실습)
163. S3 잠금 정책 및 Glacier 볼트 잠금
두 가지 기능에 대해 얘기해 봅시다 첫 번째는 Glacier 볼트 잠금입니다.
이는 한 번 쓰고 여러 번 읽는 WORM 모델을 적용하기 위함입니다. Glacier에 객체를 쓰면 아무도 건드릴 수 없게 되죠.
즉 미래의 편집에 대한 정책을 잠금으로써 더 이상 변경될 수 없도록 하는 것입니다.
규정 준수와 데이터 보존을 위해 이 방식을 사용합니다.
객체가 Glacier 볼트로 가면 그 후에 볼트 잠금 정책을 추가하여 객체가 지워지거나 또는 정책 자체가 지워지는 것을 방지합니다. 누군가 감사를 실시할 때 규정 준수를 보장해 줍니다. 즉 '데이터가 수정되거나 지워지지 않았다는 것을 어떻게 확신하죠?'라는 질문을 받으면 여러분은 'Glacier 볼트에 볼트 잠금 정책을 적용했습니다. 따라서 저를 포함한 누구도 수정할 수 없죠. 객체가 전혀 수정되지 않았다는 것을 AWS가 보증합니다'라고 답할 수 있는 겁니다.
Amazon S3에는 비슷한 것도 있습니다. 바로 S3 객체 잠금이죠. 이를 위해서는 버전 관리를 활성화해야 합니다.
이번에도 WORM 모델을 적용합니다
이는 특정 시간 동안의 객체 버전 삭제를 막죠
객체 보존을 위해 두 가지 옵션이 있습니다
- 특정 기간 동안 객체를 잠그는 Retention Period를 사용하거나 동일한 보호 기능을 하지만
- 객체 보존 만료일이 정해지지 않는 Legal Hold를 할 수 있습니다
S3 객체 잠금의 모드 측면에서는
- 사용자에게 특별한 권한이 부여되지 않았다면 객체 버전을 무효화 또는 삭제하거나 잠금 설정을 변경할 수 없도록 하나
- 거버넌스 모드가 있고 AWS 계정의 루트 사용자를 포함한 어떤 사용자도 보호된 객체 버전을 무효화하거나 삭제할 수 없도록 하는 규정 준수 모드가 있습니다. 따라서 객체가 규정 준수 모드로 잠기면 보존 모드를 변경할 수 없고 보존 기간도 단축할 수 없죠. 객체에 대한 보다 높은 수준의 제한입니다
