토스, DW 파이프라인 도메인별 분리

ai.euno.news 자동 뉴스 요약

토스가 400개가 넘는 데이터 웨어하우스(DW) 파이프라인을 하나의 에어플로(Airflow) 클러스터에서 실행하던 구조를 도메인별 클러스터로 분리하고 있다. 실행 환경은 나누되 코드와 공통 문맥은 단일 저장소에 유지하는 방식이다. 토스 내부에서 ‘뉴타운’이라 부르는 새 플랫폼으로 광고 도메인을 옮긴 결과, DAG 코드는 2,794줄에서 100줄로, 테이블 실행 순서를 수동으로 연결한 코드는 180줄에서 0줄로 줄었다. 파이프라인 실행 시간도 4시간에서 2시간 30분으로 단축됐다.¹

기존에는 광고·쇼핑·결제·금융 등 도메인 마트와 중앙 DW팀의 공통 마트가 모두 한 클러스터에서 실행됐다. 이 때문에 한 도메인의 배치가 몰리면 다른 도메인도 지연됐고, 파이프라인 하나를 수정할 때 다른 도메인의 실행 방식까지 파악해야 했다. 비슷한 로직이 표준 없이 복제되는 문제도 있었다.

새 구조에서는 도메인마다 별도의 DW Airflow 클러스터를 둔다. 현재 ads, foundation, finops, fmd, dw-core 등 5개가 운영되고 있다. 다만 기존 파이프라인을 대규모로 이전한 곳은 아직 광고 도메인뿐이며, 나머지는 신규 마트 개발과 이전 준비에 주로 쓰인다. 저장소는 하나로 유지해 플랫폼팀이 공통 모듈을, 각 도메인 팀이 도메인별 디렉터리를 관리한다. 실행 장애와 배포의 영향 범위는 분리하면서 공통 코드와 데이터 생성 문맥은 한곳에서 찾을 수 있게 한 설계다.

변환 로직은 임팔라(Impala)에 직접 실행하던 쿼리에서 디비티(dbt) 모델로 옮겼다. SQL에는 SELECT 중심의 비즈니스 로직만 남기고, 테이블 생성과 적재 및 모델 간 의존성 관리는 dbt가 맡는다. 코스모스(Cosmos)는 dbt 모델 하나를 Airflow 태스크 하나로 펼친다. Spark 작업이나 다른 클러스터의 테이블을 기다리는 센서처럼 dbt가 표현하지 못하는 작업은 별도 래퍼가 선언을 읽어 태스크와 의존성을 자동 생성한다.

이전에는 스트랭글러 피그(Strangler Fig) 방식을 적용했다. 기존 시스템을 멈추지 않고 새 플랫폼을 옆에 구축한 뒤 도메인 단위로 기능을 넘기는 방식이다. 한 마트는 기존 파이프라인과 새 파이프라인에서 하루 두 번 생성해 3주간 결과를 비교했다. 일정상 기존 시스템 준비가 더 필요해 전환을 되돌렸을 때도 기존 새벽 배치는 계속 실행돼 이용자에게 영향이 없었다.

토스는 이전 범위를 의도적으로 제한했다. Spark 작업은 dbt로 바꾸지 않았고 Jenkins 작업도 유지하되 새 작업만 만들지 못하게 했다. 모든 요소를 한꺼번에 교체하면 이전이 늦어지고 두 플랫폼의 병행 운영 기간이 길어진다는 판단이다. 이번 구조의 핵심은 전면 재작성보다 실행 책임을 도메인에 나누면서도, 파이프라인을 이해하는 데 필요한 코드와 문맥은 흩어뜨리지 않은 데 있다.

읽기 목록은 이 브라우저에 저장됩니다.