sol 개발 블로그 로고
Published on

AWS S3 (2)

Authors
  • avatar
    Name
    Chan Sol OH
    Twitter

목차

이번 포스팅은 AWS S3의 심화 개념을 정리한다. 기본적인 개념은 AWS S3 (1)를 참고하면 볼 수 있다,

다른 스토리지 클래스로 객체를 옮기기

이전 포스팅을 참고하면 AWS S3에는 Standard, Standar-Infrequent Access, One Zone-Infrequent Access, 그리고 Glacier 등등 여러 클래스가 있다.

객체가 자주 사용되지 않을 것을 안다면 Standard IA로 이동하고, 아카이드에 저장할 예정이라면 객체를 Glacier나 Glacier Deep Archive에 저장하면된다. 물론 객체를 위처럼 수동으로 이동시킬 수 있지만, **수명 주기 규칙(Lifecycle Rules)**을 이용해 자동화할 수 있다.

한 클래스에 저장된 객체를 다른 클래스로 이동시키는 방법은 아래 나열된 S3의 클래스의 순서에 따라 바뀔 수 있다. 즉 낮은 번호의 클래스에 있는 객체는 큰 번호의 클래스로 이동할 수 있다.

  1. Standard
  2. Standard IA
  3. Intelligent Tiering
  4. One-Zone IA
  5. Glacier Instant Retrieval
  6. Glacier Flexible Retrieval
  7. Glacier Deep Archive

수명 주기 규칙 (Lifecycle Rules)

전환 작업 (Transition Actions) 수명 주기 규칙은 객체를 구성해 다른 스토리지 클래스로 전환하기 위한 **전환 작업(Transition Actions)**이다. 예를 들어 객체가 생성된지 60일 후에 Standard IA 클래스로 이동시키고, 다시 6달 후에 Glacier로 아카이빙하는 규칙을 생성할 수 있다.

만료 작업 (Expiration Actions) 수명 주기 규칙은 객체를 생성하고 일정 시간 후에 제거하는 **만료 작업 (Expiration Actions)**을 설정할 수 있다, 예를 들어 log files나 버저닝된 files는 오래된 파일을 만료 작업을 통해 제거할 수 있다. 또는 2주 이상 완료되지 않은 Multi-Part 업로드 파일을 제거할 수 있다.

