메뉴

문서정보

목차

S3 소개

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 오브젝트라고 하면 헷갈릴 수 있는데 오브젝트 == 파일(+메타정보)이라고 접근하기 편할 것이다.

Object Storage vs Block Storage

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

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

S3의 특징

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

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

S3 오브젝트의 구성

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는 각 버전별로 오브젝트를 보관하고 있기 때문에 잘못된 덮어쓰기에 따른 데이터의 복구, 수정내용의 확인등의 작업을 쉽게 수행 할 수 있다.

버킷, Prefix, 객체

개발자는 버킷 별로 객체를 관리하는데, 보통 폴더 구조를 만들어서 객체들을 그룹핑한다. 버킷의 이름이 myService이고 사진과 PDF 문서를 관리한다면 아래와 같은 구조가 만들어진다.
 --+-- myService --+-- pdf ----+-- hello.pdf
                   |           |
                   |           +-- kafka.pdf
                   |
                   +-- photo --+-- me ------+-- 1.jpg
                               |            |
                               |            +-- go.jpg
                               |
                               +-- friend --+-- dream.jpg 

일관성(consistent) 모델

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

Amazon S3는 여러 데이터센터에 객체를 복제함으로써 고가용성을 구현한다. 기본적으로 PUT 요청이 성공하면 데이터가 안전하게 저장되지만 객체의 변경사항을 다른 데이터 센터로 복제하는데 시간이 걸리기 때문에 아래의 현상이 관찰될 수 있다.
  1. 프로세스가 Amazon S3 버킷에 객체를 쓰고 키를 바로 출력한다. 하지만 변경사항이 모두 전파 될 때까지 해당 객체가 목록에 나타나지 않을 수 있다.
  2. 프로세스가 객체에 업데이트를 수행하고 바로 읽기를 수행한다. 변경사항이 완전히 전파될 때까지 S3는 이전 객체를 반환할 수 있다.
  3. 프로세스가 객체를 삭제한 뒤에 바로 읽기를 수행한다. 변경사항이 전파될 때까지 삭제된 객체를 반환할 수 있다.
  4. 프로세스가 객체를 삭제한 뒤에 키를 바로 출력한다. 변경사항이 전파될 때까지 삭제된 객체가 나열될 수 있다.
아래의 시나리오를 보자. 객체의 쓰기(업로드)를 성공하고 (잠시후) 읽기도 성공했다. 이 시나리오는 read-after-write consistency 를 만족하는 최상의 시나리오다. 하지만 실제는 전파시간 때문에 아래와 같은 사건이 발생 할 수 있다. PUT이 성공한 뒤에 GET을 했는데, 404 NOT FOUND가 떨어졌다. 변경사항이 전파되지 않아서 발생한 사건이다. 이 사건은 시간에 따라서 달라질 수 있다.

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

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

최종 일관성

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

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

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

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

S3 Storage class

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

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

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

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 버전 컨트롤

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 요청이다.
DELETE /my-image.jpg?versionId=3HL4kqCxf3vjVBH40Nrjfkd HTTPS/1.1
Host: bucketName.s3.amazonaws.com
x-amz-mfa: 20899872 301749
Date: Wed, 28 Oct 2009 22:32:00 GMT
Authorization: AWS AKIAIOSFODNN7EXAMPLE:0RQf4/cRonhpaBX5sCYVf1bNRuU=

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

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

 S3 버킷 내용

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

 s3 버킷 퍼블릭으로 만들기

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

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

 s3 버킷상세정보

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

 s3 properties 상세

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

 s3 properties versioning 설정

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

파일을 업로드하자.

 S3 파일 업로드

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

 s3 file upload

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

 S3 file version

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

 s3 version file delete

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

정리해보자.

S3 객체 수명주기 관리

만들어진 S3 객체는 생성 -> 전환 -> 소멸의 과정을 거친다. 전환과 소멸의 과정을 거치는 이유는 아래와 같다. 아래는 객체 수명 주기를 구성해야 하는 시나리오다. awscertification 버킷으로 테스트를 진행한다. Management > lifecycle에서 lifecyle 룰을 관리 할 수 있다.

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

 s3 storage class transiton

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

 s3 lifecycle

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

 s3 lifecycle

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

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