RDB에서 S3 + Athena로 전환할 때, 비용을 어떻게 계산했나

데이터가 어느 정도 쌓이면 한 번씩 "이거 한 달에 얼마 쓰는 거예요?" 하는 질문이 들어온다. 우리도 그랬다.

운영 DB에 분석 데이터까지 다 쌓아두던 시절엔 분석 쪽 비용도 그냥 Aurora 비용 안에 묻혀 있었다. 그러다 DB가 2TB를 넘기기 시작하면서 "분석용 데이터까지 비싼 Aurora 스토리지에 굳이 둘 필요 있나?" 하는 얘기가 나왔다. 거기서부터 S3 + Athena 전환을 검토하기 시작했다.

이번엔 그때 우리가 비용을 어떻게 비교해봤는지 정리해보려고 한다. 정확한 청구서는 공개 못 하니까 단가 기준으로 얘기할 거다.

비용 구성 비교

먼저 두 환경의 비용이 어디서 나오는지부터 정리해보자.

Aurora MySQL 비용 구조:

• 스토리지: GB당 월 약 $0.10
• I/O 비용: 요청당 별도 과금
• 인스턴스: 항상 켜져 있어야 함 (시간당 과금)
• 백업: 별도

S3 + Athena 비용 구조:

• S3 스토리지: GB당 월 약 $0.023 (Standard 기준)
• Athena 쿼리: 스캔한 데이터 1TB당 약 $5
• 인스턴스 비용 없음, 백업 비용 없음

이걸 옆에 놓고 보면 답 나온다. 단순 스토리지만 비교해도 4배 정도 차이. 거기에 Aurora는 I/O랑 인스턴스 비용이 추가로 들고, 백업까지 더하면 격차는 더 벌어진다.

진짜 차이는 Parquet에서 났다

근데 사실 진짜 큰 차이는 다른 데서 났다. 바로 데이터 포맷.

운영 DB에 있을 땐 row-based 형식이고, 우리 환경에서 약 2TB 정도였다. 이걸 그대로 S3에 옮기면 그대로 2TB. 그러면 절감 효과는 스토리지 단가 차이 정도, 약 4배.

근데 Parquet으로 변환하면 얘기가 달라진다. 우리 케이스에선 원본의 약 25% 수준까지 줄었다. 2TB가 500GB쯤 된 거다. Parquet은 컬럼 기반 압축이라 반복되는 값(국가 코드, status 같은 enum류)이 많을수록 압축률이 잘 나온다.

스토리지 비용 다시 계산해보자.

• Aurora 2TB: 월 약 $200
• S3 Parquet 500GB: 월 약 $11.5

약 17배 차이. 처음엔 "한 10배쯤 싸지겠지" 정도로 봤는데, 실제로는 데이터 특성에 따라 그것보다 더 벌어지기도 한다.

Athena 쿼리 비용이 변수

근데 여기서 끝이 아니다. 분석 환경에서 정작 무서운 건 쿼리 비용이다.

Athena는 스캔한 데이터량에 비례해서 과금한다. 1TB 스캔하면 $5. 숫자만 보면 싸 보이는데, 데이터 마트 환경에서 누가 풀스캔 쿼리 한 번 잘못 돌리면 그거 하나로 몇 달러가 그냥 나간다.

도입하고 며칠 모니터링해보니 보이더라. 분석가 한 명이 잘못 짠 쿼리로 하루에 수십 달러 태우는 케이스도 있었다.

그래서 파티셔닝이 결국 필수가 된다.

Hive 파티셔닝으로 스캔 범위 제한

우리는 S3에 데이터를 적재할 때 사용자 ID 기반으로 Hive 파티셔닝을 걸었다.

s3://our-bucket/user_activity/
  user_id_prefix=00/
    data.parquet
  user_id_prefix=01/
    data.parquet
  ...

이렇게 디렉터리 구조로 나눠두면 Athena 쿼리에 WHERE user_id_prefix = '03' 조건만 들어가도 다른 파티션은 아예 스캔을 안 한다.

처음엔 날짜 기반 파티셔닝도 같이 고민했는데, 우리 분석 쿼리는 거의 다 특정 사용자 그룹 대상이라 user_id 쪽이 더 잘 맞았다. 이건 케이스마다 다르다. 시계열 분석이 주력이면 날짜 파티션이 맞을 거고.

파티셔닝 적용 전후를 비교해보면 평균 쿼리 스캔량이 약 1/10 수준으로 줄었다. 쿼리 한 번에 $5 나오던 게 $0.5 정도로. 분석가들이 그제서야 부담 없이 쿼리 돌릴 수 있게 됐다.

트레이드오프와 주의점

물론 좋은 점만 있는 건 아니다. 우리가 굴려보면서 부딪힌 부분들.

1. 실시간성은 떨어진다. S3에 적재되는 주기가 있고, Athena는 쿼리 시작에서 결과까지 몇 초~몇 분 걸린다. 실시간 대시보드용이 아니라 분석·리포팅용이라는 걸 이해하고 써야 한다.

2. JOIN이 비싸다. 여러 테이블 조인할 때마다 각 테이블을 풀스캔할 수 있다. 그래서 우리는 자주 조인되는 데이터를 비정규화 상태로 미리 합쳐서 저장했다. 첫 글에서 얘기한 "동기화 시점에 비정규화 변환" 패턴이 여기 와서는 비용 절감으로도 이어졌다.

3. 작은 파일이 많으면 비싸다. Athena는 S3에서 파일을 읽는데, 작은 파일이 수천 개 있으면 메타데이터 처리 비용이 더 든다. 파일 크기 100MB~1GB 정도로 묶어두는 게 좋다. 우리는 100건·5분 버퍼링 후 flush 하는 식으로 적재 단위를 조절했다.

4. 비용이 갑자기 튈 수 있다. 누군가 잘못된 쿼리 한 번 돌리면 그날 청구가 확 튄다. AWS 비용 알람 설정은 거의 필수다.

그래서 결론

우리 케이스에선 분석용 데이터를 RDB에 두던 시절 대비 월간 비용이 한 자릿수 % 수준까지 떨어졌다. 정확한 숫자는 못 적지만 자릿수 자체가 바뀌었다고 보면 된다.

다만 그게 단순히 "S3가 싸니까 옮겼다"로 된 게 아니다. 실제로 들어간 건 이런 조합이다.

• Parquet으로 변환하고
• Hive 파티셔닝을 적용하고
• 자주 쿼리되는 패턴을 비정규화로 미리 합쳐두고
• 쿼리 비용 알람을 걸어두고

이 네 가지가 다 맞물려서 비용이 떨어진 거지, 그냥 S3에 데이터만 들이부었으면 오히려 Athena 쿼리 비용이 폭주했을 거다. 이 부분은 진짜 강조하고 싶다.

결국 비용은 도구가 줄여주는 게 아니라 설계가 줄여주는 거 같다.