AWS Certified Solutions Architect - S3

Contents

Amazon S3(Amazon Simple Storage Service)는 확장성, 가용성, 보안성, 성능을 제공하는 Object Storage서비스다. Object Storage는 간단히 말해서 파일 단위의 업로드/다운로드를 서비스하는 것이라 볼 수 있다. S3가 제공하는 파일의 업/다운로드라는 아주 간단한 서비스이지만 무한대에 가까운 용량, 99.999999999% 의 내구성, 저렴한 가격으로 가장 사랑받는(널리 사용하는) 서비스다. 어떤 서비스를 개발하든지 S3는 기본으로 들어간다.

1. 데이터 백업 및 복원 : 99.99999999%의 내구성으로 데이터를 보호 할 수 있다. EBS(Amazon Elastic Block Storage - 블록 스토리지), RDS(데이터베이스), DynamoDB(AWS의 NoSQL Key-Value 데이터베이스) 백업등 모든 AWS 서비스의 기본 백업 장치로 사용 한다. 또한 온-프레미스의 기업 데이터들을 저장소로 사용 할 수 있다.
2. 재해복구 : S3 리전 간 복제 기능을 이용해서 DR 아키텍처를 구축할 수 있다.
3. 아카이브 : S3는 여러 티어를 가진다. S3 Glacier, S3 Glacier Deep Archive등을 이용해서 저렴한 비용으로 장기간 객체를 보호할 수 있다.
4. 데이터 레이크와 빅 데이터 분석 : AWS Lake Formation, AWS EMR(Hadoop), ETL를 위한 대량의 저장공간을 제공한다.
5. CloudFront(CDN)과 연동해서 컨텐츠를 캐시하고 빠르게 서비스 할 수 있다.

S3 오브젝트라고 하면 헷갈릴 수 있는데 오브젝트 == 파일(+메타정보)이라고 접근하기 편할 것이다. 오브젝트 스토리지는 각 데이터의 조각을 가져와서 오브젝트로 지정한다. 데이터는 폴더가 아닌 별도의 저장소에 보관되며 관련 메타 데이터와 고유 식별자들로 스토리지 풀을 형성한다. S3가 제공하는 버킷(폴더)도 일반적인 파일 시스템의 폴더가 아니다. 블록 스토리지는 파일을 여러 개의 데이터 블록으로 분리 한 다음 이러한 블록을 별도의 데이터 조각으로 저장한다.

오브젝트 스토리지는 아래의 장점을 제공한다.

1. 빅 데이터 분석 : 오브텍트 스토리지는 각 오브젝트(파일)에 대한 메타 데이터를 저장 할 수 있다. 모든 파일에 대해서 메타 데이터를 설정함으로써 분석에 도움을 얻을 수 있다.
2. 무한한 확장성 : 파일단위로 저장하기 때문에, 디스크를 추가하거나 노드를 묶어서 무한하게 확장 할 수 있다.
3. 빠른 데이터 검색 : 폴더(디렉토리)구조로 저장하는 구조가 아니기 때문에 데이터를 훨씬 빠르게 검색 할 수 있다. 빠른 검색을 위해서 별도로 색인 할 수 있기 때문이다.
4. 비용 절감 : 상대적으로 적은 비용으로 데이터를 저장 할 수 있다.
5. 자원 최적화 : 파일을 저장하기 위한 계층 구조가 없고, 사용자가 정의한 메타 데이터를 정의 할 수 있다. 파일에 다양한 속성을 부여 할 수 있기 때문에 블록 스토리지에 비해서 최적화된 사용이 가능하다.

