광고 성과 데이터 StarRocks 도입기

광고 성과 데이터 플랫폼의 MySQL 기반 아키텍처를 StarRocks로 전환한 실전 도입기다. 새 성과 지표 유형이 추가될 때마다 전체 파이프라인을 복제해야 했던 확장성 문제, RDS 과부하, 커서 기반 집계의 데이터 무결성 결함까지 세 가지 근본 문제를 진단하고 DB 후보 비교 선택 과정을 상세히 기록했다.

핵심 포인트

선택 배경: BigQuery(배치 중심·비용 구조 불일치), ClickHouse(Glue Catalog 타임스탬프 버그) 평가 후 StarRocks 선택 — Iceberg/Glue 안정 통합 + MySQL wire-protocol 호환이 결정 요인
아키텍처: Apache Iceberg on S3 + Glue 메타데이터 → StarRocks 외부 테이블로 쿼리 (원본 데이터 이동 없음)
초기 실수: shared-data 배포 → S3 API 비용 예상 대비 95% 초과 → shared-nothing(로컬 스토리지) 마이그레이션으로 해결
결과: RDS active sessions p50 8→5, p99 16→10 / commit latency p50 12ms→8ms, p99 25ms→15ms
복구 시간: 인시던트 후 소스 데이터 수정 반영 4시간 이상 → 30분 미만으로 단축
커서 기반 집계의 레이스 컨디션 → 묵시적 데이터 누락 문제 완전 제거

상세 정리

기존 문제 1 (확장성): 새 광고 성과 지표 유형 추가 시 전체 배치-컨슈머-DB 파이프라인을 복제해야 하는 구조, 상품 레벨·날짜 기반 지표 조합 처리 불가
기존 문제 2 (RDS 과부하): 지표 차원 증가에 따른 쓰기 증폭으로 "RDS average active sessions" 경보 반복 발생, 핵심 광고 수익 위협
기존 문제 3 (데이터 무결성): 커서 기반 증분 집계에서 고동시성 스레드가 ID 생성 순서와 무관하게 커밋 → 묵시적 데이터 갭 발생, 사후 복구는 수동 처리 필요
BigQuery 탈락 이유: 배치 처리 중심 설계, 실시간 집계 비용 구조가 광고 플랫폼에 부적합
ClickHouse 탈락 이유: AWS Glue Catalog 연동 시 타임스탬프 처리 버그 — 재현 가능하고 수정 일정 불명확
StarRocks 선택 이유: Iceberg + Glue 안정 통합, MySQL 호환 프로토콜로 기존 쿼리 최소 변경, 외부 카탈로그 지원
shared-data vs shared-nothing: 초기 shared-data는 S3 직접 읽기로 API 호출 폭증, shared-nothing은 컴퓨팅 노드 로컬 스토리지 캐시로 비용 정상화
파티셔닝 전략: 날짜 기반 파티션 + 마테리얼라이즈드 뷰 계층으로 집계 쿼리 성능 최적화

왜 읽나OLAP DB 후보(BigQuery/ClickHouse/StarRocks)를 실제 프로덕션 조건에서 평가한 비교 근거와, shared-data → shared-nothing 전환으로 S3 비용 95% 초과를 해결한 실수 공유가 같은 선택 앞에 선 팀에게 직접적인 판단 기준이 된다.

라포랩스 (퀸잇) 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

광고 성과 데이터 StarRocks 도입기

이 글과 비슷한

분석가가 직접 만든 마케팅 자동화 시스템 — 오디언스 빌더 제작기

모든 Vercel 빌드를 지탱하는 데이터베이스 마이그레이션 이야기

DynamoDB 핫 파티션을 해결하는 3가지 방법 (3): 조회를 인덱스 테이블로 옮기기