[AWS] 📚 S3 티어(스토리지 클래스) & 수명주기 관리하기

...

S3 티어 (스토리지 클래스)

S3 스토리지는 일반적으로 어떤 종류의 데이터를 관리하는지에 따라서 그리고 얼마나 자주 그 데이터에 접근해야 하는지에 따라서 분류가 된다.

예를들어 자주 엑세스하는 데이터는 내구성이 높은 스토리지에, 자주 엑세스는 하지는 않는데 그래도 저장이 필요한 데이터들은 비교적 가격이 저렴한 스토리지에 저장하는 등 다양히 활용할 수 있다.

아마존의 일종의 마케팅 전략이라고 보면 된다. 그렇지만 생각보다 훨씬 합리적인 요금제이다.

사용자가 정말 “쓴 만큼만" 과금할 수 있도록 하는 요금제이기 때문이다.

그래서 이런 분류를 Storage Class라고 하며 각각 다음과 같은 특징이 있다.

	Standard	Intelligent-Tiering	Standard-IA	One Zone-IA	Glacier	Glacier Deep Archive
내구성을 위한 설계	99.999999999% (11개의 9)	99.999999999% (11개의 9)	99.999999999% (11개의 9)	99.999999999% (11개의 9)	99.999999999% (11개의 9)	99.999999999% (11개의 9)
가용성을 위한 설계	99.99%	99.9%	99.9%	99.5%	99.99%	99.99%
가용성 SLA	99.9%	99%	99%	99%	99.9%	99.9%
가용 영역	≥3	≥3	≥3	1	≥3	≥3
객체당 최소 용량 요금	해당 사항 없음	해당 사항 없음	128KB	128KB	40KB	40KB
최소 스토리지 기간 요금	해당 사항 없음	30일	30일	30일	90일	180일
검색 요금	해당 사항 없음	해당 사항 없음	검색한 GB당	검색한 GB당	검색한 GB당	검색한 GB당
첫 번째 바이트 지연 시간	밀리초	밀리초	밀리초	밀리초	분 또는 시간 선택	시간 선택
스토리지 유형	객체	객체	객체	객체	객체	객체
수명 주기 전환	예	예	예	예	예	예

이처럼, 상황에 따라 필요한 스토리지 클래스를 사용할 수 있고 하나의 스토리지 클래스에서 다른 클래스로 데이터를 이동할 수도 있다.

S3 Standard (S3 기본)

S3 하면 가장 보편적으로 사용되는 스토리지 타입이며 가장 일반적인 요금제 이다.

99.99% 가용성, 99.999999999% 내구성을 지니고 있다.

내구성 - 어떤 조건에서도 데이터가 유지할 수 있는 퍼센트. 99.999999999% 내구성이란 인프라가 실패하더라도 표준 S3 플랫폼에 저장된 데이터의 손실 가능성은 사실상 0에 가깝다는 의미
가용성 - 객체에 대한 지속적인 요청을 처리할 수 있는 능력을 퍼센트.
비용 효율성 - 비용을 얼마나 절약할 수 있는지

S3 - IA (Infrequent Access / 스탠다드 IA)

자주 접근되지는 않으나 접근시 빠른 접근이 요구되는 파일이 많을시 저렴한 가격에 IA에 보관하면 유용하다.

일반 S3에 비해 비용은 저렴하나 데이터를 불러올때마다 추가 비용 발생한다.

뉴스 신문 서비스를 예로 들자면 오늘기사는 트래픽이 많겠지만 1달 2달이 지나면 트래픽이 많이 줄어들 것이다.

그렇다고 트래픽이 계속 하향추세로 간다고 단정짓기도 애매한것이 나중에 다시금 기사가 이슈화되어 또 다시 많은 트래픽이 몰릴 수 있어 언제든 많은 트래픽이 올것을 준비하고 있어야 한다.

이럴때 Infrequent Access를 사용하기 적합하다. 즉, 사용도가 다소 낮은경우의 요금제라고 이해하면 된다.

일반적으로 S3에서 30일이상 액세스가 잘 이루어지지 않았다면 알아서 IA요금제로 전환되도록 되어있다.

* Standard One Zone - IA의 경우에는 99.999999999%의 내구성과 99.5%의 가용성을 지원

S3 - One Zone IA (단일영역 IA)

기본적으로 IA와 같지만 하나의 AZ에만 데이터 저장하는 클래스이다.

덜 중요하고 자주 사용되지 않는 데이터를 저장하는데 적합하다.