• S3는 이미지, 동영상, 오디오, 기타 모든 종류의 파일을 안전하게 저장하기 위한 공간을 제공한다.
• 오브젝트 스토리지다. 파일 단위로 업로드/다운로드 할 수 있다.
• 데이터는 여러 노드 혹은 데이터센터에 분산되서 저장하기 때문에 높은 가용성을 제공한다.
• 파일은 버킷(bucket)에 저장된다. 전체 시스템에서 유일한 저장 공간이다. 이 버킷에 폴더와 객체들이 저장된다.
• 파일하나는 0 Byte에서 최대 5TB의 크기를 가질 수 있다.
• S3는 단일한 universal namespace를 가진다. 따라서 파일이름은 글로벌하게 유일해야 한다. 따라서 디렉토리 역할을 하는 버킷 이름은 전체 AWS S3 시스템에서 유일해야 한다. 디렉토리 이름을 "company"등으로 하면 (이미 존재할 것이기 때문에)에러가 발생할 것이다.
• 버킷이름은 DNS 이름으로 접근 할 수 있다. 버킷이름을 joinc로 했다면 이 버킷의 주소는 https://<버킷이름>.s3.<region>.amazonaws.com 이 된다. 예를 들어 서울리전(ap-northeast-02)에 joinc 라는 버킷을 만들었다면, 버킷의 도메인 주소는 https://joinc.s3.ap-northeast-02.amazonaws.com 이 된다.

버킷이름은 AWS 상에서 유일해야 하기 때문에 서비스 도메이름, 단계(dev, stage, product)등을 섞어서 만든다. 예를들어 joinc wiki 서비스를 개발중이고 dev 단계에 s3 bucket을 제공해야 한다면 joinc-wiki-dev 와 같이 이름을 만들어야 할 것이다.

S3는 HTTP를 이용해서 접근 할 수 있다. S3로의 파일업로드가 성공하면 HTTP 200코드를 받을 것이다. 파일이 없어서 파일 다운로드에 실패 할 경우 HTTP 404코드를 받을 것이다. HTTP를 이용한 서비스이기 때문에 웹 서비스와 부드럽게 통합할 수 있다.

S3 오브젝트은 아래의 정보들로 구성된다.

1. Key : 오브젝트의 이름.
2. Value : 바이트(bytes)로 이루어진 오브젝트의 값. 파일의 내용이라고 보면 된다.
3. Version ID : 파일의 버전.
4. Metadata : 오브젝트에 대한 Key-Value 방식으로 추가적인 정보를 입력 할 수 있다.
5. Subresources : 접근제어와 같은 추가적인 정보들을 포함한다.

Amazon S3는 오브젝트별로 멀티플버전(multiple versions)을 사용 할 수 있다. my-site.jpg 버전 1.0이 있다고 가정해보자. 여기에 my-site.jpg를 다시 올리면 my-site.jpg 버전 1.1이 만들어진다. S3는 각 버전별로 오브젝트를 보관하고 있기 때문에 잘못된 덮어쓰기에 따른 데이터의 복구, 수정내용의 확인등의 작업을 쉽게 수행 할 수 있다.

개발자는 버킷 별로 객체를 관리하는데, 보통 폴더 구조를 만들어서 객체들을 그룹핑한다. 버킷의 이름이 myService이고 사진과 PDF 문서를 관리한다면 아래와 같은 구조가 만들어진다.

• 버킷 : myService 라는 저장공간을 만들었다.
• Prefix : 버킷이름을 제외한 객체까지 도달하는 폴더의 경로다. pdf, photo/me, photo/friend 등이다.
• 객체 : hello.pdf, kafak.pdf 등 객체의 key 이름이다.

동시에 두 개 이상의 애플리케이션이 데이터에 접근 할 경우, 일관성이 중요한 문제가 될 수 있다. 내가 데이터를 쓰고 있을 때 다른 사용자가 데이터를 쓰거나, 내가 데이터를 쓰고 있을 때 다른 사용자가 데이터를 읽을 때, 데이터의 일관성 모델에 따라서 읽는 값이 달라질 수 있기 때문이다.

Amazon S3는 여러 데이터센터에 객체를 복제함으로써 고가용성을 구현한다. 기본적으로 PUT 요청이 성공하면 데이터가 안전하게 저장되지만 객체의 변경사항을 다른 데이터 센터로 복제하는데 시간이 걸리기 때문에 아래의 현상이 관찰될 수 있다.

