지난달 인프라 비용 정산 미팅에서 AWS 청구서를 열었을 때, 가장 눈에 띄는 항목은 EC2가 아닌 스토리지 비용이었습니다. 서비스 초기에는 무시할 수 있을 만큼 작았던 로그 데이터와 사용자 업로드 이미지들이 3년이라는 시간을 거치며 수백 테라바이트(TB) 규모의 '디지털 쓰레기'로 변해 있었기 때문입니다. 특히 액세스 로그(Access Log)와 배포 아티팩트가 저장된 s3 버킷은 누구도 읽지 않지만 매달 수천 달러의 비용을 발생시키고 있었습니다.
단순히 "오래된 파일을 지우자"는 접근은 위험했습니다. 컴플라이언스 이슈로 1년간 보관해야 하는 로그도 있었고, 가끔 고객 문의 대응을 위해 3개월 전 데이터를 조회해야 하는 경우도 있었기 때문입니다. 이 글에서는 무작정 데이터를 삭제하지 않고, 데이터의 접근 빈도(Access Pattern)에 따라 스토리지 클래스를 자동으로 변경하여 비용을 최적화한 경험을 공유합니다. 특히 무턱대고 Glacier로 보냈다가 오히려 비용이 증가했던 실패 사례도 함께 다룹니다.
데이터 온도(Temperature) 분석과 스토리지 클래스
문제 해결의 첫 단계는 데이터의 '온도'를 파악하는 것입니다. 제가 운영하던 미디어 처리 시스템은 전형적인 롱테일(Long-tail) 접근 패턴을 보였습니다. 업로드 직후 7일간은 빈번하게 호출되지만(Hot), 30일이 지나면 거의 접근이 없고(Warm), 90일이 지나면 감사(Audit) 목적으로만 존재하는(Cold) 데이터였습니다.
하지만 당시 모든 객체는 가장 비싼 S3 Standard 클래스에 저장되어 있었습니다. AWS 공식 문서를 확인해보면 클래스별 비용 차이는 극명합니다. Standard 대비 S3 Standard-IA(Infrequent Access)는 약 40% 저렴하며, S3 Glacier Deep Archive는 무려 95% 이상 저렴합니다.
우리의 목표는 명확했습니다. 수동으로 파일을 옮기는 것이 아니라, 객체의 생성일(Age)을 기준으로 자동으로 클래스를 변경하는 '수명 주기 규칙(Lifecycle Rule)'을 적용하는 것입니다. 하지만 이 과정에는 치명적인 함정이 숨어 있었습니다.
실패 사례: 작은 객체(Small Object)의 역습
처음에는 단순히 "모든 데이터를 30일 후에 Glacier로 옮기자"는 나이브(Naive)한 접근을 시도했습니다. 이론상으로는 완벽해 보였지만, 적용 후 다음 달 청구서에서 'Lifecycle Transition Request' 비용이 폭발하는 사태가 발생했습니다.
s3의 수명 주기 전환(Transition)은 객체당 요청 비용이 발생합니다. 또한, Intelligent-Tiering이나 Standard-IA와 같은 클래스는 최소 객체 크기(128KB) 제약이 있거나, 128KB 미만의 객체에 대해서는 128KB 용량만큼 과금하는 정책이 있습니다. 즉, 10KB짜리 로그 파일 100만 개를 IA로 옮기면, 스토리지 절감액보다 전환 요청 비용(Request Fee)과 오버헤드 요금이 더 많이 나오는 '배보다 배꼽이 더 큰' 상황이 벌어집니다. 이 실패를 통해 반드시 객체 크기 필터링이 필요하다는 것을 깨달았습니다.
Terraform을 활용한 최적화된 수명 주기 정책
실패를 교훈 삼아 재설계한 아키텍처는 다음과 같습니다. Terraform을 사용하여 인프라를 코드로 관리(IaC)하고 있으며, 작은 파일에 대한 예외 처리를 포함했습니다.
- 접두사(Prefix) 필터링:
logs/와images/경로에만 규칙 적용. - 객체 크기 제한: 128KB 미만 파일은 전환 대상에서 제외하거나 만료(삭제) 규칙만 적용.
- 계층적 전환: Standard → Standard-IA (30일) → Glacier Deep Archive (90일) → 삭제 (365일).
// resource "aws_s3_bucket_lifecycle_configuration" 예제
// 테라폼(Terraform) 버전에 따라 문법이 다를 수 있으니 확인이 필요합니다.
resource "aws_s3_bucket_lifecycle_configuration" "bucket-config" {
bucket = aws_s3_bucket.main.id
rule {
id = "log-management-rule"
status = "Enabled"
// 중요: 128KB 미만 객체는 전송 비용 이슈로 전환하지 않도록 필터링
filter {
and {
prefix = "logs/"
object_size_greater_than = 131072 // 128KB
}
}
// 30일 후 IA로 전환 (즉시 액세스 가능, 비용 절감)
transition {
days = 30
storage_class = "STANDARD_IA"
}
// 90일 후 Glacier Deep Archive로 전환 (꺼내는데 12시간 소요, 압도적 저렴)
transition {
days = 90
storage_class = "DEEP_ARCHIVE"
}
// 1년(365일) 후 영구 삭제
expiration {
days = 365
}
}
// 버전 관리(Versioning)가 켜진 버킷을 위한 삭제 마커 정리 규칙
rule {
id = "cleanup-delete-markers"
status = "Enabled"
filter {
prefix = ""
}
expiration {
expired_object_delete_marker = true
}
noncurrent_version_expiration {
noncurrent_days = 7
}
}
}위 코드에서 특히 주목해야 할 부분은 object_size_greater_than 설정입니다. 이 설정을 통해 작은 파일들이 불필요하게 클래스 이동을 겪으며 비용을 발생시키는 것을 원천 차단했습니다. 또한, 버전 관리가 활성화된 버킷의 경우, 파일을 삭제해도 Delete Marker가 남아 공간을 차지하거나, 이전 버전(Noncurrent Version)이 계속 비용을 발생시킵니다. 이를 해결하기 위해 noncurrent_version_expiration 설정을 추가하여 덮어쓰기 되거나 삭제된 지 7일이 지난 구버전 데이터는 완전히 제거하도록 했습니다.
| 항목 | 기존 (S3 Standard Only) | 최적화 후 (Lifecycle 적용) | 비고 |
|---|---|---|---|
| 스토리지 비용/GB | $0.023 | $0.00099 (Deep Archive 기준) | 약 95% 단가 하락 |
| 전환 비용 (100만 객체) | $0 | $50 (일회성) | 필터링으로 최소화 |
| 월 예상 총 비용 (50TB) | 약 $1,150 | 약 $380 | 67% 비용 절감 |
위 테이블은 실제 50TB 규모의 로그 버킷에 해당 정책을 적용했을 때의 전후 비교 시뮬레이션입니다. 초기 전환 비용이 발생하지만, 적용 첫 달부터 손익분기점을 넘겼으며 3개월 차부터는 60% 이상의 비용 절감 효과가 지속되었습니다. AWS 비용 계산기를 통해 사전 시뮬레이션을 돌려보면 여러분의 워크로드에 맞는 정확한 수치를 얻을 수 있습니다.
AWS 공식 수명 주기 가이드 확인주의사항: 언제 사용하면 안 되는가?
이 설정이 만병통치약은 아닙니다. 수명 주기 정책 적용 시 반드시 고려해야 할 엣지 케이스(Edge Cases)들이 있습니다.
첫째, 데이터 검색 시간(Retrieval Time)입니다. Glacier나 Deep Archive로 넘어간 데이터는 즉시 읽을 수 없습니다. 데이터를 복원(Restore)하는 데 최소 몇 분에서 최대 12시간이 걸립니다. 실시간 분석이 필요한 데이터라면 절대 Archive 계열로 보내서는 안 됩니다. 실시간성이 중요하지만 접근 빈도만 낮다면 Intelligent-Tiering이 더 나은 대안이 될 수 있습니다.
둘째, 최소 보관 기간(Minimum Storage Duration) 위약금입니다. S3 Standard-IA는 30일, Glacier는 90일의 최소 보관 기간이 있습니다. 만약 데이터를 IA로 옮긴 후 5일 만에 삭제한다면, 남은 25일치에 대한 요금이 패널티로 부과됩니다. 수명이 극도로 짧은 임시 파일(Temporary Files)에는 수명 주기 전환 규칙보다는 단순 만료(Expiration) 규칙을 사용하는 것이 경제적입니다.
결론
클라우드 비용 최적화는 한 번의 설정으로 끝나는 작업이 아닙니다. s3 수명 주기 관리는 데이터의 가치 변화에 맞춰 비용을 통제할 수 있는 가장 강력한 도구입니다. 하지만 잘못된 설정은 오히려 요청 비용 폭탄이나 데이터 접근 지연을 초래할 수 있습니다. 본문에서 다룬 '작은 객체 필터링'과 '단계별 전환 전략'을 여러분의 프로젝트에 맞게 변형하여 적용한다면, 성능 저하 없이 극적인 비용 절감을 경험할 수 있을 것입니다.
Post a Comment