[3장] Amazon Simple Storage Service와 Amazon Glacier Storage

3장에서는

S3 객체 저장, 관리, 액세스

내구성 가용성 비용에 균형을 맞춘 스토리지 클래스 선택

Amazon Glacier를 설계에 통합해 맞춘 스토리지 클래스 선택

데이터 저장과 액세스에 사용할수 있는 다른 AWS 서비스 

 

S3 는 

S3는 개인 어플리케이션 다수 AWS 서비스의 데이터를 보관하며 다음 워크로드를 위한 플랫폼 이다. 

 

- 백업 아카이브 로그파일 재해복구 이미지 유지 관리 

- 분석을 위한 빅데이터 저장

- 정적 웹사이트 호스팅 

 

S3는 필요에 따라 AWS 내 외부에서 실행되는 작업에 밀접하게 통합할 수 있는 저렴하고 안정성 있는 스토리지를 제공하며 2장에서 다룬 운영체제 볼륨과는 다르다. 

 

운영체제 볼륨은 블록 스토리지에 저장돼 EC2 인스턴스를 구동하는 반면 S3는 무제한 객체 스토리지 공간을 효과적으로 제공한다. 

 

객체 스토리지와 블록 스토리지는 어떻게 다를까?

 

먼저 블록 스토리지는 물리적 디스크를 개별 블록으로 나눠 데이터를 저장하고 파일시스템으로 관리한다. 보통 Windows에서는 NTFS를 파일 시스템으로 사용하고 Linux는 ext4를 사용한다. 파일 시스템은 설치된 OS를 대신해서 기반 장치에 저장되는 파일과 데이터를 위해 공간을 할당하고 OS가 읽을 때마다 액세스 할 수 있게한다. 

 

반면 S3 와 같은 객체 스토리지 시스템은 구조화 되지 않은 평면 저장소에 데이터를 저장한다. 이렇게 단순하게 설계됨으로써 운영체제에 연결된 블록스토리지의 복잡함은 피하면서 전문적으로 설계되고 유지 관리되는 무제한스토리지 용량에 누구나 쉽게 액세스 한다. S3에 파일을 쓸때 최대 2KB 메타데이터가 함께 저장된다. 

메타데이터는 시스템 세부 정보를 구성하는 키로 만들어지는데, 시스템 세부 정보는 데이터 사용 권한과 파일 시스템 처럼 보여지는 중첩 버킷 내 위치 정보 같은 것들이다. 

 

S3 서비스 아키텍처

S3 파일은 버킷으로 구성되며, AWS 계정당 기본으로 만들 수 있는 버킷은 100개 다. 

 

다른 AWS 서비스와 마찬가지로 AWS에 할당량 증가를 요청할 수 있다. S3 버킷과 그 내용은 한 AWS 리전에만 존재하고 버킷 주소는 전체 S3 글로벌 시스탬 내에서 유일해야한다. 여기에는 이유가 있다. 운영이나 규정 요구사항을 충족하기 위해 데이터는 특정 리전에 있는 리전에 배치하지만, 한편으로 버킷 주소만으로 버킷에 엑세스 할 수 있도록 프로세스를 단순하게 만들기 위해서다. 

 

한 리전 2 에 위치한 버킨 bucketname의 파일 filename에 HTTP로 액세스 하는데 사용할 url은 다음과 같다. 

 

https://bucketname.s3.ap-northest-2.amazonaws.com/filename

 

주소를 통해 객체에 액세스 하려면 액세스 권한이 부여되어 있어야 한다. AWS CLI 를 사용해서 위 파일에 액세스 하는 주소는 다음과 같다. 

 

s3://bucketname/filename 

 

접두사와 구분 기호 

앞서 설명한 바와같이 S3버킷은 하위 폴더 구조가 없는 평면 구조이며, 객체는이 버킷에 저장된다 그러나 접두사와 구분 기호를 사용해서 버킷을 더 체계적인 모습으로 나타낼 수 있다. 

 

일반 텍스트 문자열을 접두사로 사용해서 구조화된 수준을 표현한다. 예를 들어 contracts 다음에 구분기호 / 를 넣어서 파일을 버킷 내 그룹 안에 있는 파일처럼 보이게 한다. 

 

폴더 또는 디렉터리 구조로 객체를 업로드하면 S3는 이 구조를 버킷 내 실제 계층인 것 처럼 나타내고 자동으로 구분 기호를 빗금 문자로 처리해서 변환한다 콘솔이나 API로 S3객체를 확인할 때 마다 폴더와 흡사한 구조로 볼 수 있는 이유가 여기에 있다. 

 

