3장. AWS 스토리지

AWS

3장. AWS 스토리지

juu_98 2022. 9. 10. 22:09

S3 (Amazon Simple Storage Service) 의 용도 크게 3가지

- 아카이브, 로그파일, 재난 복구 이미지 등을 이용한 백업 관리

- 저장된 빅데이터의 분석 업무로 활용

- 정적 웹사이트 호스팅

EC2 인스턴스의 OS 볼륨이 블록 스토리지인 반면, S3는 조금 더 댜앙한 용도로 활용할 수 있는 무제한 용량의 객체 스토리지이다.

객체 스토리지와 블록 스토리지의 차이점

: 블록스토리지는 파일시스템 ( Window의 NTFS, Linux의 ext4) 을 위해 물리적 저장 장치를 블록 단위로 나눈 것으로, 파일시스템은 OS의 주요 기능 중 하나로 OS 작동에 필요한 데이터를 읽어들이기 위해 관련 파이로가 데이터가 저장될 수 있는 공간을 분할 및 할당하는 역할이다.

객체 스토리지는 사용자가 가진 어떠한 형식의 데이터라도 저장이 가능한 공간이다. 어떤 포맷의 데이터, 어떤 용량의 데이터도 저장 가능하다.

S3 서비스 아키텍처

S3 파일은 버킷에 저장된다.

사용자의 계정에는 최대 100개의 버킷을 생성할 수 있으며, AWS측에 가용 버킷 수를 증가시켜줄 것을 요청이 가능하다.

S3 버킷 및 그 속에 저장된 콘텐츠는 단일 AWS 리전에만 존재할 수 있으며, 버킷의 이름은 전세계 S3 시스템을 기준으로 유일한것이어야한다는 특징을 가짐.

ex) http 접근 방식으로 bucketname이라는 버킷 속 filename이라는 파일에 접근하기 위한 URL이다.

s3.amazonaws.com/bucketname/filename

위의 URL을 통해 해당 객체에 접근하기 위한 적절한 접근 권한을 부여해야하며, AWS CLI를 이용한 파일 접근 코드는 다음과 같다.

s3://bucketname/filename

대용량 객체 저장하기

객체 하나의 용량은 5TB를 초과할 수 없으며, 한번의 업로드 작업은 5GB를 초과할 수 없다.

이와 같은 옹량 제한 문제를 피하기 위한 방법으로, AWS는 100MB 초과 객체의 경우 멀티파트 업로드 (Multipart Upload) 기능을 사용할 것을 권장한다.

AWS CLI 또는 고수준 API로 S3에 업로드할 경우 멀티파트 업로드 기능이 자동으로 적용되고, 저수준 API로 업로드 작업을 수행할 경우 사용자가 직접 개체를 여러 부분으로 분할할 수 있다.

AWS는 세심한 설정이 필요한 S3 업로드 작업을 위해 저수준 API를 제공하고, 조금 더 자동화 수준이 높은 S3 업로드 작업을 위해 고수준 API를 제공한다.

S3 버킷에 대용량 파일을 전송해야 하는 경우 Amazon S3 Transfer Acceleration 기능 환경 설정을 통해 전송 속도를 높일 수 있다.

버킷에서 Transfer Acceleration 기능을 사용하도록 설정한 경우, 업로드 작업은 인근 AWS 엣지 로케이션과 Amazon의 내부 네트워크를 통해 고속으로 처리된다.

Transfer Acceleration이 사용자의 지역과 특정 AWS 리전 사이에서 실제로 얼마나 빠른 속도로 파일을 전송하는지 확인하기 위해서는 Amazon S3 Transfer Acceleration Speed Comparison 도구를 사용한다.

해당 기능이 도움이 된다면, 버킷에서 이 기능을 활성화 한 뒤 사용한다.

이때, bucketname.s3-accelerate.amazonaws.com과 같이 특수한 엔드포인트 도메인 네임으로 전송 경로를 설정한다.

※ 멀티 파트 업로드 (Multipart Upload) 란 S3에 하나의 대용량 파일을 업로드 할 때 여러 개의 부분으로 분리해 업로드하는 기능이다. 여러 부분 중 일부가 업로드에 실패하더라도, 반복적으로 업로드 작업을 수행한다는 특징이 있다.

※ API (Application Programming Interface) 란 코드 또는 명령줄 방식으로 각종 작업을 실행할 수 있는 프로그래밍 기법의 인터페이스로, AWS의 각종 서비스에 대한 어드민 작업 방법으로 널리 활용된다.

암호화

S3에 데이터를 저장할 때는 암호화 키를 이용할 수 있고, Amazon의 암호화된 API 엔드포인트를 이용해 S3에서 다른 서비스 또는 리소스로 전송되는 데이터를 암호화 할 수 있다.

- 서버 측 암호화

S3 플랫폼 내에서 진행되며, 디스크에 저장될 때 데이터 객체를 암호화하고, 적절한 권한 증빙을 통해 데이터 인출을 요청할 때 복호화해서 전송한다.

