[AWS] S3란? 무제한으로 저장할 수 있는 스토리지!

<참고>

https://acstory.tistory.com/33

[AWS] S3란? 무제한으로 저장할 수 있는 스토리지!

 

한마디로 요약하면 S3는 "높은 내구성"과 "높은 가용성"을 "저렴한 가격"으로 제공하는 "인터넷 스토리지 서비스" 이다.

 

 

하나의 저장 공간을 구성하고 그 공간에 데이터를 업로드하면 인터넷을 통해 해당 파일을 자유롭게 다운로드할 수 가 있다. 물론 데이터를 업로드하고 다운로드하는 주체는 일반 인터넷 사용자가 될 수도 있고, 다른 AWS 서비스 또는 사용자의 어플리케이션이 될 수도 있다.

 

 

 

1-1 Object Storage, 그리고 S3

S3의 가장 큰 특성, 다시 말해 높은 내구성과 가용성을 설명하기 위해서는 객체 스토리지(Object Strage)가 어떤 방식으로 설계되었는지부터 이해할 필요가 있다.

 

 

 

 

일반 Strage 예시

 

 

 

일반적인 스토리지부터 생각해보자. 

 

 

한 사용자가 데이터를 새로 저장(업로드)하고, 또 다른 사용자가 해당 데이터를 다운로드 한다. 

 

시간이 지나 수명이 다했거나 물리적인 손상으로 인해 해당하는 데이터가 있는 영역이 손상되었다. 

 

 

이제 이 공간이 놓인 데이터는 내구성이 손상되었으며, 사용할 수 없게 되었으므로 가용성 또한 훼손되었다

 

 물리적인 저장 공간을 어떤 소재로 어떻게 설계했느냐에 따라 손상될 확률에는 차이가 있을 수 있지만, 

 

물리 장비의 한계상 결국 언젠가는 데이터의 내구성과 가용성에 문제가 생길 수 밖에 없다.

 

 

 

 

 

 

그래서 이런 물리적인 한계를 논리적인 방식으로 극복하고자 한 구성이 "객체 스토리지"이다. 

 

객체 스토리지는 기본적으론 내부 복제를 전제로 한다. (물론 내부 복제는 객체 스토리지만의 고유 특징은 아니다.) 

 

하나의 단위 객체가 업로드되면 자동저긍로 내부의 여러 위치에 복제본을 생성한다. 

 

S3의 경우 동일 Region 내의 여러 AZ에 걸쳐 복제본을 생성한다.

 

 

Object Strage 예시

 

 

 

 

내부적으로 복제가 수행되면, 어느 한 객체에 손상이 발생하더라도 손상되지 않은 복제본이 있기 때문에 내구성이 비약적으로 상승한다. 

 

예를 들어, 하나의 객체가 손상될 확률이 10%고, 원본을 포함해 총 세 개의 복제본을 생성했다면 모든 객체가 손상될 확률은

10%*10%*10% = 0.1%가 된다.

 

 가용성 또한 향상된다. 복제본도 원본과 동일하게 실제 다운로드 요청에 응답하는데 사용되기 때문이다.

 

하지만 객체 스토리지 방식이 무조건 장점만 있는 것은 아니다. 

 

내부 복제에는 일정한 시간이 소요되기 때문에, 내부 복제가 모두 완료(Fully Propagated)되기 이전에는 각기 다른 객체의 위치에서 응답하므로 사용자별로 일관되지 않은 응답이 발생할 수 있다.

 

 

※ 새로 쓰기(Create)의 경우, 일부 요청에 객체 목록이 표시되지 않거나

※ 덮어 쓰기(Overwrtie)의 경우, 일부 요청에 이전 버전의 객체를 응답하거나

※ 삭제(Delete)의 경우, 일부 요청에 삭제되기 전의 객체가 표시되거나 응답할 수 있다.

 

 

Eventual Consistency

 

 

물론 이러한 현상을 일시적인 것이며, 일정 시간(수초 이내)이 지난 후에는 내부 복제가 모두 완료되어 비로서 모든 사용자에게 일관된 응답을 제공하게 된다. 

 

