지난달 프로덕션 환경의 AWS 비용 청구서를 열어보고 등골이 서늘했던 경험이 있습니다. EC2 인스턴스 비용은 예상 범위 내였지만, S3 스토리지 비용이 전월 대비 200% 가까이 폭증했기 때문입니다. 로그 데이터와 유저가 업로드한 미디어 파일이 테라바이트(TB) 단위로 쌓이면서, 기본 설정인 'S3 Standard' 클래스의 높은 단가가 누적된 결과였습니다. 단순히 "오래된 데이터를 지우자"는 접근은 컴플라이언스(보존 의무) 문제로 불가능했습니다. 이 글에서는 100TB 규모의 데이터를 운영하며 겪었던 시행착오와, AWS S3 Storage Classes를 전략적으로 배합하여 성능 저하 없이 비용을 40% 이상 절감한 구체적인 엔지니어링 과정을 공유합니다.
S3 비용 구조의 함정: Standard가 정답이 아닌 이유
초기 스타트업이나 프로젝트 초기 단계에서는 대부분의 S3 버킷을 생성할 때 기본값(Default)인 S3 Standard를 사용합니다. 이 클래스는 밀리초(ms) 단위의 액세스 속도와 높은 내구성을 제공하지만, GB당 스토리지 비용이 가장 비쌉니다. 저희 팀이 운영하던 로그 수집 시스템(Fluentd -> S3)은 하루에 약 500GB의 로그를 적재하고 있었는데, 분석은 주로 최근 7일 치 데이터에 집중되었습니다.
문제의 핵심은 "접근 빈도(Access Frequency)는 급격히 떨어지는데, 스토리지 비용은 동일하게 지불하고 있다"는 점이었습니다. 생성된 지 30일이 지난 로그 파일에 액세스할 확률은 1% 미만이었지만, 우리는 여전히 가장 비싼 Standard 요금을 내고 있었던 것입니다.
실패한 접근: 무조건적인 Glacier 전환의 역효과
처음에는 단순히 "안 쓰는 데이터는 다 얼려버리자"는 생각으로, 30일이 지난 모든 객체를 S3 Glacier Flexible Retrieval로 전환하는 배치 스크립트를 작성했습니다. 이론상으로는 비용이 1/10로 줄어들어야 했습니다.
하지만 며칠 뒤, 긴급한 보안 감사 이슈로 인해 2달 전 로그를 전수 조사해야 하는 상황이 발생했습니다. Glacier에 있는 수만 개의 객체를 복원(Restore)하는 과정에서 두 가지 치명적인 문제가 터졌습니다.
- 복원 시간(Retrieval Time): 데이터가 사용 가능해질 때까지 4~12시간을 기다려야 했습니다.
- 복원 비용(Retrieval Cost): Glacier는 저장 비용은 싸지만, 데이터를 꺼낼 때 발생하는 요청 비용과 데이터 전송 비용이 비쌉니다. 대량 복원을 수행하니 절약한 보관 비용보다 복원 비용이 더 나오는 배보다 배꼽이 더 큰 상황이 발생했습니다.
해결책: Intelligent-Tiering과 Lifecycle Policy의 이원화
이 문제를 해결하기 위해 데이터의 성격을 두 가지로 분류하고, 각각 다른 전략을 적용했습니다.
- 예측 불가능한 데이터 (User Uploads): 액세스 패턴을 알 수 없으므로 S3 Intelligent-Tiering을 적용. AWS가 자동으로 모니터링하여 계층을 이동시킴.
- 예측 가능한 데이터 (System Logs): 생성 시점 기준으로 가치가 하락하므로 명확한 Lifecycle Policy 적용.
다음은 Terraform을 사용하여 로그 데이터 버킷에 적용한 수명 주기(Lifecycle) 정책의 예시입니다. 30일 후 Standard-IA로, 90일 후 Glacier Instant Retrieval로, 1년 후 Deep Archive로 이동하며, 3년 후 삭제합니다.
// resource "aws_s3_bucket_lifecycle_configuration" "log_bucket_config"
resource "aws_s3_bucket_lifecycle_configuration" "bucket-config" {
bucket = aws_s3_bucket.log_bucket.id
rule {
id = "log-archive-policy"
status = "Enabled"
// 30일 경과: 자주 액세스하지 않지만 즉시 접근 필요 (Standard-IA)
transition {
days = 30
storage_class = "STANDARD_IA"
}
// 90일 경과: 밀리초 단위 접근이 필요하지만 빈도 매우 낮음 (Glacier IR)
transition {
days = 90
storage_class = "GLACIER_IR"
}
// 365일 경과: 거의 볼 일 없음, 규제 준수용 (Deep Archive)
transition {
days = 365
storage_class = "DEEP_ARCHIVE"
}
// 3년(1095일) 경과: 데이터 영구 삭제
expiration {
days = 1095
}
}
}위 코드에서 주목해야 할 부분은 GLACIER_IR (Instant Retrieval)의 도입입니다. 기존 Glacier와 달리 밀리초 단위의 액세스가 가능하면서도 Standard 대비 약 68% 저렴합니다. 드물게 발생하는 로그 검색 요구사항을 충족시키면서 비용을 최적화하는 'Sweet Spot'이었습니다.
비용 절감 효과 비교 분석
정책 적용 후 3개월간 모니터링한 결과를 바탕으로 비용 변화를 분석했습니다. 데이터 양은 100TB로 가정했을 때의 월간 추정 비용입니다 (서울 리전 기준, 대략적 수치).
| 스토리지 클래스 | GB당 비용 (월) | 100TB 기준 월 비용 | 특이사항 |
|---|---|---|---|
| S3 Standard | $0.023 | $2,300 | 기준점 (최적화 전) |
| S3 Standard-IA | $0.0125 | $1,250 | 약 45% 절감, 최소 30일 저장 |
| Glacier IR | $0.004 | $400 | 약 82% 절감, 밀리초 액세스 |
| Deep Archive | $0.00099 | $99 | 약 95% 절감, 복원 시간 필요 |
저희 팀은 계층화 전략을 통해 전체 스토리지 비용을 약 42% 절감했습니다. 특히 Intelligent-Tiering을 적용한 유저 업로드 버킷의 경우, 우리가 미처 파악하지 못했던 'Long-tail' 데이터들이 자동으로 Archive Access Tier로 이동하면서 예상보다 큰 절감 효과를 보았습니다.
AWS 공식 S3 요금표 확인하기주의사항: 작은 객체와 최소 보존 기간
이 전략을 모든 버킷에 무분별하게 적용해서는 안 됩니다. 특히 다음 두 가지 경우에는 오히려 비용이 증가하거나 효율이 떨어질 수 있습니다.
따라서 썸네일이나 임시 파일과 같이 수명 주기가 매우 짧거나 크기가 작은 객체가 많은 버킷은 S3 Standard를 유지하거나, 별도의 필터링 규칙을 적용해야 합니다.
결론 (Conclusion)
AWS S3 비용 최적화는 단순히 "저렴한 스토리지로 옮기는 것"이 아닙니다. 데이터의 라이프사이클을 이해하고, 액세스 패턴을 분석하여 적재적소에 배치하는 엔지니어링입니다. 무작정 Glacier로 보내기보다는 Intelligent-Tiering을 통한 자동화나, Glacier Instant Retrieval 같은 하이브리드 옵션을 적극적으로 검토해 보시기 바랍니다. 작은 설정의 변화가 클라우드 비용 명세서에는 극적인 변화를 가져다줄 것입니다.
Post a Comment