단일영역 IA는 스탠다드 IA와 트래픽 요금은 같지만 저장요금은 더 저렴(20%)하다.

하지만 하나의 AZ에만 저장하니 만일 가용영역에 문제가 생길경우 데이터를 날려먹을 수 있다는 위험은 존재한다.

S3 - Intelligent Tiering (지능형 계층화)

머신러닝을 통해서 자동으로 파일의 티어(클래스)를 변경 하는 서비스이다.

예를들어 최근에 파일을 사람들이 자주 접근하면 스탠다드에 옮기고, 접근빈도가 낮으면 IA로 옮기고, 다시 많이 찾으면 스탠다드에 옮기는 형식이다.

퍼포먼스 손해 오버헤드 없으며 관리비도 그렇게 많이 들지 않는다.

S3 - Glacier

이름에서 볼수있듯이, 빙하에 데이터를 꽁꽁 얼려 보관하는 컨셉의 아카이브 서비스이다.

5년전, 10년전 데이터, 아무도 볼것 같지도 않아 쓸모 없는데 법적인 이유 등으로 보관은 해야되는 데이터들을 보통 취급한다. 즉, 거의 접근하지 않을 데이터 저장 시 유용하며 매우 저렴한 비용을 자랑한다.

그러나 데이터 접근시 대략 분~시간 소요될 정도로 상당히 오래걸린다.

이외에도 Glacier는 다른 S3 스토리지 클래스와 다른 부분도 많다.

우선 Glacier 아카이브의 저장 용량은 40TB로 제한되며(S3는 제한 없음), 아카이브 생성 시 기본적으로 저장 데이터를 암호화하고(S3에서는 암호화가 옵션), 아카이브 이름은 기계 생성 ID 형식을 지니는 등(S3 버킷은 사람이 읽기 쉬운 키 이름 제공) 다수의 차이점이 존재한다.

Glacier에서 아카이브라는 말은 문서, 비디오, TAR, ZIP 파일 등 저장 객체를 가리키는 말이며, Glacier vaults(볼트)에 저장된다.

Glacier에서 볼트는 S3에서 버킷에 대응되는 개념이지만, 전역에서 유일무이한 이름을 부여할 필요는 없다.

S3 스토리지가 여러 티어 클래스로 나뉘듯이, Glacier 스토리지 자체에서도 다음 세 가지가 존재한다.

그중에서 S3 Glacier Deep Archive가 가장 저렴한 서비스이다.

S3 Glacier Instant Retrieval

밀리초 단위의 검색시간, 분기당 한 번 엑세스에 적합
자주 액세스하지 않지만 이미지 호스팅, 온라인 파일 공유 애플리케이션, 의료 영상 및 건강 기록, 뉴스 미디어 자산, 위성 및 항공 영상과 같이 성능에 민감한 사용 사례에서 즉시 액세스할 수 있어야 하는 데이터용으로 설계 되었다.

S3 Glacier Flexible Retrieval

수 분~몇 시간(최대 12시간)의 검색 시간, 연간 1~2회 액세스에 적합
즉각적인 액세스가 필요하지 않지만 백업 또는 재해 복구 사용 사례와 같이 대규모 데이터 집합을 무료로 검색할 수 있는 유연성이 필요한 아카이브 데이터에 이상적인 스토리지 클래스.

S3 Glacier Deep Archive

이름에서 볼수있듯이 가장 깊은 빙하.
12~48시간의 검색 시간, 연 1회 미만 액세스에 적합, 가장 저렴한 스토리지
데이터 집합을 7~10년 이상 보관하는 금융 서비스, 의료, 미디어, 엔터테인먼트, 공공 부문의 고객을 위해 설계되었다.

S3 스토리지 클래스 실전 연습

S3 객체를 다른 스토리지 클래스로 변경

만일 빈번히 사용되지 않는 객체(데이터)가 있을 경우 비용절감을 위해 IA 스토리지로 보낸다고 해보자.

보내고 싶은 객체들을 선택하고 [작업 메뉴]에서 [스토리지 클래스] 편집을 누른다.

S3 스토리지 연습 문제

S3 티어에 대해 알아봤다면 다음 문제를 풀어보자.

정답 : C

S3 수명주기 관리 (Lifecycle)

S3는 버킷에 저장된 객체의 수명 주기(Life Cycle)를 관리할 수 있는 기능이 있다.

이 기능은 일정 시간이 지났을 때 사용되지 않는 파일들을 삭제하거나 다른 곳에 백업하여 하게 해준다.

위에서 S3 스토리지 클래스에 대해서 알아보았고, 각 티어마다 특징과 요금제가 다르다는 사실도 알았다.

