오늘은 29CM의 데이터 파이프라인을 리뷰해보려고 한다. 데이터 엔지니어로서 한 회사의 파이프라인을 들여다볼 수 있는 건 되게 재밌고 흔치 않은 기회라고 생각된다. 글은 2023년도 초에 작성되었지만 파이프라인의 초기 상태에서 발전해 나가는 흐름을 파악하기 좋아 선택했다.
기술 블로그 출처
29CM 데이터 파이프라인 소개
안녕하세요 데이터그로스팀 이진환입니다. 29CM에선 21년 9월 이후부터 데이터에 기반한 의사결정을 원활하게 할 수 있도록 데이터 파이프라인을 빠르게 개선하여 운영하고 있습니다. 지금부터 2
medium.com
29CM 데이터 파이프라인 흐름
2021년도 9월 이전 → 2021년도 9월 ~ 22022년도 12월 → 2023년도 이후
어느 부분이 문제가 있었고 어떻게 해결됐는지 한 단계씩 뜯어보자.
2021년도 9월 이전
운영 데이터 수집은 ETL 방식으로 진행되어 데이터 엔지니어와 분석가들이 필요한 데이터를 요청 및 개발했다. 워크플로우는 명확한 기준 없이 Airflow, Jenkins, Bigquery Scheduled queries로 나눠서 사용하고 있었다.
* Airflow: 데이터 파이프라인의 작업 스케줄링, 실행 및 모니터링을 위해 주로 사용되며, 데이터 엔지니어링 및 분석 작업에서 ETL 작업을 자동화하고 관리한다.
* Jenkins: 소프트웨어 개발 시 지속적으로 통합 서비스를 제공하는 툴로 주로 사용되며, 데이터 파이프라인을 관리하고 실행하는 데에도 사용된다.
* Bigquery Scheduled queries: 특정 시간에 자동으로 쿼리를 실행하고 결과를 저장하거나 다른 작업을 수행할 수 있도록 하는 Bigquery 기능 중 하나로, 이 기능을 사용하면 주기적으로 실행해야 하는 쿼리 작업을 자동화할 수 있다.
데이터 레이크로 GCS를, 데이터 웨어하우스로 Bigquery를 사용했는데 추출/변형이 완료된 동일한 형태의 데이터를 가지고 있었다. 데이터마트인 PostgresSQL에는 별도의 ETL 형식 데이터 파이프라인으로 생성한 데이터가 저장되고 있었다.
내가 만약 회사에 들어갔는데 현 데이터 파이프라인이 이렇다고 하면 어떨까? 정확한 워크플로우 내부를 몰라서 쉽게 판단할 순 없지만 airflow, jenkins, bigquery 를 전부 써야 하는가에 대해 먼저 분석해 볼 거 같다. 각 환경에 맞는 도구를 써야 하는 건 맞지만 도구가 많아질수록 유지보수가 어렵고 확장성도 낮다. 그리고 운영비용과 인력비용도 중요하기 때문에 줄일 수 있는 부분은 줄이려고 할 것이다. (정답이 없다는 점이 재밌기도, 어렵기도 하다.) 데이터 레이크와 데이터 웨어하우스엔 동일한 데이터가 있다고 하는데, 이는 데이터 일관성을 유지하기 어렵고 저장 공간을 낭비하고 있는 문제이므로 꼭 해결해야 하는 문제 같다.
이렇게 기준이 잡히지 않은 데이터 파이프라인에서 아래와 같은 문제점이 있었다.
- ETL 방식으로 데이터를 수집하고 있어 필요할 때마다 데이터 엔지니어, 데이터 분석가의 리소스가 소요됨
- 기준 없이 여러 워크플로를 사용하여 오류를 찾기 힘듦
- Jenkins, Bigquery Scheduled queries에서 오류가 발생할 경우, 백필에 리소스가 소요됨
- 데이터 레이크와 데이터 웨어하우스에 불필요하게 동일한 데이터가 저장됨
- 데이터 파이프라인이 2가지(Jenkins, Airflow)로 이원화되어 관리에 리소스가 소요됨
- 데이터 마트에 저장된 데이터를 데이터 웨어하우스에서 접근할 수 없음
또한, airflow 1.10.12 버전으로 구축하며 아래와 같은 문제점도 있었다.
- Kubernetes 기반이 아닌 단일 인스턴스에 컨테이너 기반 동작으로 빠른 확장성의 한계
- 단일 인스턴스의 자원 한계로 인해 동시에 처리할 수 있는 작업의 양이 제한되며, 큰 규모의 작업을 처리하기 어려울 수 있다. 또한, 고가용성 및 자동 복구 기능이 부족해 시스템의 안정성이 낮아질 수 있다.
- Airflow scheduler의 cpu 과점유 현상
- 스케줄러가 너무 많은 작업을 처리하려고 하거나, 작업을 실행을 위해 너무 자주 CPU를 점유하려고 할 때 발생할 수 있다.
- Airflow worker에 비즈니스 로직이 적용되어 있어 너무 무거워짐
- '비즈니스 로직이 적용되어 있다' = Airflow의 Task 내에 데이터 원본을 추출해 가져오고, 필요한 형식으로 변환하고, 변환된 데이터를 적재하는 작업이 포함되어 있다.
- 데이터 엔지니어가 플랫폼 문제를 해결하는데 많은 리소스가 들어감
2021년도 9월 ~ 2022년도 12월
이를 해결하기 위해 클라우드 서비스를 활용해 새로운 파이프라인을 구축하는 것이 좋겠다는 결론을 내리고 GCP 클라우드 서비스를 활용한 데이터 파이프라인을 구축했다.
GCP를 선택한 이유
- Bigquery를 사용하기 위해
- Firebase에서 Bigquery로 유저 데이터를 쉽게 가져 올 수 있음
- AWS에 비해 GCS, Bigquery의 데이터 보관 정책이 유연하고 비용이 더 저렴함
* Firebase: 구글이 제공하는 모바일 및 웹 앱을 개발하고 운영하기 위한 플랫폼으로, 사용자 인증, 데이터 베이스, 스토리지, 호스팅, 푸시 알림, 분석 등 다양한 기능을 제공하여 개발자가 애플리케이션을 더 빠르고 쉽게 개발하고 관리할 수 있다.
워크플로는 Ariflow만 사용하도록 정책을 세우고 기존에 직접 구축하여 운영하던 Airflow를 GCP의 Composer를 사용해 운영은 GCP가 하고, DE는 비즈니스를 담당하도록 역할을 분리했다.
* GCP composer: Apache Ariflow로 워크플로를 만들고 배포하기 위한 Google Cloud 솔루션
Apache Airflow 오픈소스 프로젝트 기반으로 구축되어 python 프로그래밍 언어로 작동되는 Cloud Composer는 서비스 전환이 자유롭고 사용하기 쉽다. Apache Airflow의 로컬 인스턴스 대신 Cloud Composer를 사용하면 사용자가 설치 또는 관리 오버헤드 없이 Airflow의 이점을 얻을 수 있다.
Airflow의 버전을 2.x로 업그레이드하여 scheduler의 CPU 과점유 현상을 해소했고, Airflow는 본 목적인 워크플로를 관리하는 용도로만 사용했다. 이를 위해 비즈니스 로직을 worker에 구현하여 처리하는 것이 아닌 별도의 VM을 호출해 비즈니스 로직을 담당하도록 역할을 분리했다. 즉, Airflow는 작업을 스케줄링하고 호출 및 모니터링만 담당하고 실제 동작은 별도의 VM에서 처리하는 구조로 구성했다.
이러한 Airflow를 사용하여 데이터 엔지니어는 ELT, 3rd Party 데이터 수집, 데이터 분석가가 필요한 집계 테이블 및 데이터 마트 생성을 진행하고 있다.
- 1st Party Data: 내가(기업이) 직접 수집한 고객의 데이터
- 2nd Party Data: 다른 기업이 직접 수집한 고객의 데이터를 구매
- 3rd Party Data: 특정한 주체가 아닌, 인터넷의 여러 소스로부터 수집되는 데이터
플랫폼을 GCP로 통일하고 ETL 방식을 ELT로 변경하여 데이터를 BigQuery에 저장하는 방식으로 전환했다. 이는 데이터가 최초부터 BigQuery에 저장되며, 저렴한 가격과 자동 가격 인하 정책 등의 장점이 있어 데이터 레이크 및 데이터 웨어하우스로 BigQuery를 활용했다. 또한, 운영 데이터를 추출하는 방식으로 embulk 오픈소스를 활용해 매시간 등록 및 수정된 데이터를 CDC 방식으로 추출하여 최신성을 유지했다. 디비지움 도입에는 개발 시간과 백엔드팀의 도움이 필요해 리소스 대비 운영 데이터를 실시간으로 유지하고 활용하는 임팩트가 적은 embulk를 선택하고, 디비지움은 백로그로 저장하는 방향으로 운영했다.
* embulk: 오픈 소스 데이터 이관 도구로, 다양한 데이터 소스와 대상 간의 데이터 이동을 지원하고 일반적으로는 ETL 작업에 사용된다. 다양한 플러그인을 통해 다양한 데이터베이스, 클라우드 서비스, 파일 형식 등과 통합될 수 있어 확장 가능한 데이터 이관 솔루션이다.
* 디비지움(Database Change Capture): 데이터베이스의 변경 내용을 실시간으로 캡처하여 로그에 저장하는 기술, 이를 통해 데이터베이스의 변경 이벤트를 모니터링하고 추적한다. 디비지움은 주로 데이터베이스의 변경 이력을 추적하고 CDC를 구현하는 데 사용된다.
* CDC(Change Data Capture): 데이터베이스나 데이터 스토리지 시스템에서 발생하는 변경사항을 감지하고 캡처하는 기술
이벤트 데이터는 Firebase를 사용하여 수집했으나 실시간 수집이 보장되지 않아 트렌드 파악이 어려웠고 BigQuery로 데이터 전달까지 시간이 걸려 의사결정이 지연되는 문제가 있었다. 또한 필요한 지표를 대시보드로 확인하는 데 시간이 오래 걸렸기 때문에 Amplitude를 도입하여 이를 해결했다. Amplitude를 통해 누구나 간편하게 지표를 확인할 수 있게 되었고, 모든 이벤트 데이터를 GCS에 적재하여 분석에 활용했다. BigQuery의 export 기능도 고려했으나 누락된 데이터가 존재해 GCS를 선택했다.
이렇게 데이터 파이프라인을 새로 구축하고 운영하며 많은 비즈니스 분석에 활용했으나 29CM가 빠르게 성장하며 아래와 같은 한계점에 봉착했다.
- 데이터 엔지니어의 데이터 마트 및 집계 테이블 생성 요청이 증가함
- 전체 데이터 조회로 인한 데이터 마트 및 집계 테이블 생성 빈도가 증가함
- CDC로 가져오는 운영 데이터가 실시간 반영되지 않음
- CDC는 hard delete된 row를 감지하지 못 함
- hard delete: 데이터베이스에서 데이터를 영구적으로 삭제하는 작업
- CDC는 특정 컬럼 수정 후 해당 컬럼이 수정되지 않으면 누락될 수 있음
- 이벤트 데이터의 실시간 수집이 지원되지 않음
- Amplitude의 비용 이슈로 특정 이벤트만 수집하고 있음
- 수집된 데이터의 위치, 담당자 확인, 문서화 관리가 어려움
2023년도 이후
Firebase 및 Amplitude에서의 이벤트 수집을 CDP로 대체하여 통합했다. 카프카를 직접 구축하는 것이 가장 이상적이지만 시간이 오래 걸릴 것으로 예상되어 SaaS 및 오픈소스 옵션을 검토했다. Segment, RudderStack, Snowplow 등의 SaaS CDP와 Snowplow의 오픈소스 버전을 고려했다.
* CDP(Customer Data Platform): 기업이 다양한 소스에서 수집한 고객 데이터를 통합, 관리, 분석하여 고객 경험을 개선하고 비즈니스 성과를 향상시키는 플랫폼
* RudderStack: 오픈 소스의 고객 데이터 플랫폼으로, 기업이 다양한 소스에서 수집한 고객 데이터를 효과적으로 관리하고 활용되는 도구
운영 데이터의 실시간 수집은 Debezium 오픈소스와 Apache Kafka를 활용하여 구축했다.
DBT를 사용하면 데이터 마트와 집계 테이블을 쉽게 생성할 수 있기 때문에 데이터 엔지니어와 데이터 분석가가 협업하여 변형을 관리할 수 있다. 이를 통해 엔지니어링 리소스를 절약하고 더 분석에 집중할 수 있다. 또한 Airflow와 DBT의 역할을 명확하게 분리하여 워크플로 관리와 변형 관리를 구분할 수 있다. DDP를 도입하여 데이터의 검색과 관리를 효율적으로 할 수 있어 데이터 관리의 효율성을 높이고 사용자들의 작업 효율을 향상시킨다. 현재 고려 중인 DDP는 GCP의 Dataplex나 오픈소스인 Datahub이다.
* DDP(Data Discovery Platform): 데이터 검색과 관리를 위한 플랫폼으로, 데이터를 중앙 집중화하여 데이터의 위치, 의미, 사용 등을 쉽게 파악하고 검색할 수 있도록 도와주는 도구 혹은 시스템이다.
후기
29CM의 데이터 파이프라인 변천사와 앞으로의 방향성을 살펴보았다. 자세하게 작성해 주셔서 각 단계에서 어떤 문제점이 있었고 이를 어떻게 해결하며 나아갔는지 이해하기 쉬웠다. 파이프라인 초기에는 아무래도 데이터 수집과 여러 워크플로로 리소스 낭비, airflow 한계가 보였는데 GCP를 도입하여 이를 해결한 점이 배울 점이라고 느껴졌다. 여기서의 한계점이 또 발견됐을 때 새로운 기술을 도입하고 지속적으로 발전해 나가는 과정이 인상 깊었다. 나도 어서 데이터 엔지니어로 입사하여 이러한 과정의 일원이 되어 같이 성장하고 싶다 ㅎㅎ
