컬리, Dataflow 기반 준실시간 수요 예측 파이프라인 구축기

컬리 데이터플랫폼팀이 Apache Beam과 Google Cloud Dataflow를 활용해 준실시간 수요 예측 시스템 파이프라인을 구축한 경험을 공유했다. 수요 예측 모델은 1년치 과거 데이터를 기반으로 시계열 연관성을 분석하며, 실시간으로 변하는 고객 주문 데이터를 반영하기 위해 준실시간 처리가 필수적이었다.

Dataflow 도입 배경과 아키텍처

컬리는 GCP 환경에서 대용량 분산처리와 스트리밍 프로세싱을 지원하며, 자동 스케일링과 리소스 최적화가 가능한 Dataflow를 선택했다. Apache Beam은 배치와 스트리밍 파이프라인을 모두 처리할 수 있는 프로그래밍 모델로, Dataflow의 백엔드 성능과 연동되어 실행된다. 데이터 흐름은 AWS MSK(Kafka)로 수집된 주문 데이터를 BigQuery에 적재하고, Dataflow가 이를 처리하는 구조다.

파이프라인 실행 원리와 주의점

Dataflow는 준비 단계(queued state)에서 Launcher VM이 그래프를 생성하고, 실행 단계(running state)에서 Worker VM이 실제 코드를 수행한다. 배치 파이프라인은 매번 Launcher 생성/종료로 인해 시간이 소요되므로, 준실시간성을 위해 1분 단위 배치를 설정하면 실패할 수 있다. 반면 스트리밍 파이프라인은 작업이 계속 실행되므로 최초 런칭 이후 동일한 환경에서 안정적으로 동작한다. 단, BigQuery는 유한한(bounded) 데이터 웨어하우스이므로 스트리밍 파이프라인 적용 시 배치 모드처럼 동작한다.

Flex 템플릿과 CI/CD 구축

반복적인 배포를 위해 Flex 템플릿을 사용했다. Flex 템플릿은 Docker 이미지와 템플릿 스펙 파일을 Artifact Registry와 GCS에 저장하여 재사용성을 높인다. GitHub Actions를 통해 CI/CD 워크플로우를 자동화했으며, 기존 스트리밍 작업 삭제, Docker 이미지 빌드 및 푸시, Flex 템플릿 빌드, Dataflow 작업 실행 순서로 진행된다.

운영 팁과 권한 관리

스트리밍 파이프라인에서는 Streaming Engine 사용을 권장한다. 이는 Worker VM의 부담을 줄이고 비용 절감에 도움이 되지만 별도 요금이 부과될 수 있다. 또한 save_main_session=True 설정으로 전역 변수 및 모듈 참조 문제를 방지해야 한다. 권한 관리 시 Dataflow Service Account와 Worker Service Account 두 계정이 모두 필요하며, VPC 통신 오류 등은 Dataflow Service Account의 역할 부족에서 기인할 수 있으므로 주의가 필요하다.