BigQuery 파이프라인 오케스트레이션, Airflow 3 전환으로 처리시간 32% 단축한 사례

AS-IS: BigQuery 위에서 돌아가는 대용량 파이프라인의 한계

Pine59는 시간 단위부터 분기 단위까지 다양한 주기로 분석 지표를 생성하는 회사인데요, 그중 Daily Foot Traffic이라는 지표는 한 번의 작업으로 최대 1400만 개의 개별 위치 데이터를 처리합니다. 이 회사의 시스템은 전체가 Google Cloud 위에서 돌아가고, 무거운 연산은 BigQuery가 맡고 전체 흐름은 Managed Service for Apache Airflow(과거 Cloud Composer)가 오케스트레이션합니다. 데이터 볼륨과 머신러닝 워크로드가 함께 늘어나면서, 수백 개의 DAG(작업 흐름 정의)를 담고 있는 모노레포를 현대화할 필요가 생겼어요. 기존 Gen 2 환경에서는 처리량이 몰리는 시점에 작업이 큐(대기열)에 걸린 채로 오래 머무는 문제가 있었습니다.

이번 내용: Gen 3 전환과 ML 오케스트레이션 분리

Pine59는 프로덕션 워크로드를 새로 나온 Managed Airflow(Gen 3, Airflow 3 기반) 환경에 스트레스 테스트로 먼저 돌려봤고, 결과가 확실했다고 해요. 처리 속도와 작업 스케줄링, 전체 안정성이 곧바로 눈에 띄게 좋아져서 전면 전환을 결정했습니다. ML 추론 작업의 경우 예전에는 표준 Kubernetes operator를 썼는데, Gen 3의 고도로 최적화되고 추상화된 인프라 레이어로 옮기면서 모델 추론에 특화된 별도의 GKE(Google Kubernetes Engine) 클러스터를 구성해 파이프라인에 통합했습니다. 오케스트레이션과 무거운 ML 실행 컴퓨팅을 분리한 덕분에 데이터 처리와 모델 추론이 각각 효율적으로 돌아가게 됐어요. 개발 생산성 측면에서는 Airflow 3의 플러그인 작성 시스템을 활용해 Airflow Logs와 XCom 탭에서 내부 BigQuery 테이블 참조를 자동으로 감지해 BigQuery Studio 링크를 바로 생성해주는 BigQuery Auto-linkify, DAG run 페이로드 안의 키-값 쌍을 검색해 해당 실행을 즉시 찾아주는 DAG Run Configuration Search 같은 커스텀 플러그인을 만들었습니다. 또 버전 간 operator 마이그레이션을 매끄럽게 하는 호환성 shim 레이어도 모노레포에 배포했어요.

실무 적용 포인트

300건 이상의 동일 DAG 실행을 비교한 결과 Gen 2와 Gen 3 사이 큐 대기시간 차이가 뚜렷했고, 내부 DAG 최적화와 맞물려 Daily Foot Traffic 파이프라인 처리시간이 38분에서 26분 미만으로 약 32% 줄었습니다. 대용량 BigQuery 파이프라인을 운영하는 팀이라면 체크할 포인트는 이렇습니다.

• 큐 지연이 잦다면 인프라 자체보다 오케스트레이션 레이어 버전부터 점검한다
• ML 추론과 오케스트레이션 컴퓨팅을 같은 클러스터에서 돌리고 있다면 분리를 검토한다
• DAG 개수가 많아 디버깅이 오래 걸린다면 로그, XCom 연동형 플러그인으로 관찰성을 높인다
• 버전 업그레이드 전 프로덕션 워크로드로 스트레스 테스트를 먼저 돌려 개선폭을 확인한다

자주 묻는 질문

bigquery 란 무엇인가요

BigQuery는 Google Cloud가 제공하는 서버리스 데이터 웨어하우스로, 대용량 데이터를 저장하고 SQL로 빠르게 쿼리하는 데 쓰입니다. 이번 사례에서는 Pine59가 위치 데이터를 처리하는 핵심 연산 엔진으로 BigQuery를 쓰고, 그 실행 흐름을 Airflow가 오케스트레이션하는 구조예요.

bigquery와 motherduck 비교하면 어떤가요

이번 원문에는 motherduck 관련 내용이 없어 직접 비교는 어렵습니다. 다만 원문 사례를 보면 BigQuery는 Google Cloud 생태계 안에서 Airflow, GKE 같은 오케스트레이션과 컴퓨팅 도구들과 긴밀하게 통합돼 대용량 파이프라인을 운영하는 데 강점을 보입니다.

Airflow 버전 업그레이드만으로 파이프라인 속도가 개선되나요

Pine59 사례에서는 BigQuery 자체 변경 없이 Managed Airflow를 Gen 2에서 Gen 3로 올린 것만으로 큐 대기시간이 크게 줄고 파이프라인 처리시간이 32% 단축됐습니다. 다만 이는 300건 이상 실행을 비교한 특정 사례 결과이고, 내부 DAG 최적화 작업도 함께 진행됐다는 점을 감안해야 해요.

오케스트레이션과 ML 추론 컴퓨팅을 분리하면 뭐가 좋은가요

Pine59는 ML 추론 전용 GKE 클러스터를 별도로 구성해 오케스트레이션 레이어와 분리했는데, 이렇게 하면 데이터 처리와 모델 추론이 서로 자원을 두고 경쟁하지 않고 각자 효율적으로 돌아갑니다. 원문은 이를 엔터프라이즈 MLOps를 위한 견고하고 확장 가능한 백본이라고 설명합니다.