이것을 Eventual Consistency(최종 일관성)를 제공한다고 말하며, 이는 객체 스토리지의 특성이자 S3의 특성이 된다.

 

 

 

객체 스토리지 및 S3가 공통적으로 갖고 있는 기타 특성은 다음과 같다.

 

※ 객체의 생성(Create) 및 삭제(Delete)만 지원한다. 수정(Update/Modify) 작업은 지원하지 않는다.

덮어 쓰기도 가능하지만 이는 내부적으로 수정 처리하는 것이 아니라 동일한 경로에 재생성하는 방식이다.

 

 

※ 객체 데이터와 관련된 각종 부가정보(날짜, 사용자정보, 기타)는 객체 데이터 외부에 별도로 저장하여 관리한다.

이러한 부가정보를 Metadata라고 부르며 "Key-Value" 형태로 항목을 자유롭게 추가하여 관리할 수 있다.

 

※ 각 객체의 주소값은 글로벌하게 고유해야 한다. 사용자가 인터넷을 통해 단위 객체에 접근하기 때문이다. S3의 경우 버킷명+키값+(버전ID)로 각 객체를 구분한다.

 

※ HTTP(S) 프로토콜을 사용하여 업로드/다운로드를 수행할 수 있다.

 

 

S3는 AWS에서 제공하는 고가용성, 고내구성의 객체 스토리지 서비스이다. S3는 DB와 같이 데이터 수정이 빈번한 입출력 형태보다는, 객체(파일) 단위로 데이터를 한 번 저장하고 이 후에 다운로드가 많은 형태에 적합한 스토리지이다.

 

 

 

1-2 Bucket과 Object

 

 

S3에는 버킷(Bucket)과 객체(Object)로 불리는 단위가 있다.

비유하면 객체는 파일 및 파일정보(Data and Metadata)로 구성된 저장 단위, 

 

버킷은 다수의 객체를 통합하여 저장/관리/제어하는 일종의 바구니(Container)라고 생각하면 쉽다.

 

이 바구니를 생성한 AWS 계정은 버킷의 소유자(Owner)가 되며, 

 

이 소유자는 버킷 단위로 각종 기능을 활성화/비활성화하거나 버킷 내 객체의 접근제어 정책을 관리할 수 있다.

 

 

Bucket과 Object

 

 

 

 

버킷(Bucket)을 생성할 때는 버킷의 이름과 버킷이 위치할 Region을 선택한다. 

이 때 버킷의 이름은 전 세계적으로(즉, 모든 AWSㄱ 계정, 모든 Region에 걸쳐) 고유(Unique)해야 한다.

 

다시 말해, 이미 특정 이름의 버킷명을 한 사용자가 사용 중이라면 다른 사용자는 동일한 이름의 버킷을 생성할 수 없다.

 

 

버킷명은 이후 인터넷을 통해 객체를 호출할 때 주소값의 가장 앞에 위치하며, 

버킷명이 고유하므로 버킷명을 포함한 객체 주소도 글로벌하게 고유한 주소값을 갖는다.

 

 

여기서 잠깐 Q&A Q. 하나의 S3 버킷단위로 초당 최대 요청 수 (GET/PUT/LIST/DELETE)가 정해져 있다고 하는데, 주어진 조건 내에서 최대한의 성능을 뽑아내려면 어떻게 해야 하나요? A. 정확히 수치화할 수는 없지만, 버킷 단위로 초당 몇백 건 정도의 요청을 처리할 수 있는 제한값이 존재하며 해당 갑싱 초과되면 요청에 대한 정상적인 응답을 반환하지 못할 수 있다. S3 내부적으로는 저장 공간이 일정한 파티션 단위로 분리되어 있으며, 단위 객체를 어떤 파티션에 저장할지 여부는 버킷 하위의 객체 주소값이 결정한다. 다시 말해 하나의 버킷이있다면 이 버킷은 일정한 성능 제한값을 갖고 있다. 하나의 버킷 내에서 요청이 파티션별로 최대한 분산되도록 유도하려면 객체의 주소값 또한 최대한 분산되도록 설계해야 한다. (예를 들어, /20001110, /20001112 이런식의 순차구조가 아니라 /FOAQ, /01AG 이런 형태로 분산되도록) S3 앞에 CloudFront같은 Cache Layer를 구성하여 캐싱을 통해 S3로 직접 들어오는 요청 부하를 줄이는 방법도 있다.

 

 

 

