AWS S3, 제대로 이해하기 - Lifecycle Rules

2023. 3. 23. 00:47BACKEND/AWS

반응형

AWS S3에 대한 이해부터 활용까지 이해하는 것이 본 포스팅의 목표입니다.

 

 

 

===== AWS S3, 제대로 이해하기 Series.  =====

✔️ AWS S3, 제대로 이해하기 - S3 Basics

✔️ AWS S3, 제대로 이해하기 - Storage Classes

👉🏻 AWS S3, 제대로 이해하기 - Lifecycle

✔️ AWS S3, 제대로 이해하기 - Replication & Event Notification

 

 

 

Lifecycle Rules

저장된 S3 내 객체들은 Storage Class 간 이동을 시킬 수 있습니다. 아래 그림에서 하위 수준으로 이동할 수 있는데요.

가령, Standard에서는 Standard IA나 Intelligent Tiering으로, One-Zone IA에서는 Glacier Instant Retrieval Flexible과 Deep Archive로 이동할 수 있습니다. 혹은 Standard IA에서 바로 Glacier Flexible Retrieval로 갈 수도 있습니다.

 

https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html

 

Standard 클래스 타입의 객체가 자주 접근되지 않는다면, Standard IA로 옮겨 비용을 절약할 수 있겠죠. 

혹은, Standard 클래스로 사용하다 아카이브를 위해 Glacier Deep Archive 티어로 옮길 수도 있습니다.

 

객체는 옮기는 방식은 아래의 두 가지 방식이 있습니다.

 - 직접 수동 설정

 - Lifecycle Rules(생명 주기 규칙)를 통한 자동화

 

Lifecycle Rules은 특정 객체를 특정 조건/시점에 특정 클래스 타입으로 전환하거나 만료 시키는 것을 자동화하도록 설정할 수 있습니다. 특정이라는 단어가 보이는데, 바로 이 부분들을 설정할 수 있습니다. 지금부터 Lifecycle Rules를 설정하는 과정을 살펴보며, Lifecycle Rules의 개념을 살펴볼 예정입니다. 먼저, S3의 버킷을 살펴보면 아래와 같이 Management Tab에서 Lifecycle rules 속성을 확인할 수 있습니다.

 

 

 

여기서 Create lifecycle rule을 선택하면 아래와 같은 폼을 볼 수 있습니다. Lifecycle rule을 지정하는 것은 그림 아래와 같이 정리할 수 있습니다. 크게 Configuration과 Actions을 지정할 수 있는데, Configuration 섹션에서는 Lifecycle의 이름과 해당 Lifecycle rule을 적용할 타겟을 지정하고 Action에서는 어떤 동작을 할지를 설정합니다.

 

 

Configuration에서는  이름과 대상 타겟이 포함될 범위(A rule scope)를 지정합니다.

 

 

Rule scope

적용할 수 있는 범위는 옵션 두 가지를 볼 수 있습니다.

 

1. Limit the scope of this rule using one or more filters

2. Apply to all objects in the bucket

 

하나 이상의 필터를 사용해서 범위를 제한하거나, 버킷 내의 모든 객체에 반영할 수 있습니다. 첫 번째 옵션의 필터 지정은 Prefix(접두사), Tags(태그), Object Size(사이즈)을 선택하여 적용할 수 있습니다.

 

1. Prefix             : 특정 Prefix을 지정 (ex. /Private)

2. Object tags : 특정 Tag가 붙은 객체만을 타깃으로 할 수 있음 (ex. Department:Development)

3. Object size  : 최소, 최대 객체 사이즈를 특정 지을 수 있음

 

 

Actions

이후로 어떤 작업을 할 것인지를 지정합니다. 크게 다른 클래스 타입으로 전환(Move)하거나 만료(Expire)시키는 설정을 할 수 있습니다.

혹은 delete marker가 표시되었거나 완료되지 않은 멀티파트 업로드를 삭제하도록 구성할 수 있는데, 가령 끝났어야 할 업로드가 2주째 진행되지 않는 멀티파트 업로드를 삭제하도록 설정할 수 있습니다.

 

 

 

1 & 2. Move current/noncurrent versions of objects between storage classe

스토리지 클래스 간 최신 버전(current) 혹은 이전 버전(noncurrent)의 객체 이동하는 전환 작업을 진행할 수 있습니다. 가령, 생성 60일 후에 Standard IA로 이동하도록 설정하거나 6개월 후에 Glacier에 아카이빙되도록 설정할 수 있습니다.

 

예를 들어, EC2에 애플리케이션이 있고 Amazon S3에 업로드되는 프로필 사진의 이미지 섬네일을 생성하고자 합니다. 이 때, 섬네일은 원본 사진에서 재생성하기 쉽기 때문에 60일 동안만 보관하고자 합니다.

