왜 Iceberg 하나로 끝나지 않는가
Iceberg·S3 Tables는 큰 데이터를 싸게 보존하고 여러 엔진이 함께 읽기 좋다. 그러나 사용자가 보는 대시보드나 검색 API가 1초 이내 응답을 요구하면 오브젝트 스토리지의 파일을 매번 스캔하는 엔진만으로는 지연을 안정적으로 맞추기 어렵다.
리멤버 공개 자료는 Aurora MySQL의 운영 트랜잭션과 분석 쿼리를 분리하고, S3 Tables에 쌓인 CDC 데이터를 EKS 위 StarRocks로 가져와 저지연 질의를 제공한 구조를 설명한다.
1. 기존 선택의 한계부터 본다
공개 자료에서 기존 분석은 Presto on EMR과 Athena를 사용했다.
- Presto는 실시간 변경을 위해 MySQL federation을 사용하면 다시 운영 DB 부하가 생긴다.
- 상시 클러스터를 유지하면 사용량과 무관한 고정 비용이 생긴다.
- Athena는 스캔량에 비례한 비용과 첫 실행 warming 지연이 있어 반복적인 저지연 질의에 불리할 수 있다.
- 사용자 대면 검색이나 대시보드는 실패율보다 p95·p99 지연이 제품 경험을 결정한다.
그래서 대형 ad-hoc 스캔과 저지연 반복 질의를 같은 엔진으로 풀지 않는다.
2. StarRocks를 서빙 계층으로 보는 이유
StarRocks는 컬럼 기반 MPP OLAP 데이터베이스다. 여러 노드가 스캔·조인·집계를 나눠 실행하고, 컬럼 지향 저장과 vectorized execution으로 분석 쿼리에 맞춰져 있다.
리멤버 사례에서 중요한 기능은 다음이다.
- Iceberg catalog를 통해 S3 Tables 데이터를 조회
- incremental sync로 필요한 데이터를 내부 테이블에 반영
- materialized view로 반복 집계를 미리 계산
- 인덱스와 정렬 키로 주요 필터·조인 최적화
- EKS에서 컴퓨트 리소스를 조정
다만 Iceberg를 직접 읽기와 StarRocks 내부 테이블로 복제해 서빙하기는 freshness, 지연, 저장 중복이 다른 선택이다.
3. 어떤 데이터를 서빙 계층에 올릴지 정하는 기준
모든 Iceberg 테이블을 StarRocks에 복제하면 두 시스템의 스토리지·스키마·재처리 비용을 모두 감당해야 한다. 아래 조건을 만족하는 워크로드부터 선택한다.
- 같은 필터·집계가 반복되고 QPS가 높다.
- 사용자 대면 SLA가 엄격하다.
- 결과가 운영 DB를 직접 조회해서는 안 된다.
- 업무적으로 허용되는 freshness 지연을 정의할 수 있다.
- 스키마·매핑 변경 뒤 재생성 범위가 명확하다.
4. 실시간은 하나의 지표가 아니다
end-to-end freshness는 여러 구간의 합이다.
MySQL commit → Debezium 탐지 → Kafka 전달 → Iceberg commit → StarRocks 반영 → 대시보드 조회
전체 지연만 보면 어느 구간이 느린지 모른다. 아래 지표를 분리한다.
- Debezium source lag과 Kafka consumer lag
- Iceberg sink commit duration과 failure
- S3 Tables latest snapshot age
- StarRocks load lag·error rows·materialized view refresh lag
- 쿼리 p50·p95·p99, scan bytes, cache hit ratio
- 소스·Iceberg·StarRocks 간 표본 reconciliation
파이프라인이 빠라도 잘못된 데이터를 빨리 보여 주면 실패다. 그래서 freshness, latency, correctness를 동시에 본다.
5. 장애 시 어디까지 제공할지 정한다
- StarRocks 반영이 늦어지면 이전 snapshot을 계속 제공할지, 읽기를 막을지
- materialized view refresh가 실패하면 기본 테이블 조회로 되돌릴지
- Iceberg schema가 바뀌었을 때 기존 쿼리를 fail closed할지
- 재처리가 필요하면 어느 snapshot·offset부터 시작할지
- 서빙 오류가 실제 제품에 미치는 영향을 누가 판단할지