파일을 테이블처럼 쓰면 운영 작업이 생긴다
Amazon S3 Tables는 S3 위의 Apache Iceberg 테이블을 관리형으로 제공한다. SQL로 행을 갱신할 수 있다고 해서 내부가 전통적인 DB 페이지로 바뀌는 것은 아니다. 실제 데이터는 Parquet 파일이고, Iceberg metadata가 어느 파일이 현재 테이블에 속하는지 설명한다.
CDC로 작은 변경을 자주 커밋하면 작은 파일, 많은 스냅샷, 더 이상 참조되지 않는 파일이 계속 늘어난다. 따라서 compaction, snapshot 정리, unreferenced file removal은 선택 기능이 아니라 테이블 운영의 한 부분이다.
1. Compaction: 작은 파일을 적절한 크기로 합친다
파일이 작으면 같은 데이터를 읽어도 S3 GET 요청과 metadata 탐색이 많아진다. 쿼리 엔진은 많은 파일을 열고 스케줄해야 하므로 스캔 시간도 늘어난다.
반대로 파일이 너무 크면 필요한 일부 데이터만 읽을 때도 스캔하는 양이 커지고, 병렬 읽기 단위가 줄어든다. 리멤버 공개 사례는 기존 HDFS·Parquet 운영 경험과 테스트를 바탕으로 S3 Tables의 목표 파일 크기를 512MB로 정했다. 이 값은 보편 정답이 아니라 해당 워크로드의 선택이다.
2. Snapshot: 복구 가능 기간과 metadata 비용을 조정한다
Iceberg는 커밋마다 새 snapshot을 만든다. 이 기록 덕분에 과거 시점을 조회하고 잘못된 작업 전으로 돌아갈 수 있다. 그러나 10분마다 커밋하면 하루에 144개, 30일에 약 4,320개의 snapshot이 생긴다.
보존 정책은 테이블의 용도에 따라 달라야 한다.
- 과거 시점 재현이 필요한 테이블: 업무적으로 필요한 기간을 보존
- 최신 상태만 중요한 실시간 지표: 짧게 보존해 metadata 증가 제한
- 감사·법적 보존 대상: 플랫폼 기본값이 아니라 데이터 소유자와 합의
snapshot을 만료하면 그 snapshot만 참조하던 파일은 삭제 후보가 된다. 이 때문에 보존 정책과 파일 삭제 정책을 따로 보면 안 된다.
3. Unreferenced file: 안전 유예 기간 후 지운다
쓰기 중단, 재시도, snapshot 만료로 어떤 snapshot에서도 참조하지 않는 파일이 남을 수 있다. 바로 지우면 늦게 커밋되는 작업이나 복구 경로와 충돌할 수 있다. 그래서 일정 기간 참조되지 않았음을 확인한 뒤 삭제한다.
리멤버 공개 글은 S3 Tables의 bucket 수준 unreferencedDays, nonCurrentDays를 설명한다. 핵심은 구체적인 기본값을 외우는 것이 아니라, 복구 가능 기간과 스토리지 비용 사이의 판단을 이해하는 것이다.
4. 상태를 보지 않으면 관리형도 블랙박스가 된다
S3 Tables가 compaction을 자동 실행해도 운영자는 결과를 검증해야 한다. 공개 사례는 PyIceberg로 다음 지표를 10분 단위로 수집했다.
- total file count
- small file count: 목표 크기의 75% 미만
- average file size
- snapshot 수와 생성 속도
- maintenance 로그와 실패 이력
지표는 테이블별로 봐야 한다. 전체 평균 파일 크기가 정상이어도 특정 핫 테이블에만 small file이 쌓일 수 있다.
운영 체크리스트
- 커밋 주기는 freshness와 small file 수를 함께 고려했는가?
- 테이블별 목표 파일 크기에 측정 근거가 있는가?
- snapshot 보존 기간이 복구·감사 요구와 맞는가?
- 파일 정리가 늦게 종료되는 커밋을 지우지 않도록 유예 기간을 두었는가?
- 자동 maintenance가 실제로 작동하는지 외부 지표로 확인하는가?