컬리의 BigQuery 도입기 - 1부

Context

컬리의 기존 Data Warehouse는 최소 20분에서 최대 1시간 이상의 지연시간이 발생했으며, 스토리지 부족으로 인한 주기적 데이터 삭제가 필요했다. 또한 데이터 파이프라인과 분석 쿼리가 동시에 실행되며 제한된 자원을 놓고 경쟁하여 응답 지연이 심각했고, Oracle·Aurora DB·DocumentDB → DMS → Kafka → S3 → Airflow Pod의 복잡한 적재 과정으로 인해 장애 원인 파악이 어려웠다.

Technical Solution

• 지연시간 단축: BigQuery Streaming API를 통해 Kafka Topic에서 S3 거쳐 Airflow로 처리하는 방식 대신 BigQuery로 직접 데이터 적재하여 스토리지 I/O 제거
• 스토리지 확장: 무제한 스토리지 용량의 BigQuery 도입 및 테이블별 파티션에 데이터 보관 기간 설정으로 비용 관리
• 쿼리 성능 분리: 데이터 파이프라인 전용 프로젝트와 데이터 조회 전용 프로젝트를 별도 구성하여 리소스 경쟁 제거
• 파이프라인 단순화: BigQuery Streaming API를 통해 Kafka Topic에서 BigQuery로 직접 적재 가능하도록 구조 단순화
• 비용 관리 체계: 파이프라인 프로젝트에는 슬롯 예약구매, 조회 프로젝트에는 일일 데이터 스캔 용량 제한 설정

Key Takeaway

복잡한 다단계 데이터 파이프라인은 장애 원인 파악을 어렵게 만드므로, 관리형 서비스의 직접 적재 API(Streaming API)를 활용하여 아키텍처를 단순화하는 것이 운영 효율성을 높인다. 클라우드 기반 데이터 웨어하우스 도입 시 프로젝트 분리를 통한 리소스 격리와 파티션 기반 비용 관리가 필수적이다.