1-3 S3의 접근제어

S3는 두 가지 범주의 작업(Operation)이 있다.

 

◆ Bucket Operation : 버킷 생성, 버킷 삭제, 버킷 속성변경 등 버킷 단위의 작업

◆ Object Operation : 객체 생성, 객체 삭제, 객체 다운로드 등 객체 단위의 작업

 

그리고 이러한 두 가지 범주의 작업을 제어하는 권한계층에는 다음의 세 가지가 있다.

 

 

S3 권한계층의 세 가지 종류

 

 

 

 

우선 Bucket ACL과 Object ACL은 XML 형식으로 접근권한을 정의한다. 

Bucket ACL은 버킷 단위 작업의 권한을 Object ACL은 객체 단위 작업의 권한을 제어한다. 

 

예전 제어 방식이며, 여러 제약사항으로 인해 사용을 권장하지 않는다.

 

Bucket Policy는 JSON 형식으로 접근권한을 정의한다. 

버킷 단위 작업과 객체 단위 작업을 모두 정의할 수 있으며, 정의하는 권한범위 또한 제한이 없다.

 따라서 S3와 관련된 접근정책은 가급적 Bucket Policy를 통해 제어하는 것을 권장한다.

 

 

여기서 잠깐 Q&A Q. S3측에서 접근제어를 설정하는 방법은 Bucket/Object ACL, Bucket Policy가 있다는 건  알겠습니다. 반면 IAM Policy에서도 S3 관련 권한(특정 버킷이나 객체를 대상으로)을 사용자 측면에서 정의하는 것으로 알고 있습니다. 이 두 가지 정책이 충돌했을 때 어떻게 해석되는지 알고 싶습니다. A. 그렇다. IAM 측에서도 S3 관련 권한을 정의한다. 즉 S3와 관련된 접근제어를 정의하는 계층은 IAM (Object/Bucket)ACL, Bucket Policy 세 개가 있는 셈이다. 일반적으로 허용 정책은 미설정에 우선하며, 거부 정책은 허용 정책에 우선하낟. 즉 IAM Policy에서 허용 정책을 정의하고 Bucket Policy에서 허용 정책을 설정한 경우 허용, 둘 중 하나라도 거부 정책이 있을 경우 거부 처리 된다.

 

 

1-4 S3의 Storage Class

S3는 여러 가지 종류의 Storage Class를 제공한다. 

 

그리고 이 Storage Class는 버킷 단위로 고정된 것이 아니며, 

동일한 버킷 내에서도 각 객체별로 다른 Storage Class를 선택하여 저장할 수 있다.

 

 S3에서 제공하는 Storage Class는 총 네 가지가 있으며,

 각 Class별로 보장하는 내구성과 가용성, SLA(Service Level Agreement: 서비스 수준 계약) 기준이 다르다.

 

S3에서 제공하는 Storage Class

 

저장 용량에 대한 단가는 위 표를 따르지만, Class별로 과금 요소가 다르기 때문에 

단순히 어느 것이 가장 비싸고 싸다는 개념은 아니다. 

 

예를 들어, Standard-IA의 경우 객체별로 과금되는 최소 용량단위가 있으며, 

데이터 복구 시 추가 요금이 발생한다. 

 

Glacier 또한 백업 용도의 Storage Class로 실제 데이터를 불러오는데 

 

추가 시간과 비용이 발생하므로 요청 즉시 응답하는 다른 Storage Class와는 성격과 용도가 다르다.