1. 프로세스가 Amazon S3 버킷에 객체를 쓰고 키를 바로 출력한다. 하지만 변경사항이 모두 전파 될 때까지 해당 객체가 목록에 나타나지 않을 수 있다.
2. 프로세스가 객체에 업데이트를 수행하고 바로 읽기를 수행한다. 변경사항이 완전히 전파될 때까지 S3는 이전 객체를 반환할 수 있다.
3. 프로세스가 객체를 삭제한 뒤에 바로 읽기를 수행한다. 변경사항이 전파될 때까지 삭제된 객체를 반환할 수 있다.
4. 프로세스가 객체를 삭제한 뒤에 키를 바로 출력한다. 변경사항이 전파될 때까지 삭제된 객체가 나열될 수 있다.

아래의 시나리오를 보자.

• PUT /photo/hello.jpg 200 OK
• GET /photo/hello.jpg 200 OK

객체의 쓰기(업로드)를 성공하고 (잠시후) 읽기도 성공했다. 이 시나리오는 read-after-write consistency 를 만족하는 최상의 시나리오다. 하지만 실제는 전파시간 때문에 아래와 같은 사건이 발생 할 수 있다.

• PUT /photo/hello.jpg 200 OK
• GET /photo/hello.jpg 404 NOT FOUND

PUT이 성공한 뒤에 GET을 했는데, 404 NOT FOUND가 떨어졌다. 변경사항이 전파되지 않아서 발생한 사건이다. 이 사건은 시간에 따라서 달라질 수 있다.

아래의 시나리오를 보자.

• PUT /photo/hello.jpg 200 OK
• PUT /photo/hello.jpg 200 OK (새로운 컨텐츠)
• GET /photo/hello.jpg 200 OK

첫번째 객체를 PUT 한 다음에, 객체를 업데이트 했다. 그 뒤에 GET으로 객체를 요청했는데 첫번째 컨텐츠가 반환될 수도 있고, 두번째 컨텐츠가 반환될 수도 있다. 객체 전파시간이 걸리기 때문이며 역시 시간에 따라서 결과가 달라질 것이다. 일정시간이 지나면 두번째 컨텐츠가 반환될 확률이 높을 것이다. 객체는 전파가 완료될 때까지 그대로 유지된다.

마지막 시나리오다.

• GET /photo/hello.jpg 404 NOT FOUND
• PUT /photo/hello.jpg 200 OK
• GET /photo/hello.jpg 404 NOT FOUND

역시 전파시간이 이유가 되는 시나리오다. PUT 요청에 의한 객체전파가 완료되기 전까지 404 NOT FOUND가 발생한다.

최종 일관성(eventual consistency) 혹은 궁극적 일관성은 분산 컴퓨팅에 쓰이는 일관성 모델의 하나다. 데이터 항목에 업데이트가 없으면 궁극적으로 해당 항목에 대한 모든 접근들은 마지막으로 업데이트된 값을 반환하는 것을 보장하는 고가용성을 말한다.

라고 설명하고 있는데, 솔직히 이게 무슨 말인가 싶다. 이를 이해하려면 분산시스템에서의 동시성을 생각해볼 필요가 있다.

기존의 관계형데이터베이스에서 "동시성"은 같은 시간에 조회하는 데이터는 항상 동일한 데이터임을 보증한다. 하지만 데이터가 분산저장되는 많은 NoSQL들에서는 "분산"이라는 물리적인 제약 때문에 동시성을 보장하기가 힘들어진다. 분산된 각 노드에 데이터가 전파되는데 시간이 걸리기 때문이다. 결국 동시성을 제공하지는 않지만 결과적으로는(최종적으로) 일관성을 가지게 되는게 최종 일관성이다.

솔직히 말장난 같다는 생각이 든다. 그냥 시간이 지나면 결과적으로 원하는 입력/출력 결과를 얻을 수 있는 모델이라고 보면 된다.