섬네일은 업로드 후 60일 동안은 빠른 검색이 가능해야 하고, 60일 이후엔 사용자가 이후 6시간까지 기다릴 수 있습니다.

S3에 섬네일 이미지를 Standard 클래스에 두고 수명 주기 구성을 한 다음, 60일 이후에 Glacier로 전환하면 되겠죠. 이 때, "/Thumbnail" 이라는 위치에 저장해두면 Prefix를 이용해 쉽게 처리할 수 있습니다.

 

실제 Move current/noncurrent versions of objects between storage classe 옵션을 선택하면 각각 아래와 같은 섹션이 생기고 각 경과 날짜에 대해 옮길 스토리지 클래스를 지정할 수 있습니다.

 

 

current versions of Objects
noncurrent versions of Objects

 

 

 이렇게 지정한 것은 설정 섹션 바로 하단에 하단과 같이 보기 쉽게 표기됩니다.

 

 

 

 

변경할 스토리지 클래스를 선택할 때(Choose storage class transitions)에는 아래와 같은 옵션들을 선택할 수 있습니다.

 

Standard-IA

  • Infrequently accessed data (once a month) with milliseconds access
  • 30 days minimum storage duration

Intelligent-Tiering

  • No minimum storage duration
  • Data with changing or unknown access patterns

One Zone-IA

  • 30 days minimum storage duration
  • Recreatable, infrequently accessed data (once a month) stored in a single Availability Zone with milliseconds access

Glacier Instant Retrieval

  • 90 days minimum storage duration
  • Long-lived archive data accessed once a quarter with instant retrieval in milliseconds

Glacier Flexible Retrieval (formerly Glacier)

  • 90 days minimum storage duration
  • Long-lived archive data accessed once a year with retrieval of minutes to hours

Glacier Deep Archive

  • Long-lived archive data accessed less than once a year with retrieval of hours
  • 180 days minimum storage duratio 

 

3. Expire current versions of objects

객체의 최신 버전 만료 작업을 설정할 수 있습니다. 지정 객체를 일정 시간이 지나면 객체가 삭제 또는 만료되게 합니다. 가령, 365일 후에 액세스 로그 파일을 삭제하도록 하거나 버저닝을 활성화한 경우, 이전 버전의 파일을 삭제하도록 설정할 수 있습니다. 그리고 수명 주기 구성을 통해 60일 이후에 만료 또는 삭제시키는 거죠.

Expire current versions of objects 옵션을 선택하게 되면 아래와 같은 섹션이 생깁니다.

 

 

이 때, 700이라는 값을 입력하면 아래와 같이 Day 700: Objects expire 이 추가된 것을 확인할 수 있습니다.

 

 

 

4. Permanently delete noncurrent versions of objects

최신 버전이 아닌 객체를 영구 삭제합니다.

 

 

 

버전 사용 버킷의 경우 Amazon S3에서 삭제 마커를 추가하고 개체의 현재 버전이 최신 버전이 아닌 버전으로 유지됩니다. 버전이 아닌 버킷의 경우 Amazon S3는 개체를 영구적으로 제거합니다.

 

 

 

 

5. Delete expired object delete markers or incomplete multipart uploads

만료된 객체 삭제 마커 혹은, 완료되지 않은 멀티파트 업로드를 삭제합니다. 해당 작업은 개체 태그 또는 개체 크기를 지정하여 필터링할 때에는 지원되지 않습니다.

해당 옵션을 선택하면 아래와 같은 설정 섹션이 추가됩니다.

 

 

 


 

특정 클래스에서 다른 클래스로 객체를 전환하는 데에 있어, 최적의 기간은 어떻게 정할 수 있을까요? 바로 Amazon S3 Analytics를 이용해서 결정하면 됩니다.

 

 

S3 Analytics

: Storage Class Analysis

🔗 link

 

 

Amazon S3 Analytics는 Lifecycle 을 추천받고 싶을 때 사용할 수 있습니다. S3 analytics Storage Class Analysis는 적절한 데이터를 적절한 스토리지 클래스에 전송할 수 있도록 스토리지 접근 패턴을 분석해줍니다. Lifecycle Rules 사용 초기에 함께 적용하기 좋고, Lifecycle Rules을 더 개선시킬 때에도 효과적입니다.

 

Amazon S3 Analytics 분석 리포트를 제공하는데, 매일 업데이트 되며, 24시간에서 48시간 이후에 분석된 데이터를 확인할 수 있습니다. 데이터 접근 패턴을 지켜 보며, Standard Class에 있는 객체가 접근이 적어 Standard IA(Infrequent Access)로 이동시킬만 하면, 그 시점을 알려줌으로써 적절한 스토리지를 선택하게끔 도와줍니다.

 

단, Standard나 Standard IA 를 사용할 때 추천하며, One-Zone IA 나 Glacier에서는 사용하지 못합니다.

 

반응형