AWS S3 Intelligent Tiering – Deep Archive 사용 후기
S3 비용 최적화를 하다가 겪게 된 일이다.
어느날 나는 지속적으로 과금되고 있는 S3 저장 요금에 대해 관심을 가지게 된다.
과거의 온프레미스 환경에서는 저장요금이라는 개념이 없었다.
적당한 사양의 SAS 15K 디스크 2개 구매해서 RAID 1 구성해두면 5년 이상은 끄떡없이 사용할 수 있었다.
유지비용으로 전기 요금만 지불하면 되었다.
< 서버 하드디스크는 이런 모양으로 생겼습니다 >
하지만 요즘은 인프라 또한 클라우드 서비스를 이용하는 시대라서, 저장 서비스에 대한 비용을 지불해야 한다.
S3는 데이터를 보관하는 방식에 따라서 저장 유지 비용이 달라진다.
S3 Storage Class
- Standard : 매우 높은 고가용성과 복제 (3개 이상의 AZ에 복제)
- OneZone : 매우 높은 고가용성과 복제 (1개 AZ에서 구동)
- Glacier : 매우 높은 고가용성과 복제 (3개 이상의 AZ에 복제, 하지만 디스크의 성능이 낮음)
- Intelligent Tiering : 위의 것들을 자동 분류
크게 위 4가지 종류이고, 파생된 유사한 스토리지 클래스가 몇 개 더 존재한다.
S3 Intelligent-Tiering이란?
대부분의 서비스에서, 자주 이용되는 파일과, 드물게 이용되는 파일을 구분하기 어렵다.
모든 데이터가 hot 하게 사용되지는 않기 때문에, 이 비용을 줄이는 노력을 해야 한다.
비록 스토리지 클래스 이론을 알고 있더라도, 상용 환경에서 응용하기란 매우 어렵다.
따라서 AWS는 지난 2018년 11월에 S3 Intelligent-Tiering 이라는 서비스를 출시했다.
이 스토리지 클래스를 사용하면, S3 에서 사용빈도를 자동으로 계산해서 적절한 Tier로 변경한다.
스토리지 클래스(Storage Class)는 고정이며, 그 내부적으로 Tier 라는 속성이 추가되는 것이다.
굳이 비유하자면 Apple Fusion Drive 이다.
SSD 와 HDD 를 결합해서 하나의 논리적 디스크로 만들고, 사용하는 파일은 자동으로 SSD 로 옮겨져서 동작하고, 사용하지 않는 파일은 HDD 로 저장소가 이동하는 것이다.
- S3 Intelligent-Tiering 파일 모니터링 비용 : 10만개당 3천원 정도. 즉, 무시해도 될 수준
- S3 Intelligent-Tiering은 30일 연속 액세스되지 않은 객체를 Infrequent Access 계층으로 이동하여 비용을 절감합니다.
- 90일 동안 액세스하지 않은 객체는 Archive Instant Access 계층으로 이동하여 비용을 절감합니다.
객체에 나중에 액세스하는 경우 S3 Intelligent-Tiering은 객체를 다시 Frequent Access 계층으로 이동합니다.
실제로 사용해 보면 위 표와 같이 동작한다.
파일의 모니터링 값은 임의로 변경할 수 없다. 즉, 모든 파일은 반드시 FA -> IA -> AIA 순서로 전환된다.
그리고 공식문서를 보면 혼동할 수도 있는데, 실제로 IA -> AIA 전환은 IA 전환 후 90일이 아니라 60일 후에 바뀐다. (아마도 공식문서는 FA 부터 카운트 하는 것 인듯하다.)
하위 티어에서 파일 접근이 일어나면, 파일은 즉시 응답되고 FA 티어로 올라간다.
파일 데이터 접근(GetObject/CopyObject)에 대해서 티어 상승이 일어나지만, 데이터를 접근하지 않는 MetaData 조회나 Tagging 등은 티어 상승이 일어나지 않습니다.
수동으로 계산하자면, 파일 업로드 후 4주 + 1일 (업로드 한 날짜부터 1일 이니까, 1 + 28 + 1 = 30) 에 FA->IA 로 전환된다. (달력기준, 아래로 4칸 오른쪽으로 1칸)
8주 + 4일 (56일 + 4일) 에 IA -> AIA 로 전환된다. (달력기준, 아래로 8칸 오른쪽으로 4칸)
그리고 S3 에는 다음과 같은 옵션이 존재한다.
90일 이상 사용하지 않아서 AIA Tier 가 된 파일은 이것을 설정해서 비용을 더 줄일 수 있습니다!
결론부터 말하자면 AIA 보다 더 낮은 티어가 되면 파일이 불능 상태가 된다.
나도 파일 불능 상태를 경험해 보고 싶지 않았다.
AIA 보다 하위 티어에는, Archive Access(AA), Deep Archive Access(DAA) 가 존재한다.
이해를 돕기 위해서 비용을 % 계산해 보았다.
Archive Access(AA), Deep Archive Access(DAA)가 되면 파일이 저사양 디스크로 이동된다.
이 경우 AA, DAA 파일을 GetObject 하기 위해서는 반드시, RestoreObject (즉, 아카이브 취소) 를 해야 한다.
아카이브 티어링은, Intelligent-Tiering 스토리지 클래스에 종속된 Tier 이지만, 아카이브 된 파일은 접근이 일어날 경우에도 자동으로 FA 로 승격이 되지 않는다.
왜냐하면 “데이터” 가 읽혀지지 되지 않았기 때문이다. 스토리지 학문에서, 데이터를 디스크에서 읽는 것을 검색(Search)이라고 하더라. (알기쉽게 비유하자면 data retrieval = search)
AA 의 파일은 RestoreObject 에 3~5시간이 걸린다. (내가 테스트 해 본 결과 4시간 걸리더라)
DAA 의 파일은RestoreObject 에 12시간이내 시간이 걸린다. (내가 테스트 해 본 결과 10시간 걸리더라)
AA에 180일, DAA에 365일 설정했으나, 어떤 이슈가 생겼고, 잠시 고민한 결과 아카이브 된 파일을 모두 되돌리기로 결정했다.
새로운 속성인 ArchiveStatus 는 head-object 로만 확인할 수 있다.
그 외 메소드에서 확인이 불가능 하기 때문에, list-objects-v2 를 통한 아카이브 상태 조회는 불가능하다.
즉, 아카이브 인지 확인하려면 list-objects-v2 후 head-object 해야 한다. (매우 과다한 over head 발생)
aws s3api head-object --bucket mybucket --key test1/video.mp4
{
"AcceptRanges": "bytes",
"ArchiveStatus": "ARCHIVE_ACCESS",
"LastModified": "2024-04-22T09:57:15+00:00",
"ContentLength": 577061483,
"ETag": "\"dae624aead3594d3783d202eb082f87c\"",
"VersionId": "KdZeOl2m._E.ixV9_3aXucV8gNQHKrl.",
"ContentType": "video/mp4",
"ServerSideEncryption": "AES256",
"Metadata": {},
"StorageClass": "INTELLIGENT_TIERING"
}
복원 명령어
aws s3api restore-object --bucket mybucket --key test1/video.mp4 --restore-request '{}'
list-object 후 전부 restore-object 요청하는 명령어
aws s3api list-objects-v2 --bucket mybucket --query "Contents[?StorageClass=='INTELLIGENT_TIERING']" --prefix test1 \
--output text | \
awk -F $'\t' '{print $2}' | \
tr '\n' '\0' | \
xargs -L 1 -0 \
aws s3api restore-object \
--restore-request '{}' \
--bucket mybucket \
--key
파일 복원도 (10시간 정도) 오래 걸릴 뿐만 아니라, restore-object 복원 요청하는 것도 오래 걸리더라.
SA는 문제가 생겼을때, 헤메지 않고 한번에 짧은 시간내에 문제를 해결해야 하는데, 이때 노답 상태라서 살짝 맨탈붕괴 이었다.
해결책
S3 관리기능중에 Inventory 라는 것이 있는데, 이것을 설정한다.
설정 할 때, [스토리지 클래스], [지능형 계층화: 액세스 계층] 메타 데이터 추가할 것.
그 Inventory 파일을 S3 Batch 에 입력하면 한번에 restore 할 수 있다.
장애 발생 후, 조치까지 하루 이상의 시간이 걸렸었다.
가장 최적의 방법으로 처리했었지만, 완료 될 때까지 끔찍한 경험이었다.
이때, 복원해야 할 파일 수는 113만개 이었다. cli로 계속 처리를 시도했다면 더 오래 걸렸을 것이다.
나중에 확인한 사항인데 AIA 의 뜻이 Archive Infrequent Access 이 아니라 Archive Instant Access 이더라.
저 Instant 라는 단어가 이런 의미였었구나..