즉, 자신의 서비스 상황에 따라 적절히 수명주기 관리를 통해 잘 안쓰는 데이터를 IA나 Glacier로 이동시키는 등 보다 비용 효율적으로 S3 관리가 가능해진다.

정리하자면, S3 수명주기는 간단하게 새로운 버전 파일은 ~하고, 예전 버전 파일은 삭제해줘 라는 스크립트라고 이해하면 된다.

ex) 30일이 지난 후 삭제
ex) 30일이 지난 후 Glacier로 옮기기

S3 버저닝 기능과 연동이 가능하며, 예전 버전과 현재 버전에 대해 설정 가능하다.

또한 파일이 업로드 / 삭제 / 업데이트 되었을 때 Lambda 호출도 가능하다.

S3 수명주기 작업

S3 수명 주기 구성에는 다음과 같은 두 가지 유형의 작업이 있다.

1. 전환 작업

객체가 다른 스토리지 클래스로 전환할 시기를 정의
예를 들어, 생성 후 30일이 지나면 객체를 S3 Standard-IA 스토리지 클래스로 전환하거나, 생성 후 1년이 지나면 객체를 S3 Glacier 스토리지 클래스에 아카이브하도록 선택

2. 만료 작업

객체가 만료되는 시기를 정의
Amazon S3는 만료된 객체를 자동으로 삭제
수명 주기 만료 비용은 선택한 객체 만료 시점에 따라 달라짐

S3 수명주기 사용해야 하는 경우

버킷에 주기적으로 로그를 업로드할 경우 (eg. ELB access log, VPC flow log 등)
→ 애플리케이션으로 부터 쌓이는 로그를 일정 기간 동안에 필요로 하지만, 그 이후에 사용자가 삭제하고 싶을 경우
특정 기간 동안만 자주 액세스하는 문서
→ 일부 문서는 특정 기간 동안에만 자주 액세스 되고, 그 이후에 거의 액세스가 없는 경우
보관 목적의 데이터
→ 어떤 유형의 데이터는 주로 보관 목적으로 Amazon S3에 업로드할 수 있다.
→ 예를 들어, 디지털 미디어, 금융 및 의료 기록, 가공되지 않은 유전체 염기 서열 데이터, 장기 데이터베이스 백업 파일, 그리고 규제 준수를 위해 보존해야 하는 데이터 등이 있다.

S3의 수명주기는 무한으로 증가되는 S3 버킷 용량을 주기적으로 정리하는데 목적이 있다.

수명주기는 각 버킷별로 생성할 수 있으며, 같은 수명주기를 가지더라도 각 버킷에서 새롭게 생성해줘야 한다.

예를 들어, 처음 30일간 S3 Standard(버킷 티어 종류)에 객체를 저장한 후, 다음 30일간은 좀 더 저렴한 One Zone IA(버킷 티어 종류)에 객체를 저장하는 생애주기 규칙을 작성할 수 있다.

이후 법규 등에 의해 오래된 데이터를 1년간 추가로 보관해야 하는 경우, 365일간 Glacier(버킷 티어 종류)에 저장한 뒤 영구적으로 삭제하는 규칙 또한 추가할 수 있다.

접두사를 이용해서 버킷 내 일부 객체에 대해서만 생애주기 규칙을 적용하는 것도 가능하다.

단, 객체 이동 전 특정 클래스에 유지돼야 하는 최소 기간(ex. 30일)이 정해져 있으며, S3 Standard에서 Reduced Redundancy로 직접 이동시킬 수는 없다.

Amazon S3은 다음 다이어그램과 같이 스토리지 클래스 간 전환을 위한 폭포형(Waterfall) 모델을 지원한다.

즉, S3 Standard 에서 S3 Standard-IA 로 전환은 가능하지만 S3 Standard-IA 에서 S3 Standard로는 전환이 불가능하다.

S3 수명 주기 규칙 설정하기

AWS 콘솔에 접속 후 수명 주기를 적용할 S3 버킷으로 이동해 [관리] 메뉴 클릭한다.

수명 주기 규칙 이름을 입력할때는 명시적으로 용도를 나타내게 작성하는 것이 좋다.

그리고 규칙 범위는 [하나 이상의 필터를 사용하여 이 규칙의 범위 제한]을 선택한다.

접두사에는 수명 주기를 적용할 디렉토리나 파일 등의 필터를 작성하면 된다.

