컬리의 BigQuery 도입기 - 1부
컬리 데이터 파이프라인의 BigQuery 도입 배경과 그 주안점
안녕하세요. 컬리 데이터플랫폼팀에서 데이터 엔지니어로서 데이터를 공급 중인 허재진입니다.
컬리는 사실과 데이터를 기반으로 의사결정을 합니다. 그렇기 때문에 데이터를 적시에 공급하는 일이 상당히 중요한 일이라고 할 수 있습니다.
컬리에서는 데이터를 좀 더 빠르고 효율적으로 제공하기 위하여 BigQuery를 도입하였습니다.
1부(이번 글)에서는 BigQuery 도입 배경을 위주로, 기존 데이터 파이프라인과 BigQuery 도입 주안점을 다루려고 합니다.
2부에서는 BigQuery 도입 결과를 위주로, 변경된 데이터 파이프라인과 BigQuery 도입 후 생긴 변화를 위주로 다루고자 합니다.
기존 데이터 파이프라인 문제점
기존의 Data Warehouse에는 여러 문제점이 있습니다. 그 문제점을 나열하자면 크게 4가지가 있는데, 아래와 같습니다.
1. 긴 지연시간
회사의 다양한 의사 결정을 위하여 실시간에 준하는 데이터 연동이 필요합니다. 하지만 최소 20분의 지연시간이 발생하였으며, 데이터가 많은 경우 최대 1시간 이상 지연되고 있습니다.
2. 스토리지 부족
나날이 늘어가는 컬리의 데이터를 감당하기에는 기존 스토리지가 너무 작았습니다. 스토리지가 부족하여 주기적인 데이터의 삭제가 필요하게 되었습니다. 데이터를 영구적으로 보관 및 조회할 방법이 필요하게 되었습니다.
3. 쿼리 응답 시간
데이터 분석이나 예측, 의사 결정의 효율성 및 생산성을 위해서는 쿼리의 응답 시간이 빨라야 합니다. 기존 Data Warehouse에서는 데이터 파이프라인과 분석 쿼리가 동시에 실행되어 한정된 자원을 가지고 경쟁하였습니다. 즉, 동시에 실행 중인 쿼리가 많은 경우 상당한 응답 지연이 발생했습니다. 그 결과, 데이터 파이프라인을 위해서 쿼리 시간을 제한하거나 실행 중인 분석 쿼리를 강제 종료해야 했습니다.
4. 복잡한 데이터 적재 과정
최대한 낮은 지연 시간을 위해서 다양한 방법을 시도하였고, 고육지책으로 데이터 적재 과정은 복잡해졌습니다. 복잡한 데이터 파이프라인을 상세히 설명하고자 합니다.
기존 데이터 파이프라인 아키텍처 및 문제점
기존 데이터 파이프라인 아키텍처는 아래 그림과 같습니다.
여러 DB(Oracle, Aurora DB, DocumentDB)에서 AWS DMS Service를 이용하여 각 테이블의 CDC 로그를 Kafka Topic으로 전송합니다.
CDC 로그를 통해 원본(Source) DB의 테이블과 동일한 상태의 테이블을 Data Warehouse에 구축하기 위해서입니다.
Kafka Topic의 CDC 로그는 일자 기준으로 파티션된 Amazon S3 테이블에 JSON 형태로 저장됩니다.
JSON 데이터는 EKS에 설치된 Airflow의 Pod Operator가 실행하는 Script를 통해 주기적으로 Data Warehouse에 저장됩니다.
이렇듯 기존 데이터 파이프라인이 복잡하다 보니, 데이터 파이프라인에 문제가 생긴 경우 원인을 파악하기 힘들었습니다. 소스 DB에서 CDC 로그를 가져오는 부분, Kafka Topic에서 Amazon S3로 데이터를 저장하는 부분, Airflow Pod에서 Script를 실행하는 부분 중 어디서 문제가 발생했는지 찾아야 했습니다.
컬리에서 가장 널리 사용 중인 데이터 파이프라인의 사례인데요, 이외의 데이터 파이프라인들 또한 유사한 구조적 문제를 가지고 있습니다. 그래서 저희는 BigQuery를 통한 단순하고 통일된 구조의 데이터 파이프라인 구축을 결정했습니다. 그 효과에 대해서는 2부에서 다루기로 하고, 이 글에서는 그 도입 주안점을 간략히 소개하겠습니다.
BigQuery 도입 주안점
BigQuery 도입은 앞서 언급한 기존 데이터 파이프라인의 문제점을 해결하는 것에 초점을 두고 진행했습니다.
1. 긴 지연시간
기존 파이프라인에서는 데이터를 Amazon S3에 우선 저장하고, Airflow에서 스크립트를 실행해 다시금 Data Warehouse로 적재해야 했습니다. S3에 저장된 데이터의 크기가 커질수록 늘어나는 스크립트 실행 소요시간이 파이프라인의 병목이었습니다. 기존 방식보다 데이터를 가장 빠르게 넣을 방법을 찾아야 했고, BigQuery Streaming API를 통하여 데이터 적재를 하도록 구축하였습니다. BigQuery Streaming API를 이용하여 BigQuery로 데이터를 직접 넣게 되어 파일 시스템에서 데이터를 읽을 필요가 없습니다. 즉, 스토리지에 접근하여 데이터를 읽는 I/O가 없어지도록 구축하였습니다.
2. 스토리지 부족
BigQuery는 정해진 스토리지 제한 없이, 저장한 만큼 비용을 내면 되는 구조이기 때문에 스토리지 부족의 문제에서 자유로울 수 있습니다. 물론 데이터를 끊임없이 저장한다면 과도한 스토리지 비용이 청구되므로, 테이블별 파티션에 데이터 보관 기간을 지정하였습니다.
3. 쿼리 응답 시간
BigQuery에서는 더 빠른 쿼리의 응답 시간을 위해 데이터 파이프라인을 위한 프로젝트와 데이터 조회를 위한 프로젝트를 분리하여 구축하였습니다. "프로젝트"는 시스템을 구축하기 위한 가장 작은 단위라고 할 수 있습니다. BigQuery에서 데이터 파이프라인과 데이터 조회를 하는 시스템(프로젝트)을 분리하여 쿼리 응답 시간을 개선하였습니다.
4. 복잡한 데이터 적재 과정
BigQuery Streaming API는 앞서 언급한 것 처럼 속도 면에서의 이점이 있을 뿐 아니라, 복잡한 데이터 파이프라인 구조를 단순화는데도 효과적입니다. 이것을 이용해 Kafka Topic에서 BigQuery로 바로 데이터를 적재하는 것이 가능하기 때문입니다.
비용 관리
BigQuery 도입 시 가장 중요하게 고려해야 할 부분은 '비용(Cost)'입니다. 앞서 언급한 것 처럼 스토리지를 사용하는 만큼, 또 데이터를 스캔하는 용량 만큼 요금이 부과되기 때문입니다.
파티션 사용
BigQuery 사용 시 데이터를 저장하고 스캔하는 범위를 제한해 비용을 줄이는 방법으로는 "파티션"과 "클러스터링"이 있습니다. 그 중 저희는 파티션 관리를 중점적으로 고려하였고, 데이터의 보관주기 단위와 데이터 스캔 범위를 파티션 단위로 설정하도록 하였습니다.
저희는 파티션을 데이터의 생성일자 단위로 나누었습니다. 그렇게 함으로서, 데이터 성격에 따라 그 최신성을 특정 기간만큼만 보장하도록 생명주기를 관리하는 것이 가능해졌습니다. 데이터 스캔 시에도, 쿼리의 Where 절에 파티션 범위를 반드시 지정하게 함으로서 필요한 파티션만 읽도록 강제했습니다.
프로젝트 분리
쿼리 유형에 따라 적합한 프로젝트를 선택할 수 있도록 한 것도 비용 관리에 도움을 줄 것으로 기대합니다.
한 프로젝트에는 "슬롯"을 예약구매해두었고, 다른 한 프로젝트에는 슬롯 제약은 두지 않되 하루 데이터 스캔 용량을 제한하였습니다. 데이터 스캔 용량이 큰 쿼리는 시간이 걸리더라도 예약된 슬롯 내에서 실행되도록 하였습니다.
이번 글에서는 기존의 데이터 파이프라인과 그 문제점을 살펴보고, 그것을 해결하기 위한 BigQuery 도입 주안점에 대해 소개했습니다.
2부에서는 BigQuery 도입 결과 및 효과를 소개하겠습니다.
Reference
BigQuery Logo
* 본 게시물에 사용된 이미지들의 저작권은 컬리에 있습니다. 사용 시 출처를 꼭 명시해주세요.