우리는 스토리지를 다양한 목적으로 사용한다. 일반 사용자를 대상으로 하는 파일과 로그파일, 데이터 분석을 위해서 저장한 파일들은 각각의 특징을 가진다. 예를 들어 사용자를 대상으로 하는 파일은 빈번한 쓰기와 읽기에 최적화된 스토리지를 사용해야 할 것이다. 로그 데이터는 쓰기는 많지만 읽기는 그다지 많지 않을 것이다. 데이터 분석을 위해 저정한 파일은 읽기와 쓰기가 그다지 많지 않을 것이다. 로그 데이터의 경우 처음에는 높은 쓰기 성능을 보장하는 스토리지를 사용하고, 일정시간이 지나면 테이프 백업 장치나 저 성능의 디스크로 옮겨서 보관하는 식으로 사용 특성이 변경될 것이다.

인프라 관리자는 데이터의 특성에 따라서 적당한 스토리지를 사용해야 할 것이다. 적당한 스토리지의 선택은 서비스의 성능과 비용에 직접적인 영향을 미치는 중요한 요소다.

(2020년 10월) 현재 S3는 6개의 클래스를 제공한다.

• S3 Standard : 자주 접근하는 데이터를 위한 높은 내구성, 가용성 짧은 지연시간과 대량의 처리량을 제공한다. 따라서 동적 웹 사이트, 컨텐츠배포, 빅데이터 분석등의 다양한 사례에 사용할 수 있다.
• S3 Intelligent-Tiering : 빈번한 요청을 처리하하기 위한 계층과 빈번하지 않은 요청을 처리하는 두 개의 계층으로 구성된다. 각 오브젝트는 요청에 맞게 자동으로 최적화 된다. AWS는 객체의 액세스 패턴을 모니터링 하다가 30일 동안 액세스하지 않은 객체를 빈번하지 않은 접근계층으로 이동한다.
• S3 Standard-Infrequent Access(S3 Standard IA): 자주 액세스하지 않지만 필요할 때 빠르게 액세스해야 하는 데이터에 적합하다. 장기 스토리지, 백업 및 복구 파일용 데이터스토어에 이상적이다.
• S3 One Zone-Infrequent Access(S3 One Zone-IA) : 자주 액세스하지 않지만 필요할 때 빠르게 액세스해야 하는 데이터에 적합하다. 최소 3개의 가용영역에 데이터를 저장하는 다른 S3 클래스와는 달리 단일 AZ에 데이터를 저장한다. 가용성이 떨어지며(다른 클래서의 가용성은 연간 99.9%인 반면 One Zone-IA는 99.5%다.), 가격역시 20% 만큼 저렴하다. 이 클래스는 온-프레미스에서 데이털르 다시 생성할 수 있을 경우, 데이터의 보조백업을 위해서 사용 할 수 있다.
• S3 Glacier : 데이터 보관을 목적으로 하는 저렴한 스토리지 클래스다.
• S3 Glacier Deep Archive : Amazon S3에서 가장 저렴한 클래스다. 일년에 몇 번 정도 접근하는 데이터의 장기 보관목적에 적합하다. 은행등의 경우 규제요구사항을 충족하기 위해서 7~10년 동안 데이터를 보관해야 할 수 있다. 온-프레미스는 이런 데이터를 자기 테이프에 저장하고는 하는데, Glacier Deep Archive는 이에 대한 대안으로 사용 할 수 있다.

S3 Glacier과 S3 Glacier Deep Archive는 Archive 목적으로 사용한다.

아래 S3 클래스의 성능 챠트를 참고하자.

	S3 Standard	S3 Intelligent-Tiering	S3 Standard-IA	S3 One Zone-IA	S3 Glacier	S3 Glacier Deep Archive