모든 하위 디렉토리에 영향을 주는 건 의도하지 않은 파일이 삭제될 수 있으므로, 특정한 목적이 있는 게 아닌 한 특정 디렉터리에만 규칙을 정해주는 것이 좋다.

예를 들어 fodler 디렉토리가 포함된 모든 파일에 적용하려면 /folder 라고 입력하면 된다.

이때 조심해야 할 점은 버킷명은 제외하고 입력해야 하고, 경로도 상세히 적어주어야 한다.

「하나 이상의 필터를 사용하여 이 규칙의 범위 제한」은 특정 디렉토리의 파일들만 규칙을 적용시키는 옵션이고
「이 규칙은 버킷의 모든 객체에 적용됨」은 버킷 내의 모든 파일에 적용시키는 옵션이다.

이제 수명 주기 규칙 작업을 설정해준다.

위에서 말했던 몇일이 경과하면 삭제하던가 아니면 다른 스토리지 클래스로 보내던가 하는 설정을 바로 여기서 하는 것이다.

스토리지 클래스 간에 객체의 현재 버전 전환
- 원하는 스토리지 클래스 전환을 선택하고 객체 생성 후 경과 기간을 설정

스토리지 클래스 간에 객체의 이전 버전 전환
- 현재 버전 전환과 방법은 동일

객체의 현재 버전 만료
- 날짜를 지정하면 그 날짜 기준으로 만료 상태로 변경 되며 시간이 좀 더 경과된 후 삭제

객체의 이전 버전 영구 삭제
- 설정된 날짜 기준으로 삭제

만료된 삭제 마커 또는 완료되지 않은 멀티파트 업로드 삭제
- 현재 날짜 기준으로 실행

수명 주기 규칙 작업에서 [객체의 현재버전 만료], [객체의 이전버전 영구 삭제] 두가지 항목을 선택하면, 몇일 후에 삭제할 것인지를 설정할 수 있는 [객체 생성 후 경과 일수], [객체가 이전 버전이 된 후 경과 일수] 항목이 나타난다.

여기에 원하는 날짜를 각각 입력하고, [규칙 생성] 버튼을 클릭하면 된다.

위 사진에서 설정한 수명 주기 규칙을 보면 '현재 버전 작업'과 '이전 버전 작업'으로 나누어져 있는 것을 볼 수 있다.

앞서 S3 버저닝 기능과 함께 사용할수 있다고 언급한적이 있는데, S3의 경우 버저닝을 통해 객체 관리를 할 수 있으며, 수정을 할때마다 버전 표기를 하게 된다.

따라서 위의 수명주기 규칙은 다음과 같이 동작하게 된다.

S3 객체의 버저닝을 사용하지 않는 경우
- 현재 버전 작업에서 30일이나 지나 객체가 만료되면 그대로 삭제가 진행되게 된다.
S3 객체의 버저닝을 사용하는 경우
- 현재 버전 작업에서 30일이 지나면 객체가 만료되고 이전 버젼 작업으로 이동하게 된다.
  이전 버전 작업에서는 1일 후 버킷 삭제 규칙이 적용되어있으므로 즉, 31일 후 삭제되게 된다.
- 만일 객체 버전 작업이 30일, 이전 버전 작업이 40일로 설정되어 있다면, 실제로 버킷내에서 삭제되는 것은 30일+40일, 즉, 70일이 되게 된다.

최종 생성을 하게되면, 수명 주기 규칙 메뉴에 다음과 같이 Enabled 된 규칙 목록이 나오게 된다.

수명 주기 규칙 작동 시점
수명 주기 규칙이 생각한 것보다 늦게 작동하는 경우가 있다.
이는 Amazon S3가 객체의 전환 또는 만료(삭제) 날짜를 익일 자정(UTC)부터 계산하기 때문이다.
예를 들어 2020년 1월 1일 10:30(UTC)에 객체를 생성하고 3일 후 객체가 만료(삭제)되도록 수명 주기 규칙을 설정할 경우, 객체의 만료(삭제) 날짜는 2020년 1월 5일 00:00(UTC)이 된다.
따라서 수명 주기 규칙이 충족되었는지 확인하기 전에 충분한 시간이 경과했는지 확인해야 한다.

수명 주기 규칙 주의사항
* 직접 S3 버킷을 정리하는 것과 마찬가지로, 수명 주기 규칙을 생성 후 삭제가 되면 복구할 수 없다.
* 약 1년정도의 데이터가 있는 상태에서 30일 후 삭제 등의 규칙을 입력할 경우, 30일이 지난 모든 데이터(30일 초과 데이터는 모두 삭제되니 조심해야 한다.