대용량 객체 작업

이론적으로는 버킷에 무한대 용량을 데이터를 저장할 수 있지만 단일 객체의 크기는 5TB를 넘을 수 없고 한번에 업로드 할 수 있는 용량 크기는 최대 5GB다. 100MB 보다 큰 객체는 멀티 파트 업로드를 사용해서 데이터가 손실되거나 업로드가 중지되는 위험을 줄이는 것이 좋다 

 

멀티파트 업로드는 말 그대로 큰 객체를 여러 작은 부분으로 나눠서 S3 대상 위치에 하나씩 만들어 전송한다. 개별 부분을 전송하다 실패하면 그 부분만 다시 전송하기 때문에 다른 부분에는 영향을 미치지 않는다. 

AWS CLI 나 상위 수준에 있는 API에서는 멀티 파트 업로드가 자동으로 실행되지만, 하위 수준으로 API 작업할때는 객체를 수동으로 나눠야한다. 

 

API는 코드나 명령줄로 작업을 할수있는 프로그래밍 인터페이스를 말하며, AWS는 서비스를 관리하는 기본 방법으로 API를 사용한다. 수작업으로 S3에 올릴 때를 대비해 하위 수준 API를 제공하고 신속한 자동화 작업을 위해서 상위 수준 API를 제공한다. 

 

암호화 

웹 사이트와 같이 퍼블릭 액세스 하는 용도가 아니라면 S3에 저장할 데이터는 항상 암호화 해야한다. S3에 저장중인 데이터를 보호하기 위해서 암호화 키를 사용할 수 있고 S3에서 다른 위치로 전송하는 데이터를 보호하기 위해서 Amazon 암호화 API 엔드포인트 만을 사용할 수도 있다. 

 

저장중 데이터는 서버측 암호화나 클라이언트 측 암호화를 통해서 보호할 수 있다. 

 

서버측 암호화 

여기서 서버측 이라는 말은 S3 플랫폼을 의미한다. 데이터 객체를 암호화 해서 디스크에 저장하는 작업과 데이터를 가져올 때 적합한 인증으로 복호화하는 작업이 AWS에서 이루어진다. 아래와 같이 3가지 종류의 서버측 암호화가 있다. 

 

S3 가 관리하는 암호화키(SEE-S3)를 사용하면 AWS 가 자체 엔터프라이즈 표준 키를 사용해 암호화 복호화 프로세스의 모든 단계를 관리한다.  

 

AWS KMS -관리형 키를 사용하는 서버 측 암호화(SEE-KMS)를 사용하면 SSE-S3가 제공하는 기능에 더해 완벽한 키 사용 추적과 봉투키를 사용할 수 있다 AWS KMS 서비스에 자체 키를 가져와서 사용할 수도 있다. 

 

고객 제공 암호화 키에 의한 서버 측 암호화(SSE-C)는 고객이 S3에 제공한 자체 키로 객체를 암호화 한다. 

 

클라이언트 측 암호화 

S3로 데이터를 전송하기 전에 암호화 될 수 있다. AWS-KMS 관리형 고객 마스터키(KMS-CMK)를 사용하여 업로드 전에 고유키로 객체를 암호화 한다. 또한 S3 암호화 클라이언트에서 제공된 클라이언트 측 마스터 키를 사용할 수도 있다. 

 

복잡한 암호화 절차를 단순화 하기 때문에 서버측 암호화를 많이 이용하지만, 회사나 조직의 규정 또는 법 제한으로 암호화 키의 모든 권한을 가지고 있어야 할 수도 있다. 

 

로깅

S3 이벤트 추적을 로그 파일에 저장하는 기능은 처음엔 비활성화돼 있다. S3 버킷에서 일어나는 많은 활동을 로그 데이터로 만들어 모두 기록할 필요는 없기 때문이다. 

 

로깅을 활성화 할 때는 원본 버킷과 대상 버킷(로그를 저장할 버킷)을 지정해야한다. 하나의 대상 버킷에 여러 원본 버킷 로그를 저장햇을때 쉽게 식별할 수 있도록 구분기호와 접두사를 사용한다. 

 

S3 생성로그는 구성하면 잠시후 ㅏ음과 같은 작업 상세 항목이 기본으로 나타난다. 

 

요청자 계정과 IP 주소

원본 버킷의 이름

요청동작