내구성	99.999999999%	99.999999999%	99.999999999%	99.999999999%	99.999999999%	99.999999999%
가용성	99.99%	99.9%	99.9%	99.5%	99.99%	99.99%
가용성 SLA	99.9%	99%	99%	99%	99.9%	99.9%
가용 영역	≥3	≥3	≥3	1	≥3	≥3
객체당 최소용량 요금	해당사항없음	해당사항없음	128KB	128KB	40KB	40KB
최소 스토리지 기간 요금	해당사항없음	30일	30일	30일	90일	180일
검색요금	해당사항없음	해당사항없음	검색한 GB당	검색한 GB당	검색한 GB당	검색한 GB당
첫 번째 바이트 지연시간	밀리초	밀리초	밀리초	밀리초	분 또는 시간 선택	시간 선택
수명 주기 전환	예	예	예	예	예	예

S3 스토어에 있는 모든 객체는 버전을 가지고 있다. 객체에 버전을 설정하면, 수정된 객체를 올릴 때 이전 버전의 객체를 그대로 두고 새로운 버전의 객체가 추가된다. 따라서 버전관리 기능을 강력한 백업및 감사 목적으로 사용 할 수 있다. 버전 기능은 한번 활성화하면 비활성화(disabled) 할 수 없다. 버전기능은 S3 객체의 수명주기(lifecycle)와 통합 할 수 있다. 예를 들어 최신 버전의 파일은 1달 후에 Glacier로 전환하고, 이전 버전의 파일은 3달 후에 Glacier Deep Archive로 전환 후 3년뒤에 삭제하라는 식으로 설정할 수 있다.

버전 기능을 활성화한 상태에서는 MFA(Multi-factor authentication) Delete를 설정 할 수 있다. MFA Delete 가 설정된 버킷의 객체를 삭제할 경우 HTTPS 요청에 x-amz-mfa 헤더에 MFA 값을 전송해야 한다. 이 헤더의 값은 "MFA 디바이스의 일련번호"와 "6자리의 인증코드"로 구성된다. 이 헤더가 포함되어 있지 않거나 값이 일치하지 않을 경우 요청은 실패한다. 데이터를 극히 안전하게 관리 할 수 있다. 아래는 MFA Delete 설정된 객체에 대한 DELETE 요청이다.

버전 컨트롤 기능을 테스트하기 위해서 버킷을 하나 만들었다.

• Bucket name : awscertification
• Region : Asia Pacific (Seoul)

버킷이름과 리전을 설정하고 나면, properties설정화면이 나오는데, 지금은 무시하고 기본 값으로 버킷을 만들기로 했다.

현재 만들어진 버킷이다. S3 버킷은 기본 not public상태로 만들어진다. 먼저 버킷을 public상태로 만들자.

작업할 버킷을 선택한 다음 Edit public access settings를 클릭하면 아래와 같이 public access settings 화면이 실행된다. 지금은 "Block all public access"가 체크된 상태일 거다. 체크를 풀면 public 상태가 된다.

awscertfication 버킷을 클릭하면 아래와 같이 버킷 상세정보들이 출력된다.

Properties, Permissions, Management 3개의 카테고리가 보인다. properties를 다룰 것이다. 지금은 모든 properties 들이 Disabled 상태다. Properties 를 클릭하자.

설정 할 수 있는 Properties 메뉴가 출력된다. Versioning를 클릭해서 versioning 기능을 활성화 할 수 있다.

이제 파일을 업로드해보자. 테스트를 위해서 간단한 text 파일을 만들었다. 파일의 이름은 hello.txt 다.

파일을 업로드하자.

파일 정보는 대략 아래와 같이 보일 것이다.

파일 내용을 아래와 같이 수정하고 업로드 했다. AWS 콘솔은 기본적으로 가장 최근의 파일만 보여준다. Versions > Show 를 선택하자.

모든 버전의 파일을 확인 할 수 있다. hello.txt 내용을 수정해서 버전을 몇개 더 만들어보자. 나는 Latest version 포함 총 3개의 파일을 만들었다. Versions > Hide 상태에서 Latest version 파일을 삭제해보자. Empty 상태로 보이지만 versions > Show를 선택하면 아래와 같이 보일 것이다.

