Amazon S3 Tables 메인터넌스 완전정복: Iceberg 테이블이 “항상 빠른 상태”를 유지하는 3가지 자동 작업 + 비용까지
Athena로 Iceberg 테이블을 돌리다 보면, 어느 날 갑자기 이런 순간이 옵니다.
“어제까진 쿼리 잘 나오더니 오늘은 왜 이렇게 느리지?” …그리고 원인은 대개 작은 파일 폭발, 스냅샷 누적, 고아 파일(안 쓰는 파일) 방치 같은 ‘유지관리 미납’입니다.
문제는 이 유지관리가 꼭 필요하지만 정말 귀찮다는 점이죠. 스케줄러 붙이고, Glue Job 만들고, 실패 알림 붙이고… 그러다 보면 데이터 레이크가 아니라 “운영 레이크”가 됩니다.
Amazon S3 Tables는 여기서 게임 룰을 바꿉니다. 겉으로는 S3 위의 테이블처럼 보이지만, 내부적으로는 Apache Iceberg 테이블을 “쿼리하기 좋은 상태”로 유지하기 위해 메인터넌스를 자동 수행합니다. 이 글에서 S3 Tables가 백그라운드에서 정확히 무엇을 하는지, 어떤 전략을 고르면 좋은지, 비용은 어떻게 계산되는지를 한 번에 정리해드립니다.
S3 Tables 메인터넌스가 자동으로 해주는 3가지 (진짜 핵심만)
S3 Tables는 Iceberg 테이블을 운영할 때 필수인 유지관리 작업을 백그라운드에서 처리합니다. 사용자는 “테이블 정의하고 데이터 넣고 쿼리”에 집중하면 됩니다.
1) 파일 컴팩션(Compaction): 작은 파일 지옥을 자동으로 탈출
Iceberg 테이블이 계속 INSERT/UPDATE 되면 파일이 잘게 쪼개지기 쉽습니다.
Athena는 파일이 너무 많으면 그만큼 더 많은 파일을 열고/읽어야 해서 성능이 흔들립니다.
S3 Tables는 자동으로 파일을 재구성합니다.
작은 파일을 합쳐서 Athena에 유리한 파일 크기로 맞춤
정렬/클러스터링 전략이 있으면 거기에 맞춰 재배치 가능
한마디로 “쿼리 엔진이 좋아하는 형태로 테이블을 다듬어주는 자동 정리”입니다.
2) 오래된 스냅샷 자동 삭제: 메타데이터 폭증 방지
Iceberg는 변경이 생길 때마다 스냅샷을 만들고, 이는 롤백/타임트래블 같은 강력한 기능을 줍니다.
하지만 스냅샷이 무한히 쌓이면 메타데이터가 커지고 성능/비용 부담이 됩니다.
S3 Tables는 보존 정책에 따라 기간이 지난 스냅샷을 자동 삭제해서 이 폭증을 막아줍니다.
3) 고아 파일(어느 스냅샷에서도 안 쓰는 파일) 자동 정리
UPDATE/DELETE가 생겨도 Iceberg는 데이터를 바로 지우지 않습니다.
과거 스냅샷이 그 파일을 참조할 수 있기 때문이죠.
그래서 “지워도 되는 파일”을 판단하려면 스냅샷/메타데이터를 꼼꼼히 봐야 하는데, 이걸 S3 Tables가 대신합니다.
어떤 스냅샷에서도 참조하지 않는 파일만 골라
안전하게 삭제(클린업)
스토리지 비용과 메타데이터 스캔 부담을 함께 줄이는 효과가 납니다.
컴팩션 전략 선택: binpack vs sort vs z-order (이렇게 고르면 됩니다)
S3 Tables의 성능 최적화에서 가장 “선택”이 필요한 부분이 컴팩션 전략입니다. 대표 3가지는 아래와 같습니다.
binpack(기본값): 대부분의 테이블은 이걸로 충분
작은 파일들을 적당한 크기의 큰 파일로 합치는 전략
정렬 기준이 따로 없고, 쿼리 패턴이 다양하면 가장 무난합니다.
운영 초기에는 binpack으로 시작하는 게 안전합니다.
추천 상황
로그/이벤트성 데이터
특정 컬럼에 필터가 고정되지 않음
“일단 안정적으로 빠르게”가 목표
sort: “한 가지 컬럼”으로 자주 필터링한다면 강력
sort는 특정 컬럼 기준으로 데이터를 재배치해 비슷한 값이 같은 파일에 모이도록 합니다.
예를 들어 customer_id로 정렬 + sort 컴팩션을 쓰면, 특정 고객을 조회할 때 읽는 파일 범위가 줄어들어 성능이 좋아집니다.
추천 상황
WHERE customer_id = ...처럼 단일 컬럼 필터가 압도적으로 많음특정 키(테넌트, 고객, 국가 등) 중심 조회가 잦음
z-order: “여러 컬럼 조합 필터”가 많다면 최적
z-order는 여러 컬럼을 동시에 고려해 데이터를 “가까운 값끼리” 배치합니다.
예:
SELECT *
FROM orders
WHERE customer_id = 'C123' AND product_id = 'P456';단일 sort로는 이런 복합 조건 최적화가 애매할 수 있는데, z-order는 다차원 기준으로 파일 스킵 효율을 높여줍니다.
추천 상황
customer_id + product_id처럼 2개 이상 컬럼 조합으로 필터링이 잦음대표 대시보드 쿼리 패턴이 복합 조건에 고정됨
메인터넌스 비용 구조: “자동”은 공짜가 아닙니다 (계산식까지)
S3 Tables는 자동 컴팩션에 대해 별도 요금을 부과합니다.
과금은 크게 2개 축입니다.
1) 파일 개수 기준 비용
컴팩션 처리된 파일 1,000개당 $0.00185
파일이 잘게 쪼개져 있으면 이 비용이 자연히 늘어납니다.
즉, “파일이 너무 많아 느리다”는 상황은 보통 “메인터넌스 비용도 같이 오른다”와 동의어가 되기 쉽습니다.
2) 처리 데이터 용량 기준 비용(전략별 단가 다름)
binpack: 1GB당 $0.005
sort / z-order: 1GB당 $0.01 (binpack의 2배)
정리하면 이렇습니다.
sort/z-order는 쿼리 성능 잠재력이 더 크지만
유지관리 비용도 더 큽니다.
현실적인 운영 전략(추천)
1단계: binpack 기본값으로 시작
2단계: 쿼리 로그를 보고 “딱 여기만 느리다”가 보이면
3단계: 그 테이블만 sort 또는 z-order로 선택 적용
또한 컴팩션 비용만 보지 말고, Athena 쿼리 비용(스캔 감소) + S3 저장 비용(불필요 파일 정리)까지 포함한 TCO 관점으로 판단하는 게 좋습니다.
일반 S3 + Iceberg 테이블과 뭐가 다를까? (한 줄로 요약하면 “운영의 자동화”)
이미 S3 버킷 위에 Iceberg 테이블을 운영 중이라면 이렇게 묻게 됩니다.
“그냥 지금처럼 Glue로 최적화 돌리면 되지 않나?”
맞습니다. 다만 차이는 분명합니다.
일반 S3 + Iceberg
자유도 높음
대신 컴팩션/스냅샷 정리/고아 파일 삭제를 직접 구현
스케줄링/실패처리/비용관리까지 운영 부담이 큼
S3 Tables
Iceberg 테이블을 S3 위에서 관리하되
위 유지관리 3종 세트를 서비스가 내장 제공
사용자는 테이블/데이터/쿼리에 집중
운영 리소스가 부족하거나, Athena 트래픽이 많은 분석 환경일수록 “자동 유지관리”의 체감 효용이 커집니다.
결론: S3 Tables 메인터넌스를 한 번에 정리하면
S3 Tables는 Iceberg 테이블을 위해 컴팩션, 스냅샷 삭제, 고아 파일 정리를 자동 수행합니다.
컴팩션 전략은 binpack(기본) → sort(단일 컬럼) → z-order(복합 컬럼) 순으로 필요할 때만 강화하세요.
비용은 파일 개수 + 처리 GB 기준이며, sort/z-order가 binpack보다 2배 단가입니다.
다음 행동(바로 적용 체크리스트)
지금 Athena 쿼리가 느리다면: 최근 데이터에 작은 파일이 폭발했는지부터 확인
쿼리 패턴이 “한 컬럼/두 컬럼 조합”으로 고정이라면: sort 또는 z-order 전환 후보 테이블을 1개만 골라 A/B로 비교
메타데이터가 커지는 느낌이 든다면: 스냅샷 보존 기간 정책을 먼저 점검
읽으면서 떠오른 쿼리 패턴(자주 쓰는 WHERE 조건)을 댓글로 남겨주시면, sort vs z-order 선택을 더 구체적으로 같이 판단해드릴게요. 공유도 환영합니다.
참고
Amazon S3 Tables 메인터넌스 기능 소개(서버워크스 엔지니어 블로그): https://blog.serverworks.co.jp/s3-tables-maintenance
Amazon S3 Features (AWS): https://aws.amazon.com/s3/features/
