테크 블로그 분석
데이터 엔지니어링에 관한 정보는 웹 개발에 비해 확실히 부족하다. 데이터 엔지니어링에 관한 책을 읽는 것은 많은 도움이 되지만, 최신 정보를 반영하지는 못한다. 그렇다보니 추후 프로젝트(EATceed)에 도입할 (로그)데이터 파이프라인을 어떻게 구성할 수 있을까에 대한 고민이 들었고 이에 대한 해결 방법으로 기업 기술 블로그에서 데이터 엔지니어링에 관한 내용을 분석하는 것을 채택했다.
기술 블로그인만큼 유용한 정보가 많지만, 그만큼 어렵다고 느낀다. 단어와 개념부터 하나씩 알아보면서 분석해보자!
마켓컬리
기술 블로그 분석 포스트 중 마켓컬리를 먼저 채택한 이유는 개인적으로 기업 기술 블로그 중에서 글을 깔끔하고 알차게 구성했다는 느낌을 받아서이다. 그리고 데이터 엔지니어링에 관한 포스트도 다수 존재하여 마켓컬리 기술 블로그를 먼저 분석하고 다른 회사 포스트를 업로드할 예정이다.
간단하게 마켓컬리는 신선한 식재료를 집 앞으로 배송해주는 서비스를 비즈니스 모델로 하는 이커머스 기업이다.
마켓컬리에서는 샛별배송 서비스를 제공하기 위해 필요한 수요예측, 재고관리, 주문처리, 배송처리 등을 위한 IT 시스템과 솔루션을 직접 개발 하고 운영하고 있다. 단순한 물류, 유통이 아니라 다양한 데이터 기술을 바탕으로 높은 품질을 유지하고 더 나은 상품을 빠르게 배송하는 것을 목표로 하기때문에 이때 다양한 의사 결정 환경에 실시간에 가까운 데이터를 제공하기위해 데이터 엔지니어가 필요하다.
이제 컬리의 BigQuery 도입기를 분석해보자!
컬리의 BigQuery 도입기
기존 Data Warehouse의 문제점은 다음과 같다.
- 긴 지연시간 :
실시간에 준하는 데이터 연동이 필요한데, 최소 20분에서 데이터가 많을 경우 1시간 이상 지연 발생 - 스토리지 부족 :
컬리의 데이터를 감당하기에는 기존 스토리지가 너무 작아 데이터의 주기적인 삭제 기능 필요, 즉 영구적인 데이터 보관이 불가능 - 쿼리 응답 시간 :
효율성 및 생산성을 위해서는 쿼리의 응답 시간이 빨라야하는데, 동시에 실행 중인 쿼리가 많은 경우 응답 지연 발생 - 복잡한 데이터 적재 과정 :
낮은 지연 시간을 위해 데이터 적재 과정이 복잡(trade off)
기존 데이터 파이프라인 아키텍처는 위 그림과 같다. 그림 상의 기술 스택에 대한 정보를 알지 못해 먼저 정리하고자 한다.
기술 스택
- AWS DMS : 데이터베이스를 마이그레이션(전송) 해주는 AWS 서비스
- AWS MSK(Kafka) : Kafka를 사용하여 스트리밍 데이터를 처리하는 애플리케이션의 구축 및 실행을 위해 사용할 수 있는 완전관리형 서비스
- Amazon S3 : 스토리지 서비스로 다양한 형식의 데이터를 저장하기 위해 사용하는 서비스
- Airflow Pod on EKS : Airflow를 Amazon EKS(Elastic Kubernetes Service) 클러스터 위에서 실행하는 서비스
파이프라인 흐름
1. 여러 DB에서 AWS DMS를 이용하여 각 테이블의 CDC 로그를 Kafka Topic(MSK)으로 이동
(CDC 로그를 통해 원본 DB의 테이블과 동일한 상태의 테이블을 Data Warehouse에 구축 가능)
- CDC 로그 : Cahnge Data Capture로 DBMS의 변경 데이터를 사용해 후속처리를 취할 수 있도록 데이터를 추적하기 위해 사용되는 소프트웨어 디자인 패턴들의 집합
- Log Scanner 방식을 CDC라고 부르는 추세인데 대부분의 DB에는 모든 이벤트를 저장하는 트랜잭션 로그가 존재하여 트랜잭션 로그에서 변경데이터를 추출하는데 이러한 CDC 데이터가 적재되어있는 테이블을 AWS DMS를 이용해서 Kafka Topic(MSK)로 이동하는 원리(국내 대기업에서 활용 중인 기술이라고 한다..)
2. Kafka Topic의 CDC 로그는 일자 기준으로 파티션된 Amazon S3 테이블에 JSON 형태로 저장
3. JSON 데이터는 EKS에 설치된 Airflow의 Pod Operator가 실행하는 Script를 통해 주기적으로 Data Warehouse에 저장
문제점
해당 포스트에서는 데이터 파이프라인에 문제가 생긴 경우 원인 파악의 어려움을 아키텍처의 문제점으로 언급했다.
과정 중간중간에 데이터를 넘기고 기능을 실행하는 부분에서 문제가 발생한다면 어디서 문제가 발생하는지 일일이 찾아야하기 때문이다.
데이터 파이프라인 구축에 자세히 알지 못해 해당 아키텍처가 복잡하다고 생각이 들지는 않고, 어려운 개념이 다수 존재하구나라고 생각했다.
BigQuery 도입 주안점
위의 문제처럼 아키텍처가 복잡한데 BigQuery를 도입하면 어떻게 해결할 수 있을까?
1. 긴 지연시간 :
- 데이터를 Amazon S3에 우선 저장하고 Airflow에서 스크립트를 실행해 Data Warehouse로 적재하다보니 S3에 저장된 데이터의 크기가 커질수록 스크립트 실행 소요시간이 파이프라인의 병목
- BigQuery Streaming API를 이용하면 BigQuery로 데이터를 직접 넣게되어 파일 시스템에서 데이터를 읽을 필요 x
결국 파일 시스템(스토리지)에서 데이터를 읽을 필요가 없기 때문에 I/O 작업이 없어진다.
2. 스토리지 부족 :
- BigQuery는 정해진 스토리지 제한 없이 저장한 만큼 비용을 내는 구조(스토리지 부족 문제 x)
- 파티션에 데이터 보관기간 지정하면 비용 효율적으로 관리 가능
3. 쿼리 응답 시간 :
- BigQuery에서는 빠른 쿼리 응답 시간을 위해 데이터 파이프라인을 위한 프로젝트와 데이터 조회를 위한 프로젝트를 분리하여 구축
4. 복잡한 데이터 적재 과정 :
- BigQuery Streaming API는 속도 뿐만 아니라 복잡한 데이터 파이프라인 구조를 단순화하는데도 효과적
- Kafka Topic(MSK)에서 BigQuery로 바로 데이터를 적재하는 것이 가능
기존에는 Amazon S3에 넣는 것을 수행했는데 BigQuery Streaming API를 사용하면 중간 과정을 생략할 수 있다.
도입 주안점을 읽어보니 BigQuery가 제공하는 Streaming API는 데이터 파이프라인에서 강력한 기능을 수행한다는 것을 알게 되었다.
추후 프로젝트에 BigQuery Streaming API를 적용하는 것도 고려해야겠다.
신규 데이터 파이프라인 아키텍처
신규 데이터 파이프라인 아키텍처는 크게 2가지로 분류할 수 있다.
- RDBMS 데이터 연동을 위한 정형 데이터 파이프라인 아키텍처
- 비정형 데이터 파이프라인 아키텍처(스키마가 고정적이지 않기 때문에 파이프라인에서 데이터 변환(T) 필요)
정형 데이터 파이프라인 아키텍처
1. RDBMS에서 AWS DMS를 이용하여 각 테이블의 CDC 로그를 Kafka Topic으로 전송(기존 방식과 동일)
2. Kafka Topic의 CDC 로그는 일자 기준으로 파티션 된 BigQuery의 CDC 로그 테이블에 BigQuery Streaming API를 통해 저장
- 기존에는 S3를 활용하여 일자 기준으로 파티션하였지만 새로운 파이프라인 아키텍처에서는 BigQuery CDC 로그 테이블 활용
3. CDC 로그 테이블은 GCP Cloud Composer(Airflow)의 BigQuery Job Operator가 실행하는 Merge Procedure을 통해 주기적으로 Final 테이블에 데이터 넣기(Final 테이블 == 원본 DB 테이블)
- 기존에는 Airflow Pod on EKS를 이용했다면 GCP 플랫폼으로 이전하여 GCP Cloud Composer(Airflow)로 변경
비정형 데이터 파이프라인 아키텍처
1. NoSQL에서 AWS DMS를 이용하여 Collection의 Change Streamdmf Kafka Topic으로 전송
- Change Stream : MongoDB의 변경을 애플리케이션에 실시간으로 전달해주는 기능
- Change Stream을 통해 원본 DB Collection과 동일한 상태의 테이블을 BigQuery에 구축
2. Kafka Topic의 CDC 로그는 JSON Format Processing 진행
- JSON Format Processing은 BigQuery에서 원본 DB 테이블과 동일한 상태의 Final 테이블을 만드는데 필요한 컬럼을 추출하는 방법 - BigQuery는 JSON 타입을 지원해서 JSON Format Processing을 단순하게 구현 가능
3. CDC 로그 테이블은 GCP Cloud Composer(Airflow)의 BigQuery Job Operator가 실행하는 Merge Procedure을 통해 주기적으로 Final 테이블에 데이터 넣기(Final 테이블 == 원본 DB 테이블)
기존 데이터 파이프라인과의 차이점
- 기존 데이터 파이프라인은 정형 / 비정형 데이터를 구분하지 않고 일단 Amazon S3에 넣었다면 개선한 데이터 파이프라인 아키텍처는 정형 / 비정형을 구분
- 플랫폼을 AWS에서 GCP로 이전
BigQuery 도입 결과 및 효과
데이터 레이크하우스 구축
- BigQuery는 앞서서 언급한 것처럼 기존 Data Warehouse와 달리 스토리지 비용이 상당히 저렴하며 확장성이 뛰어남
- 운영 DB 테이블 연동 이외에도 운영 DB 테이블의 이력(CDC 로그), 데이터 마트를 주기적으로 삭제하지 않고 보관 가능
- 많은 양의 로그 데이터를 BigQuery에 보관 가능
- BigQuery는 JSON 타입을 지원하여 다양한 로그를 손쉽게 보관 가능
데이터 파이프라인 개선
- 기존 Data warehouse 적재 방식은 S3에 있는 CDC 로그 데이터를 비교하여 Update+Insert 방식을 사용했는데 해당 동작 방식은 임시 테이블 생성, 과거 데이터 삭제, 신규 데이터 삽입, 임시 테이블 삭제 4단계를 거쳐서 적재해서 속도가 느림
- BigQuery는 Merge문을 사용하여 Insert, Update, Delete 스크립트를 사용할 필요없이 빠른 속도로 데이터 적재하여 데이터 연동 지연시간이 대폭 감소
쿼리 응답 시간 / 비용 감소
- 프로젝트 분리로 인한 데이터 파이프라인과 데이터 조회가 한정된 자원이 아닌 할당된 자원을 사용해서 쿼리 응답 시간이 대폭 감소
테이블 조회 시 파티션 기능을 사용해서 스캔 용량을 줄여 쿼리 응답시간 개선 - BigQuery는 스캔 비용에 따라 비용을 지불하거나 슬롯을 예약 구매하여 정해진 비용 지불하여 비용 기존보다 많이 감소
컬리의 BigQuery 도입기를 읽고난 후
컬리의 BigQuery 도입기를 읽고 나니, 그동안 AWS 플랫폼(특히 EC2 배포)에만 익숙하여 편협한 생각을 하고 있었다는 것을 깨달았다. 기존에는 익숙한 AWS를 사용해 EATceed 데이터 파이프라인을 구축해야겠다고 생각했지만, 해당 포스트를 통해 BigQuery라는 새로운 관점을 얻을 수 있었다.
특히, BigQuery Streaming API의 강력한 기능을 알게 되었는데, 이 API는 데이터 파이프라인의 여러 단계를 생략하고 복잡성을 제거해주기 때문에, 앞으로의 프로젝트에 도입을 고려해볼 만하다는 생각이 들었다. 또한, 해당 포스트에서 제공한 BigQuery 문서 페이지를 통해 개인적으로 더 깊이 공부할 필요성을 느꼈다.
기술 블로그를 처음 분석해 보았는데, 확실히 어려운 개념이 많았지만 하나씩 찾아가며 이해하는 과정이 매우 유익하다고 생각한다.