아래 세 가지 옵션 중 하나를 사용할 수 있다.

● AWS는 기업용 표준 키를 이용해서 암호화 및 복호화의 각 단계를 관리한다.

● SSE-S3 보다 고도화된 암호화 서비스로서, 엔벌로프 키(envelope key) 기법을 이용해서 키 사용과 관련된 모든 작업 흐름을 추적해 감사 업무에 활용할 수 있다. 필요에 따라 KMS 서비스를 통해 사용자의 커스텀 키를 임포트하여 사용할 수 있다.

● 커스텀 키를 이용하여 S3 데이터 암호화 및 복호화 작업을 수행한다.

-클라이언트 측 암호화

CMK(Managed Customer Master Key)를 이용하면, S3에 전송하기 전에 데이터를 암호화 할 수 있으며, 데이터 객체 업로드 직전에 데이터 키를 생성한다.

Amazon S3 암호화 클라이언트를 통해 Client-Side Master Key를 사용할 수 있다.

서버측 암호화가 클라이언트측 암호화에 비해 복잡성이 낮아 대다수의 사용자가 선호하는 방법이지만 기업 및 기관에 따라 암호화 키를 직접 생성 및 관리하려는 경우가 있어, 이 때는 클라이언트 암호화를 사용하면 된다.

로그 관리

S3의 이벤트를 로그 파일에 남기는것은 기본적으로 불능으로 설정되어 있다. (S3 버킷의 작업이 많아, 로그를 남기는게 비효율적이기 때문)

S3 로그 기능을 활성화하기 위해서 소스 버킷(작업 내용을 추적하는 버킷)과 타겟 버킷(로그 파일을 저장하는 버킷)을 설정해야 한다.

S3 로그 생성에는 약간의 시간 지연이 발생되며, 아래와 같은 작업 세부 내역 정보가 표시된다.

- 요청자의 계정 및 IP 주소

- 소스 버킷 이름

- 요청 작업 내욕 (GET, PUT, POST, DELETE 등)

- 요청을 한 시간

- 요청에 대한 응답 상태 (오류 코드 포함)

S3 버킷은 CloudWatch, CloudTrail 등 다른 AWS 서비스의 로그 및 객체 저장을 위해 사용된다.

S3의 내구성 (어떤 조건에서도 데이터가 유지되어야 하는지의 대한 성질)

S3의 내구성은 99.99999%로, 이는 10,000,000개의 객체를 저장했다면, 10,000년마다 단 하나의 객체가 손실될 수 있는 확률로 손실 가능성이 사실상 0에 가까운것과 같다.

S3가 제공하는 고도의 내구성은 S3가 최소 세 개의 AZ, 가용성지역에 자동으로 데이터를 복제해 놓기 때문에 가능하다.

이는 특정 지역에 있는 AWS의 전체 시설이 갑자기 없어지더라도 사용자의 데이터 사본은 다른 AZ에 저장되어 있기 때문에 안전하다는 의미와 같다.

이와 같은 내구성은 가용성 또는 비용 등의 요소와 균형을 맞추기 위해 증가 또는 감소할 수 있지만 가급적 내구성이 99.999999%에 이르는 표준 클래스를 사용할 것을 권장하고, 최소 3곳 이상의 AZ에 분산 저장되는 클래스를 선택하는것을 권장한다.

=> 위와 같이 S3 내구성이 좋아 데이터 손실 가능성이 매우 적다고 하더라도 중요한 데이터의 사본을 S3 버킷에만 저장하는 것은 바람직하지 못하다. 중요한 데이터는 항상 복수의 장소에 백업해서 보관해야 하며, 이 때도 서로 다른 서비스 및 미디어 타입을 이용하는것이 좋다.

S3의 가용성 (신속하게 데이터를 인출할 수 있는지 여부에 대한 성질)

Amazon S3 Standard 클래스는 연간 99.99%의 지속적인 요청을 처리할 수 있는 응답 가능성을 보증한다.

이는 연간 9시간 미만의 다운타임이 발생할 수 있다는 의미이며, 이 시간을 초과해서 발생하는 다운타임에 대해서는 서비스 크레딧을 적용할 수 있다.

종국적 일관성 데이터

S3는 다수의 지역에 데이터를 복제하기 때문에 기존 객체를 업데이트하면 시스템 전체에 해당 사실이 전파될 때까지 약간의 시간 지연이 발생한다. 때문에 데이터 상태 변경에 대한 1~2초의 시간 지연을 감안한 뒤 관련 작업 수행의 방식을 설계하여야 한다.

S3 객체 생애주기

백업 아카이브 작업에서는 기존 아카이브 버전을 유지하는 일도 중요하지만, 스토리지 비용 및 공간 관리를 위해 구 버전을 삭제하거나 폐쇄하는 작업도 필요하며, S3는 이를 위해 자동화된 백업 관리 기법인 관리 및 생애주기 관리 기법을 제공한다.

-버전 관리