요청 개시시간

응답상태 

 

S3 버킷은 CloudWatch나 CloudTrail 같은 다른 AWS 서비스가 로그 또는 다른 객체를 저장하는데에도 사용된다. 

 

S3 내구성과 가용성 

객체를 저장할 때 여러 S3 스토리지 클래스 중에서 선택할 수 있으며, 내구성(데이터가 손실되지 않을 확률), 가용성(객체가 사용 가능한 기간의 비율), 지출 가능 비용에 따라 선택한다. 

 

내구성

S3 는 내구성을 백분율로 측정한다. 예를 들면 대부분 S3클래스와 Glacier는 다음과 같이 99.9%의 내구성을 보장한다. 

 

즉 S3 Standard / Glacier 플랫폼에 저장한 데이터를 인프라 장애로 손실할 가능성은 거의 없다고 할 수 있다. 그렇다고 해서 중요한 데이터를 S3 한 버킷에만 저장해 놓는 것도 권장할만할 일은 아니다. 잘못된 구성, 잠김, 외부공격 등 영영 데이터에 액세스 하지 못할 수도 있으며, 정신나간 소리같지만 AWS가 파산할 가능성을 완전히 배제할 수 없다. 

 

S3는 최소 3개 가용영역에 데이터를 자동으로 복제하기 때문에 높은 내구성을 보장할 수 있다. 한 AWS 시설이 완전히 사라지더라도 다른 영역에 있는 데이터 복사본으로 복구할 수 있다. 

 

반면 복원력이 전혀 없는 두가지 스토리지 클래스도 있다 One Zone-IA 는 이름 그대로 데이터를 단일 가용영역에만 저장하고 RRS 는 다른 클래스보다 더 적은 영역에 복제하기 때문에 99.9%의 내구성만을 보장한다. 내구성 증감과 가용성 비용 등 기능의 균현ㅇ을 정해서 적합한 스토리지를 선택할 수 있다. 

 

가용성

객체 가용성도 백분율로 측정하며 1년동안 해당 객체를 요청했을때, 즉시 응답할 수 있는 시간을 백분율로 나타낸다. S3 Standard 클래스는 연간 99,99% 기간동안 데이터가 필요할때 사용될 수 있도록 보장하는데 이는 1년동안 1시간 이내라는 의미 이다. 

 

데이터의 일관성 

S3 데이터를 여러 장소에 복제하므로 기존 데이터가 업데이트 되면 시스템에 전파하는 동안에 약간의 지연이 발생할 수도 있다. 파일을 새 버전으로 업데이트 하거나 삭제할때 한 사이트 에서는 새로운 상태가 반영됐지만 다른 사이트에서는 변경이 반영되지 않을 수 있다. 

단일 객체의 버전 여려개가 충돌하면애플리케이션과 데이터 사이에 심각한 손상이 발생할 수 있는데 이를 피하기 위해서 최종 일관성 표준에 따라 데이터 처리를 설계해야하며 보통 2초 이하의 지연시간을 고려해야 한다. 

 

S3에 새로운 객체를 생성(PUT) 할때는 객체 버전이 충돌할 가능성이 없으므로 쓰기 후 읽기 일관성이 제공 된다. 

 

S3 객체 수명 주기 

S3 에서 시작하는 워크로드는 대개 백업 아카이브와 관련이 있다. 제대로 설계 됐다면 정기적으로 백업이 수행돼야하기 때문에 백업 아카이브가 늘어날 수 밖에 없다. 이전아카이브 버전을 유지하는 것도 필요하지만 오래된 버전을 정리하고 삭제해서 스토리지 비용을 절약하는 것도 중요한데 S3 버전관리와 수명주기 기능으로 이 모든 작업을 자동화 할 수 있다. 

 

버전 관리 

대부분의 파일 시스템은 기존 파일과 같은 위치에 같은 이름으로 파일을 저장하면 기존 객체를 덮어쓴다. 이 경우 항상 최신 버전을 유지할 수 있지만 기존 버전은 삭제된다. 실수로 덮어썼을 때는 다소 심각한 상황이 될 수 있다. 

 

S3 객체도 이와 같은 방식으로 작동하지만, 버킷 수준에서 버전 관리를 활성화 하면 덮어쓴 이전 객체를 보존할 수 있어서 기존 버전에 계속 액세스 할 수 있다. 이로서 실수로 기존 데이터를 잃게 되는 문제를 해결할 수 있지만 아카이브가 늘어나는 것은 감수해야한다

 

