grep

Engineering

데이터는 지웠는데 비용은 그대로? Aurora 스토리지 비용 최적화 하기

원티드

2025년 11월 20일

원문에서 보기 ↗

클라우드 서비스를 운영하다 보면 예상치 못한 비용 문제에 직면하곤 합니다. 특히 AWS Aurora와 같은 관리형 데이터베이스 서비스는 편리한 만큼 내부 동작 방식을 정확히 이해하지 못하면 불필요한 비용을 지불할 수 있습니다.

이번 글에서는 실제 데이터 사용량은 310GB에 불과했지만, 청구서에는 2TB의 비용이 발생하던 문제를 발견하고, Snapshot & Restore 방식을 통해 스토리지를 최적화하여 비용을 최적화한 과정을 공유합니다.

문제상황: 데이터는 지웠는데 비용은 그대로!?

모니터링 중 Aurora DB의 스토리지 비용이 비정상적으로 높게 유지되고 있는 것을 확인했습니다.

사용하지 않는 불필요한 데이터를 정리하기 위해 대량의 DELETE 작업을 수행했음에도 불구하고, AWS 콘솔상의 지표는 실제 사용하고 있는 데이터의 크기와 큰 차이가 있었습니다.

논리적 데이터 크기와 Volume 지표

일반적으로 데이터를 삭제하면 스토리지 사용량도 줄어들 것이라 기대하지만, 실제 VolumeBytesUsed 지표는 요지부동이었습니다. 즉, 사용하지 않는 약 1.7TB에 대해서도 매달 비용이 발생하고 있었습니다.

원인 분석: Aurora 스토리지 아키텍처의 비밀

왜 논리적인 데이터 삭제가 물리적인 스토리지 비용 감소로 이어지지 않았을까요? 이를 이해하기 위해서는 AWS Aurora의 독특한 스토리지 관리 방식과 Dynamic Resizing의 한계를 알아야 합니다.

Aurora는 스토리지를 미리 프로비저닝할 필요 없이, 데이터가 늘어남에 따라 10GB 단위의 청크(Chunk)인 ‘Protection Group’을 자동으로 추가하며 확장합니다.

“Your volume expands in increments of 10 GB up to a maximum of 128 TiB.” (볼륨은 10GB 단위로 최대 128TiB까지 확장됩니다.)

과거 Aurora는 한 번 늘어난 스토리지는 줄어들지 않는 ‘High Water Mark’ 방식을 사용하다가, 2020년 말 데이터를 삭제하면 스토리지 용량이 줄어드는 기능을 도입했습니다.

“The storage space allocated to your Amazon Aurora database cluster will now dynamically decrease when you delete data from the cluster.” (이제 Aurora DB 클러스터에서 데이터를 삭제하면 할당된 스토리지 공간이 동적으로 감소합니다.)

하지만 결정적인 문제 는 반환 조건에 있습니다. AWS Aurora는 내부적으로 10GB 단위의 블록이 완전히 비워져야만 해당 공간을 반환합니다. DELETE 쿼리로 데이터를 지우더라도, 데이터가 디스크 곳곳에 흩어져 저장된 파편화(Fragmentation) 상태라면 10GB 블록 내에 빈 공간(Hole)만 생길 뿐, 블록 자체가 사라지지 않아 비용이 줄어들지 않는 현상이 발생합니다.

“A table is stored internally in one or more contiguous fragments of varying sizes… While running TRUNCATE TABLE operations, the space is reusable and not reclaimable.” (단순히 데이터를 지운다고 해서 파편화된 공간이 즉시 반환되지 않을 수 있습니다.)

해결 과정: Snapshot & Restore 전략

클러스터 재생성을 통해서 스토리지를 재할당 받는 방법을 통해서 Volume 사용량을 줄이는 방식을 선택했습니다.

스냅샷의 크기가 크더라도, Aurora의 스냅샷 Restore는 기존 클러스터의 물리적 디스크를 그대로 복사하는 것이 아니라, 데이터 페이지를 기반으로 새로운 스토리지 볼륨을 생성 하는 작업입니다. 새로운 클러스터는 현재 실제 데이터의 양을 기준으로 스토리지를 다시 할당하기 때문에 비용 최적화가 가능합니다.

작업순서는 다음과 같습니다.

  1. 관련 서비스 중단
  2. DB snapshot 생성: 현재 운영 중인 Aurora Cluster의 스냅샷을 생성합니다.
  3. Snapshot을 이용한 신규 클러스터 생성: 스냅샷을 기반으로 새로운 클러스터를 생성합니다. 이 시점에 스토리지는 파편화가 제거된 상태로 할당됩니다.
  4. 데이터 검증: 파라미터 그룹, 보안 그룹 등 설정이 올바른지 확인하고 데이터 무결성을 점검합니다.
  5. 서비스 재시작: 애플리케이션의 DB Endpoint를 신규 클러스터로 변경하고 서비스를 재시작합니다.

최종 결과

작업 완료후 CloudWatch의 VolumeBytesUsed 지표와 청구되는 비용에 큰변화가 있었습니다.

신규 Cluster의 VolumeBytesUsed 지표

최적화 이전 스토리지관련 일일 비용

최적화 이후 스토리지관련 일일 비용

불필요하게 점유되어 있던 약 1.7TB 이상의 공간을 반환함으로써, 실제 사용하는 데이터 양에 합당한 비용 구조를 갖추게 되었습니다.

실제로 청구되는 비용이 약86% 감소하면서 월 약$550 이상의 비용을 아낄수 있었습니다.

마치며

Aurora의 “사용한 만큼만 지불한다”는 개념은 참 매력적이지만, “지운 만큼 즉시 줄어든다”는 것을 보장하지는 않습니다. 특히 DELETE 위주의 데이터 관리를 하고 있다면 데이터 파편화로 인한 스토리지 비용 낭비가 없는지 주기적으로 확인해 볼 필요가 있습니다.

만약 VolumeBytesUsed와 실제 데이터 크기의 괴리가 크다면, Snapshot & Restore를 통한 클러스터 리프레시가 가장 확실한 비용 절감 솔루션이 될 것입니다.

Reference