버킷 레벨에서 버전 관리(versioning)기능을 활성화해서 객체의 구 버전을 저장해 두고 필요할 때는 언제든 접속하도록 할 수 있다.

이는 실수에 의한 덮어쓰기 문제를 해소할 수 있긴 하지만 저장 공간이 지나치게 커지는 문제를 낳기도 한다. 이에 대한 해법이 바로 생애주기 관리이다.

- 생애주기 관리

버킷 레벨의 생애주기 규칙(lifecycle rules)을 작성해서 지정 일수에 따라 자동으로 클래스가 변경되도록 설정할 수 있다.

ex) 처음 30일간 S3 Standard 클래스에 객체를 저장한 후, 다음 30일간은 좀 더 저렴한 One Zone IA 클래스에 객체를 저장하는 생애주기 규칙을 작성할 수 있다.

S3 객체 접근 제어

사용자가 생성한 S3 버킷과 객체에 사용자는 마음대로 접속할 수 있지만, 다른 AWS 계정 또는 외부 사용자는 접근할 수 없다.

따라서 외부 접속자에게 데이터에 대한 접근을 허용할 때는 접근 제어 규칙(ACL)과 S3 버킷 정책, IAM 정책을 통해 세분화된 접근 제어를 할 수 있다.

세가지 접근 제어 중 Amazon은 ACL대신 S3 버킷 정책과 IAM 정책으로 접근 제어를 할 것을 권장한다.

S3 버킷 정책 : JSON 포맷으로 작성된 뒤 S3 버킷에 부착되며, 다수의 외부 계정 또는 유저가 하나의 S3 버킷에 접근하기 위한 규칙 생성에 주로 활용된다.

IAM 정책 : IAM 기반의 계정 레벨에서 접근을 제어하므로, 개별 유저 또는 롤이 S3을 포함한 다수의 리소스에 접근하기 위한 규칙 생성에 활용된다.

Amazon S3 Access Points : 액세스 포인트는 버킷 내 객체를 정의하는 호스트네임이며, 사용자가 설정하는 내용에 따라 클라이언트는 호스트네임을 통해 특정 객체에 대한 읽기 또는 쓰기 권한을 얻게 되며, 접근 허용이 철회되면 더 이상 해당 객체에 접근할 수 없게 된다.

프리사인 URL

프라이빗 객체에 대해 일시적으로 접근을 허용하고자 할 때 프리사인 URL(presigned URL)을 생성해서 제공하면 된다.

CLI를 이용해서 프로그래밍 기법으로 생성하는 프리사인 URL은 일정 시간 동안만 유효하며, 시간이 경과하면 접속할 수 없게 된다.

정적 웹사이트 호스팅

S3 버킷을 정적 웹사이트 호스팅용으로 설정하면, 트래픽은 자동으로 index, html 등, 웹사이트의 루트 문서로 이동하게 되고, 사용자가 HTML 페이지 내 링크를 클릭하면 해당 페이지 또는 미디어로 이동하며, HTML 404 등 오류 발생시 그에 적합한 페이지로 이동하게 된다.

저장된 데이터에 접근할 수 있는 또 다른 방법으로 S3 Select 및 Glacier Select가 있다.

S3 Select는 SQL 스타일의 쿼리 기능을 통해 효율적, 비용효율적으로 객체 내 관련 데이터에만 접근해 필요한 부분만 가져올 수 있다.

사용자는 S3 Select를 이용해 전체 데이터 중 일부만 특정해 데이터를 추출함으로써 데이터 접근 및 다운로드와 관련된 네트워크 부담 및 비용 부담을 모두 줄일 수 있다.

※정적 웹사이트란 서버 측이 아닌, 클라이언트 측에서 웹페이지 렌더링 및 스크립트 실행을 웹사이트로서, 간단하고 단순하게 구성된 웹 문서를 클라이언트 브라우저에서 이용할 수 있도록 한 것이다.

Amazon S3 Glacier

다른 S3 스토리지 클래스와 비슷한 부분이 많으며, 다른 S3 클래스처럼 99.999999%의 내구성을 지니고 S3 수명주기 환경설정에 통합해서 사용할 수 있다.

S3 스토리지 클래스와 다른 부분들도 많은데, 우선 Glacier 아카이브의 저장 용량은 40TB로 제한되며 (S3는 제한 없음),

아카이브 생성 시 기본적으로 저장 데이터를 암호화하고 (S3에서 데이터 암호화는 옵션임),

아카이브 이름은 기계 생성 ID 형식을 지니는 등 (S3 버킷은 사람이 읽기 쉬운 키 이름을 제공),

다수의 차이점이 존재한다.

그 중에 가장 큰 차이점은 데이터 인출 시간이다.

Glacier 아카이브에서 객체를 인출하는데는 수 시간이 소요될 수 있지만, S3 버킷에서는 거의 즉각적으로 객체를 인출할 수 있다.

Glacier 아카이브는 저장된 데이터를 거의 인출하지 않는, 저렴하게 사용할 수 있는 장기 보관용 스토리지이다.