수명주기 관리 

버킷에서 수명주기 규칙을 구성하면지정한 기간이 경과했을때 자동으로 객체가 다른 스토리지 클래스로 옮겨진다 예를 들면 새로운 객체는 첫 30일 동안 S3 Standard 클래스에서 보관되고 30일이 지나면 더 저렴한 One Zone IA로 옮겨진다. 과거 버전을 유지해야하는 조직의 규정이 있다면 파일을 저렴한 장기 저장용 스토리지 서비스인 Glacier로 옮겨서 365 일 보관하고 기간이 지나면 영구 삭제된다. 

 

S3 객체 액세스 

S3에 데이터를 저장해서 사용하겠다고 결정했다면 데이터의 중요성에 맞게 S3에 저장된 객체에 액세스 하는 방법과 업무 보안상 필요에 맞는 요청만 액세스 하도록 제한하는 방법을 이해해야한다. 

 

액세스 제어

새롭게 S3 버킷과 객체를 생성한 즉시, 만든 사용자 계정에서는 완벽하게 액세스 할 수 있지만, 다른 AWS 계정이나 외부 사용자는 기본적으로 해당 버킷과 객체에 액세스 할 수 없다. 액세스 제어 블록 규칙,세분화된 S3 버킥 정책 IAM 정책을 사용해서 버킷이나 객체 수준에서 타 계정이나 외부 사용자에게 액세스를 허용할 수 있다. 

 

3가지 액세스 제어방식은 일부 중복 되어 있다 

 

사실 ACL 은 IAM을 만들기 전에 사용하던 정책이다. 지금은 ACL 대신 S3 버킷 정책이나 IAM 정책을 적용할 것을 권장한다. 

 

S3 버킷 정책은 외부 계정과 사용자가 S3 버킷에 액세스 하는 것을 제어할 수 있게 하는 반면 IAM 정책은 IAM이 관리하는 계정 즉 사용자와 역할이 S3를 비롯한 여러 리소스에 액세스하는 방을 제어하고자 할 때 사용한다. 

 

다음 코드는 특정 AWS 계정에 있는 루트 사용자와 사용자 Steve가 S3 MyBucket과 그 내용에 액세스 할 수 있게하는 S3 버켓 정책의 예이다. 두 사용자 모두 이 규칙에서 보안 주체가 된다. 

 

다음 IAM 정책을 IAM 엔터티 에 연결할 때 앞의 S3 버킷 정책과 같은 효과를 얻을 수 있다.

 

미리 서명된 URL

외부 액세스가 제한된 프라이빗 객체에 임시로 액세스 할 수 있게 할 때, 미리 서명된 URL 을 사용할 수 있다. 미리 서명된 URL 은 지정된 기간만 사용할 수 있으며, 기간이 지나면 사용할 수 없고 프로그래밍 방식으로 객체에 액세스 할 수 있도록 미리 서명된 URL 을 생성하는 명령을 코드에 포함해서 빌드 할 수 있다. 

 

정적 웹사이트 호스팅 

S3 버킷은 정적 웹사이트 HTML 파일 호스팅에도 사용된다. 정적 웹사이트는 웹 페이지와 스크립트를 랜더링 할 때 서버가 아닌 클라이언트 시스템 서비스를 사용하며, 클라이언트 브라우저에서 간단하고 유연한 HTML 코드를 실행한다. 

 

S3 정적 사이트를 호스팅하는데 저렴하고 안정된 플랫폼으로 사용할 수 있다. S3 버킷을 정적 호스팅으로 구성하면, 버킷 URL 트래픽이 자동으로 지정된 루트 문서로 연결된다. 보통 루트문서는 index.html 이며 HTML 페이지 내 링크를 클릭하면 링크된 문서나 미디어 리소스가 전송된다. 오류 처리와 리다이렉션도 정적 웹사이트 호스팅 프로파일에 통합할 수 있다.

 

DNS 도메인 이름을 정적 사이트로 라우팅하려면 Route53에서 버킷 엔드포인트를 도메인 이름과 연결한다. S3 버킷이름을 도메인 이름과 똑같게 만들어야 제대로 작동한다. 

 

무로 SSL/TLS 인증서를 ACM 에 요청해서 사이트를 암호화 하고 S3 버킷을 원본으로 하는 CloudFront 배포판에 인증서를 가져올 수 있다. 

 

S3 Select와 Glacier Select

