컬리의 BigQuery 도입기 - 1부

컬리 데이터플랫폼팀이 기존 Data Warehouse의 한계를 BigQuery로 옮겨 해결한 도입 배경을 다룬다. 1부는 기존 파이프라인의 문제점과 BigQuery 선택 시 고려한 주안점, 비용 관리 방식을 정리한다.

핵심 포인트

기존 DW는 최소 20분~1시간 지연, 스토리지 부족으로 인한 주기적 데이터 삭제, 파이프라인과 분석 쿼리의 자원 경쟁, 복잡한 적재 과정 4가지가 문제였다.
기존 구조는 Oracle/Aurora/DocumentDB에서 AWS DMS CDC → Kafka Topic → S3(JSON) → EKS Airflow PodOperator → DW로 이어져 장애 원인 추적이 어려웠다.
BigQuery Streaming API로 Kafka에서 바로 적재해 S3·스크립트 단계를 없애 지연과 복잡도를 줄였다.
비용은 파티션(생성일자 기준)과 프로젝트 분리(슬롯 예약 vs 스캔량 제한)로 통제한다.

상세 정리

지연 문제: 실시간에 준하는 연동이 필요한데 S3 적재 후 Airflow 스크립트로 재적재하는 구조라, 데이터가 커질수록 스크립트 실행 시간이 병목이었다.
스토리지 문제: 늘어나는 데이터를 기존 스토리지가 못 버텨 주기적으로 삭제해야 했고, 영구 보관·조회 수단이 없었다.
쿼리 응답: 파이프라인과 분석 쿼리가 한정 자원을 두고 경쟁해, 동시 쿼리가 많으면 쿼리 시간을 제한하거나 실행 중 분석 쿼리를 강제 종료해야 했다.
Streaming API 도입: 파일시스템 I/O 없이 BigQuery로 직접 데이터를 넣어, 스토리지 접근으로 데이터를 읽는 과정을 제거했다.
스토리지 해결: BigQuery는 저장한 만큼 과금이라 용량 제한에서 자유롭지만, 과금 방지를 위해 테이블 파티션마다 보관 기간을 지정했다.
쿼리 응답 개선: 데이터 파이프라인용 프로젝트와 조회용 프로젝트를 분리해 응답 시간을 개선했다(프로젝트는 시스템 구축의 최소 단위).
적재 단순화: Streaming API로 Kafka Topic에서 BigQuery로 직접 적재가 가능해져 복잡한 파이프라인 구조가 단순해졌다.
비용 관리, 파티션: 저장·스캔 범위를 제한하려 파티션과 클러스터링 중 파티션을 중점 사용, 데이터 생성일자 단위로 나눠 생명주기를 관리하고 쿼리 WHERE에 파티션 범위 지정을 강제해 필요한 파티션만 읽게 했다.
비용 관리, 프로젝트 분리: 한 프로젝트는 슬롯을 예약구매, 다른 프로젝트는 슬롯 제약 없이 하루 스캔 용량을 제한해 스캔량 큰 쿼리는 예약 슬롯 안에서 처리했다.