[SAA] S3 수명 주기 규칙

S3 – Moving between storage classes

• 스토리지 클래스 간 객체의 전환이 가능
• 드물게 액세스하는 객체의 경우 STANDARD_IA, 실시간으로 필요한 것이 아닌 아카이브 객체는 GLACIER, DEEP_ARCHIVE
• 객체의 클래스 간 이동은 수동으로 할 수도 있지만 구명 주기 구성을 사용해 자동으로 할 수 있음 

S3 Lifecycle Rules

• 전환 작업은 객체를 한 스토리지 클래스에서 다른 스토리지 클래스로 전환하는데 도움을 주는 작업
  예) 객체를 생성한지 60일 후 STANDARD_IA 클래스로 보내고 6개월 후에는 아카이빙을 위해 GLACIER로 옮기는 작업
• 만료 작업은 일정 기간이 지난 후 객체를 삭제하는 것
  예) 파일들이 전부 일 년이 넘었으니 만료, 즉 삭제해달라고 요청, 파일의 오래된 버전을 삭제하는데 사용,
  버저닝을 허용해 계속해서 새로운 파일을 덮어쓰고 있을 때 60일 이상 지난 이전의 버전이나 파일, 객체가 필요없을 때 사용,
  분할된 파트가 30일동안 떠돌고 있고 절대 완료되지 않을 다중 파트 업로드를 정리하는데도 사용
• 특정 접두어에 규칙을 적용할 수 있음
  예) s3://mybucket/mp3/* : 모든 mp3 파일이 mp3라는 폴더에 있거나 접구어를 가지고 있을 때 해당 접두어에만 설정
  이 외에도 특정 객체 태그를 위해 규칙을 생성할 수도 있음

S3 Lifecycle Rules – Scenario 1

• 프로필 사진이 S3에 업로드된 후 EC2 애플리케이션이 썸네일을 생성
  이 썸네일들은 손쉽게 재생성할 수 있으며 45일간 보관됨
  45일 동안은 원본 사진 파일을 즉시 회수할 수 있으며 이후에는 유저가 최대 6시간까지 기다릴 수 있음
  이 때 솔루션을 어떻게 비용 효율이 가장 높게 설계할 수 있을까?
• S3 원본 사진은 Standard 클래스에 두고 수명 주기 구성을 설정해 45일 후 Glacier에 보내면 됨
  그렇기 때문에 45일 이후에는 아카이브되어야 하므로 회수를 위해 6시간까지도 기다리게 될 수 있는 것임
  그리고 썸네일은 재생성이 가능하므로One Zone-IA 에 두고 수명 주기 구성을 통해 45일 후에는 필요 없으므로 만료, 혹은 삭제 

S3 Lifecycle Rules – Scenario 2

• 15일 동안은 삭제된 S3 객체를 즉시 복구할 수 있는 규칙이 있음
  그 이후 최대 1년까지는 삭제한 객체를 48시간 내에 복구할 수 있음
  이 때 솔루션을 어떻게 경제적으로 설계할 수 있을까?
• 파일을 삭제는 하되 복구시키길 원하므로 S3 버저닝을 허용함으로써
  객체 버전을 가지고 삭제된 객체는 삭제 마커를 달고 숨겨져 쉽게 복구할 수 있음
  최신이 아닌 버전들은 객체의 이전 버전들도 가지게 되므로
  이 오래된 버전들을 액세스할 일이 드물지만 만약 액세스할 경우에 복구가 즉시 이루어지게 하기 위해 S3-IA로 전환
  그리고 오래된 버전들을 복구할 수 있는 기간이 15일이 지나면 Deep-Archive로 전환시켜 100일이나 365일 동안 보관
  48시간이 주어지고 비용이 더 저렴하므로 Glacier보다 Deep-Archive를 사용하여 비용을 더 절약할 수 있음

<S3 수명 주기 규칙 실습>

• 수명 주기 규칙 정의
  Management 탭에서 수명 주기 규칙을 정의할 수 있으므로 lifecycle rule을 클릭해서 DemoRule 이름으로 생성
  수명 주기 규칙은 버킷 내의 특정 범위를 지정할 수도 있고 모든 객체를 대상으로 할 수도 있으므로 모든 객체를 대상으로 정함
  
  수명 주기 규칙 작업에는 다섯 가지 유형이 존재하며 현재 버전, 혹은 이전 버전의 객체를 스토리지 클래스 간에 전환 가능
  버저닝이 활성화된 경우 현재란 객체의 최신 버전을 의미하고 현재 객체가 아닌 다른 모든 버전들을 이전 버전이라고 함
  그리고 객체의 현재 버전을 만료시킬 수 있고 객체의 이전 버전들을 영구 삭제하는 것도 있고
  만료된 삭제 마커나 미완료 분할 업로드를 삭제하는 옵션도 존재
  
  이번 실습에서는 현재 버전 객체의 스토리지 클래스 전환을 시켜보도록 하여
  객체를 Standard-IA로 30일 후에 보내고 70일 후에는 Intelligent-Tiering으로 보내도록 하고
  180일 후에는 Glacier로 보내고 365일 후에는 Glacier Deep Archive로 보내도록 설정
  
  그리고 객체의 현재 버전을 만료시킬 수 있도록 하기 위해서 객체 생성 후 700일 후 삭제하는 것으로 설정
  
  마지막으로 이전 버전 전환을 통해 60일 후에 Glacier로 옮기도록 설정
  
  그런 후 타임라인 요약을 통해 위의 작업들의 수명 주기 규칙을 요약해 볼 수 있음
  이를 통해 버킷 내에서 여러 수명 주기 규칙을 설정할 수 있으며 필터마다 다르게도 될 수 있어 비용을 쉽게 최적화할 수 있음

현재 버전 객체의 스토리지 클래스 전환 - 1

현재 버전 객체의 스토리지 클래스 전환 - 2

객체의 현재 버전을 만료 - 1

객체의 현재 버전을 만료 - 2

이전 버전 전환 - 1

이전 버전 전환 - 2

타임라인 요약