AWS 는 S3나 Glacier에 저장된 데이터에 액세스 할 수 있는 또다른 방법을 제공하는데 그것이 바로 Select이다. 이 기능을 사용하면 SQL 과 유사한 쿼리로 저장된 객체에서 관련 데이터만 검색할 수 있으므로 훨씬 효율적으고 저렴하게 작업할 수 있다. 

 

예를 들어 소매 사이트 판매 , 제고 데이터를 대용량 CSV 파일로 저장하는 경우 회사 마케팅 팀이 영업데이터 중 특정 매장 영업데이터만 정기적으로 분석해야 한다. 이때 S3 Select를 사용하면 전체 데이터를 내려받아서 발생하는 비용을 고려할 필요 없이 일부 데이터만 정확하게 가져올 수 있다. 

 

Glacier

Glacier는 S3 스토리지 클래스의 일부로 보여진다 대부분 S3 클래스와 마찬가지로 99.9%의 내구성을 보장하고 S3 수명주기에 통합할 수 있다 

 

Glacier에는 S3와 크게 다른 점이 있는데 S3 단일 객체 최대 크기는 5TB인 반면 Glacier는 40TB까지 대형 아카이브를 지원하고 S3 에서는 암호화를 선택하지만 Glacier는 암호화가 기본이라는 점! 그리고 S3에서는 인간이 읽을 수 있는 이름으로 키를 만들지만 아카이브에는 기계가만든 ID가 주어진다는 점이다. 

 

그러나 가장 큰 차이점은 데이터를 가져오는데 걸리는 시간으로 S3에서는 데이터를 거의 즉시 액세스 할 수 있지만 Glacier 에서는 객체를 가져오렴녀 몇시간이 걸릴 수있다. 이 차이점은 Glacider 목적을 규정한다. 즉 데이터의 필요성과 사용빈도가 낮은 환경에서 장기적으로 데이터를 보관할 수 있는 저렴한 스토리지로 사용할 수 있다는 것이다. 

 

Glacier 에서 아카이브라는 용어는 문서 비디오 TAR, ZIP 과 같은 객체를 의미하며 아카이브는 S3 버킷에 해단하는 볼트에 저장된다. 

 

스토리지 요금 

이번 절에서는 기업의 일반적인 스토리지 사례를 통해 S3 와 Glacier 의 비용을 비교한다. 

회사에서 영업 데이터를 매주 백업할 때 5GB 아카이브가 만들어 진다고 가정한다. 첫 30 일 동안은 Standard 에서 아카이브를 보관하고 다음엔 S3 One Zone으로 변환헤서 90일간 유지하며 120일이 지나면 Glacier로 이동해서 그 이후에는 삭제된다고 가정한다. 

 

기타 스토리지 관련 서비스 다른 스토리지 관련 AWS 서비스도 알아보자 

 

EFS

EFS는 자동 확장 가능한 공유 파일 스토리지 로서 VPC 내에서 NFS 로 여러 EC2 인스턴스에 장착하거나, Direct Connect 연결로 온프레미스 서버에서 액세스 할 수 있도록 설계됐다. EFS는 여러 인스턴사가 짧은 지연 시간으로 안전하고 내구성있게 파일을 공유하는데 사용할 수 있다. 

 

AWS Storage Gateway

온프레미스 로컬 백업과 아카이브 운영 요구 사항을 클라우드 스토리지 서비스를 사용해 해결하려면 구성이 복잡해진다. Storage Gateway를 사용해 소프트웨어 방식의 게이트 웨이 어플라이언스로 다양한 가상 연결 인터페이스를 구현해서 이러한 요구를 해결할 수 있다. 테이프 드라이브 같은 물리적 백업장치를 연결하는 것처럼 어플라이언스를 로컬 장치에 연결하면 S3나 EBS 와 같은 AWS 플랫폼에 저장할 수 있다. 

 

AWS Snowball 

대용량 데이터 세트를 일반 인터넷 연결로 클라우드에 마이그레이션 하려면 많은 시간과 대역폭이 필요하게 된다 테라바이트 또는 페타 바이트 크기를 백업 또는 실제 사용을 위해 AWS 로 이동할 때 사용할 수 있는 장치가 바로 Snowball 이다. 사용자가 요청하면 AWS는 256 로 암호화한 물리적 Snowball 저장 장치를 사용자에게 배송한다. 사용자가 데이터를 snowball 에 복사한다음 장치를 돌려보내면 Aws 는 그 데이터를 S3 버킷에 올린다.