이 밖에도 특정 경로(prefix) 설정(ex : s3://exbucket/sol/*)이나 객체 태그 (ex : Department:Development)를 설정할 수 있다.

시나리오 1, 썸네일

S3에 프로필 사진이 업로드된 후 EC2 애플리케이션이 사진의 썸네일을 생성 및 저장했다. 이렇게 생성된 썸네일들은 60일 동안 유지되며, 썸네일을 통해 원본 사진을 즉시 검색할 수 있어야한다. 60일 이후 유저는 원본 사진을 복구하는데 6시간 동안 기다려야한다.

원본 사진 저장 방법 S3 객체를 6시간 이후에 복구 가능한 클래스는 S3 Glacier Flexible Retrieval Bulk이다. 즉 원본 사진은 60일 동안 Standard에 저장되며 그 이후에는 S3 Glacier Flexible Retrieval Bulk으로 Lifecycle configuration을 통해 이동시킨다.

썸네일 사진 저장 방법 썸네일 이미지는 Lifecycle configuration의 접두사 설정을 이용해 원본과 썸네일을 구분할 수 있고, 썸네일은 자주 액체스하지 않고 쉽게 다시 검색할 수 있기 때문에 One Zone-IA에 보관할 수 있다. 또한 Lifecycle configuration를 통해 60일 후 만료되도록 할 수 있다.

시나리오 2, 복구

회사 규칙에 따라 30일 동안 삭제된 S3 객체를 즉시 복구할 수 있어야한다. 또한 드물게 최대 365일 동안 삭제된 객체를 48시간 내에 복구할 수 있어야한다.

객체 삭제를 위하여 객체 버전을 유지하도록 S3 버전 관리를 활성화하여 삭제된 객체는 삭제 마커를 통해 숨겨져 있으며 복구할 수 있도록 할 수 있다. 객체를 즉시 복구를 위해 최신 버전이 아닌 객체를 30일 동안 Standard IA에 보관할 수 있다. 객체를 삭제하고 48시간 내에 복구하려면 S3 Glacier Deep Archive에 보관하는 것이 적절하다.

S3 Class Analysis

S3 분석을 이용해서 객체를 언제 적절한 클래스로 옮기면 좋을지를 결정할 수 있다. 보통 Standard나 Standard IA를 권장하며 One Zone-IA나 Glacier는 사용할 수 없다.

S3 버켓에 대해서 S3 분석을 수행하며 분석에는 권장 사항과 통계를 제공하는 CSV 보고서가 생성된다. 보고서는 매일 업데이트되며 결과는 24~48시간이 걸릴 수 있다. 이러한 보고서를 통해 적절한 Lifecycle Rule을 결정할 수 있다.

S3 이벤트

S3 이벤트 발생 기준

  • S3 버킷에서 객체가 생성, 삭제, 복원, 복제 업데이트될 때
  • 특정한 규칙을 객체 이름이 만족한 경우 (ex : .jpg)

예를 들어 S3 이벤트는 S3에 업로드되는 모든 이미지의 썸네일을 생성하는 경우, 객체 이름에서 .jpg를 인지하고 이벤트를 발생시켜서 몇 가지 목적지(SNS, SQS, Lambda)로 보낼 수 있다. 이처럼 이벤트는 원하는 목적지에 원하는 만큼 보낼 수 있다. 이벤트는 즉시 보내지지만, 도착하는데 몇분이 걸릴 수 있다.

이벤트 알림이 작동하기 위해서는 IAM 권한이 필요하다. 예를 들어 S3 이벤트가 SNS에 접근하려면 SNS 리소스 접근 정책이라는 것을 첨부해야한다. 이는 SNS 주제에 첨부하는 IAM 정책으로 이것으로 S3 버킷에서 SNS 주제로 바로 메세지를 보낼 수 있다.

위처럼 S3 이벤트 전달을 위해 S3의 IAM 역할을 사용하지 않는다. 대신 목적지 서비스에 리소스 접근 정책을 정의한다. 이벤트 전달 주체로 (SNS, SQS, Lambda)가 있다.

S3 이벤트와 EventBridge

이벤트는 예외없이 모두 S3 버킷으로 가서 EventBridge로 간다. EventBridge에서 규칙을 정의할 수 있고, 이 규칙에 따라 18 종류의 AWS 서비스를 목적지로 해서 이벤트를 보낼 수 있다. 메타데이터나 객체 크기, 이름 등 복잡한 필터링을 통해 목적지를 정할 수 있고, 필요에 따라 다중 목적지로 이벤트를 보낼 수 있으며 EventBridge 자체적인 기능으로 S3 이벤트 알림의 기능을 향상시킨다.

S3 기본 성능

S3는 많은 수의 요청에 따라 자동으로 확장되며, 첫 바이트를 받는데 100ms~200ms의 매우 낮은 지연 시간이 있다. PUT,COPY,POST,DELETE는 초당 3,500회 할 수 있고, 버킷의 접두사마다 GET 요청은 초당 5,500회 할 수 있다. 또한 버킷의 접두사 수는 제한이 없다.

객체 접수사란

예를 들어 파일 이름이 bucket/foler1/sub1/file일 때 bucket과 File 사이에 있는 /foler1/sub1/를 접두사라고 한다. 따라서 해당 접두사(/foler1/sub1/)에서 초당 3,500개의 put과 5,500개의 get 작업을 수행할 수 있다.

접두사 당 요청 수가 제한되어 있기 때문에 4개 접두사에 골고루 요청하게되면 초당 22,000회의 GET 요청을 보낼 수 있게된다. 이 부분에서 S3 성능 최적화의 힌트를 얻을 수 있다.

성능 최적화 방법

  1. Multi-Part upload : 100MB 보다 큰 파일의 경우 멀티파트 업로드가 권장되며 5GB 이상의 경우 필수이다. 또한 Multi-Part upload는 업로드를 병렬화하여 대역폭을 극대화할 수 있기에 전송 속도를 높이는데 도움을 준다.
  2. Transfer Acceleration : 다른 Region에 객체를 업로드나 다운로드할 때 사용된다. 먼저, 데이터를 AWS edge location으로 전달하고, edge location에서 S3 버킷으로 다시 전달된다. 또한 Multi-Part upload와 함께 사용할 수 있다.

edge location이란 특정 Region에서 퍼블릭 인터넷과 연결되어 있으며 AWS 프라이빗 네트워크와도 연결된 부분이다. 예를 들어 USA에 있는 객체를 퍼블릭 인터넷을 통해 USA edge location으로 전달하고, 그후 AWS 고속 프라이빗 네트워크를 통해 Australia의 S3 버킷으로 전달될 수 있다.

즉 edge location은 퍼블릭 인터넷을 통과하는 시간을 줄이고, 프라이빗 네트워크를 통과하는 시간을 늘려 빠른 전송을 가능하게한다.

  1. S3 Byte-Range Fetches : 구체적인 바이트 범위를 요청하여 GET 요청을 병렬화할 수 있다. 특정 바이트 범위를 가져오지 못한 경우에도 더 작은 바이트 범위로 다시 시도할 수 있으며, 장애가 있는 경우에도 복원력이 개선된다. 보통 다운로드 속도를 개선하기 위해 사용한다.

예를 들어 S3에 매우 큰 파일이 있을 때 바이트 범위로 파일을 병렬적으로 전달될 수 있다. 또는 헤더의 첫 50바이트만 부분적으로 요청하면 정보를 매우 빠르게 얻을 수 있다.

S3 Select & Glacier Select

S3에서 적은 양의 데이터를 검색할 때 너무 많은 데이터를 검색해야할 수 있다. 대신 SQL을 사용해 server-side filtering을 수행할 수 있다면 간단함 SQL 명령문으로 행이나 열을 기준으로 필터링하여 네트워크 전송과 실제로 데이터를 거치고 필터링하는 클라이언트 측의 CPU 코스트를 줄일 수 있다.

이전에는 S3에서 모든 데이터를 검색하고, 애플리케이션 측에서는 필터링을 통해 필요한 것을 찾게된다. 하지만 SQL을 통해 서버 사이드 필터링한다면, 네트워크 전송량과 CPU 사용량을 줄어서 400% 빠르고, 80% 더 싸게 검색할 수 있다.

사용자 정의 객체 메타데이터 및 객체 태그

객체 메타데이터

유저가 객체를 만들고 객체를 업데이트할 때 메타데이터도 할당할 수 있다. 메타데이터는 객체에 연결된 키-값 쌍에 대한 이름뿐이다. 사용자 정의 메타데이터를 업로드하면 x-amz-meta-로 시작하는 이름을 부여해야한다. 이른 AWS에서 자체적으로 생성한 메타데이터와 구별짓기 위함이다.

메타데이터는 객체를 검색할 때 사용할 수 있으며 객체 자체에 대한 정보를 담고 있다. 예를 들어 AWs 자체적으로 객체의 타입과 크기에대한 메타데이터를 생성한다. 사용자는 x-amz-meta-origin이라는 메타데이터를 부여할 수 있다.

객체 태그

태그는 AWS의 다른 서비스도 사용하기 때문에 S3 객체에 대한 키-값 쌍이 있다. 태그를 사용해 권한 세분화나 특정 태그를 가진 객체에 액세스 같은 작업을 수 있다. 예를 들어 S3 분석과 같은 솔루션을 사용할 경우 태그로 검색 결과를 그룹화할 수 있다.

정리하면 객체 검색을 위해선 메타데이터만 사용할 수 있고, 객체 작업은 태그를 사용할 수 있다. 하지만, 외부 인덱스 DB(DynamoDB)를 사용하면 메타데이터와 태그 모두를 인덱싱할 수 있고, 이를 통해 객체를 검색할 수 있다.

Discuss on Twitter • View on GitHub