Version 기능을 사용하는 파일은 삭제 할 경우 "delete marker" 처리 될 뿐 실제 지워지지 않는다. 반면 Version > Show 상태에서, 파일을 삭제하면 해당 버전의 파일이 완전히 삭제된다.

정리해보자.

• Version 기능을 사용 할 경우 S3는 현재 객체를 포함한 이전의 객체 모두를 저장한다. 삭제한 객체도 여전히 보관한다.
• Version은 백업 툴로 사용 할 수 있다.
• Version 기능을 활성화 하면 disabled 할 수 없다. Suspended만 가능하다.
• Version 기능과 Lifecycle rules를 결합할 수 있다. 예를 들어 이전 객체의 버전은 Glacier 클래스 스토리지에 저장하고 100일이 지난후 Glacier 스토리지에서 삭제하는 규칙을 만들 수 있다.
• Version MFA Delete 기능을 이용해서 저장된 파일에 대한 추가적인 보호장치를 마련 할 수 있다.

만들어진 S3 객체는 생성 -> 전환 -> 소멸의 과정을 거친다. 전환과 소멸의 과정을 거치는 이유는 아래와 같다.

• 비용 : 시간이 지나서 잘 사용하지 않는 (예를 들어 로그 같은)객체를 값 비싼 Standard 클래스에 저장 할 필요가 없다. 사용 목적에 맞게 클래스를 전환할 필요가 있다.
• 보안 : 더 이상 사용 할 필요가 없는 객체는 삭제해줘야 한다. 어떤 (개인정보 같은)정보들은 규제에의해서 일정시간 보관 후 삭제해야 한다. 물론 비용 절약 목적도 달성할 수 있다.

아래는 객체 수명 주기를 구성해야 하는 시나리오다.

• 버킷에 파일을 주기적으로 업로드 할 경우, 초기 한달은 자주 사용해야 한다. 하지만 그 이후에는 삭제해야 한다.
• 특정 기간동안 실시간으로 자주 액세스되는 문서가 있다. 그 이후에는 가끔 액세스되며 실시간성이 중요하지 않다.
• 금융 및 의료 기록, 염기서열 데이터, 디지털 미디어, 개인정보 등은 규제 준수를 위해서 일정시간 보관해야 한다.

awscertification 버킷으로 테스트를 진행한다. Management > lifecycle에서 lifecyle 룰을 관리 할 수 있다.

• Enter a rule name : Rule 이름
• Choose a rule scope : 룰을 적용할 범위를 설정 할 수 있다. Limit the scope the specific prefix or tags를 선택하면 prefix와 tag를 필터링해서 룰을 적용한다. Apply to all object in the bucket을 선택하면 전체 버킷에 적용된다.

Apply to all object in the bucket scope를 선택했다.

storage class transition에서 클래스 전환할 버전을 선택한다. Current version과 Previous version 단위로 룰을 설정 할 수 있다. 나는 Previous versions에 대해서 룰을 만들기로 했다.

"Add transition" 기능으로 상세전환룰을 선택 할 수 있다. Add transition은 하나 이상 추가 할 수 있다. 나는 30일 이후에 Glacier로 전환하고 180일 이후에 Glacier Deep Archive로 전환하도록 설정했다.

s3 객체의 삭제룰을 설정한다.

• Current version과 Previous version : 현재 버전과 이전 버전에 대한 룰을 만든다.
• Permanently delete previous versions : 며칠 후(After day)에 파일을 완전히(permanently) 삭제할지를 설정한다.
• Clean up expired object delete markers : 파일을 삭제하면 영구히 삭제되는게 아니고 삭제표시(delete markers)만 한다. 이 옵션을 체크하면 삭제표시된 만료일이 지난 객체를 삭제한다.

우리가 만든 객체 수명 주기를 검토 할 수 있다.

• 현재 버전은 만료시간(Expire)만 설정
• 이전 버전에 대해서는 Clacier -> Glacier Deep Archive -> Permanently Delete