티스토리 뷰
tagging을 사용하여 S3 lifecycle을 적용하는 방법과 고려해야할 사항들을 정리한다.
lifecycle을 사용하여 특정 날짜나 기간을 기준으로 삭제 또는 스토리지 class변경이 가능하다. S3 스토리지 class 종류는 다양하다. 종류에 따라 용도가 다르고 비용도 달라 알맞은 스토리지 class를 사용해야한다.
S3 스토리지 class 종류
- S3 Standard
- 짧은 지연 시간 및 높은 처리량 성능
- 자주 액세스하는 데이터를 위해 높은 내구성, 가용성 및 성능을 갖춘 객체 스토리지
- S3 Intelligent-Tiering
- 성능 영향 또는 운영 오버헤드 없이 가장 비용 효과적인 액세스 계층으로 데이터를 자동으로 이동하여 비용을 최적화하기 위해 설계
- S3 Standard-IA(S3 Standard-Infrequent Access)
- 낮은 비용과 높은 성능의 조합을 제공하는 S3 Standard-IA는 장기 스토리지, 백업 및 재해 복구 파일용 데이터 스토어에 이상적
- S3 One Zone-IA(S3 One Zone-Infrequent Access)
- 최소 3개의 가용 영역(AZ)에 데이터를 저장하는 다른 S3 스토리지 클래스와는 달리, S3 One Zone-IA는 단일 AZ에 데이터를 저장하여 비용이 저렴
- S3 Standard 또는 S3 Standard-IA 스토리지와 같은 가용성 및 복원력이 필요 없는 고객에게 적합
- S3 Glacier
- 데이터 보관을 위한 안전하고 내구력 있으며 저렴한 스토리지 클래스
- 몇 분부터 몇 시간까지 구성 가능한 검색 시간
- S3 Glacier Deep Archive
- 7-10년 동안 유지되는 데이터의 장기 보관을 위해 설계된 최저 비용 스토리지 클래스
- 12시간 이내의 검색 시간
- S3 on Outposts
- 온프레미스 AWS Outposts 환경에 객체 스토리지를 제공
lifecycle
S3 lifecycle을 사용하여 스토리지 class 전환 작업 또는 객체 만료 작업을 할 수 있다.
제한사항
-
객체를 S3 Standard 또는 S3 Standard-IA 스토리지 클래스에서 S3 Standard-IA 또는 S3 One Zone-IA 스토리지 클래스로 전환하기 전에 객체를 S3 Standard 스토리지 클래스에 30일 이상 보관해야 합니다.
-
128KB보다 작은 객체는 비용 효율적이지 않으므로 Amazon S3는 이러한 객체를 전환하지 않습니다.
-
S3 Standard 또는 S3 Standard-IA 스토리지 클래스에서 S3 Intelligent-Tiering로의 전환.
-
S3 Standard 스토리지 클래스에서 S3 Standard-IA 또는 S3 One Zone-IA로의 전환.
-
tagging으로 S3 스토리지 클래스 변경
구현방법
Lifecycle은 S3 bucket 단위로 설정할 수 있고 prefix, tagging을 설정하여 filtering이 가능하다.
tagging은 console에서 object를 클릭하여 객체 작업
창의 태그 편집
으로 할 수 있다. sdk를 사용하는 경우 putObjectTagging
함수를 사용할 수 있다.
추가 고려사항
- S3의 스토리지 클래스를 변경하여도 S3 object의 key가 변경되지 않는다.
- S3 folder에는 tagging을 할 수 없고 폴더 단위로 tagging을 할 수는 없었다.(folder 단위로 tagging을 하려면 sdk를 사용하여 구현해야한다.)
- object에 tagging을 하면 최종 수정일이 변경되지 않는다. 따라서 tagging을 설정한 날짜를 기준으로 lifecycle이 적용되는 것이 아니라 metadata 수정, cp 등 object 변경사항이 있었던 날짜를 기준으로 lifecycle이 적용된다.
Amazon S3는 각 객체에 대해 최종 수정일만 유지합니다. Amazon S3 콘솔은 객체의 속성 창에 최종 수정일을 표시합니다. 새 객체를 처음 생성할 때 이 날짜는 객체가 생성된 날짜가 되고, 객체를 변경하면 날짜도 이에 따라 바뀝니다. 따라서 생성일은 최종 수정일과 같은 날짜가 됩니다.
결론
sdk를 사용하여 s3 object를 delete하던 로직을 tagging으로 변경하여 lifecycle을 적용했다. Delete operation 보다 가벼운 tagging 형식으로 변경하여 성능의 향상을 이룰 수 있었다. 또한 object를 바로 삭제하지 않아서 error가 발생하여 object를 복원하는 로직이 간결해졌다.
Reference
'develop' 카테고리의 다른 글
VPC AWS ElasticSearch Service로 Cognito 인증 접근 (0) | 2021.02.05 |
---|---|
Airflow 기본 시용법 정리 (0) | 2021.01.22 |
VPC 내부 Neptune DB 클러스터 접근을 위한 리버스 프록시 서버 구성 (0) | 2020.09.18 |
AWS WAFv2(terraform 작성 예시) (0) | 2020.08.27 |
pagination 구현 시 고려사항 및 Cursor-based pagination 구현 (0) | 2020.08.20 |
- Total
- Today
- Yesterday
- mognodb
- aws
- Airflow
- graphql
- JavaScript
- Lifecycle
- Cloudfront
- typescript
- Elasticsearch
- AWS community day seoul
- Clickjacking
- sementic version
- shorten
- conventional commit
- lambda@edge
- Cognito
- pagination
- Python
- NLP
- slowquery
- Neptune
- commit message
- mongoDB
- inversify
- Terraform
- nginx
- Prisma
- Develop
- nltk
- Github Actions
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |