컬리 데이터플랫폼팀이 준실시간 수요예측 모델을 안정적으로 서빙하기 위해 Apache Beam 기반 Google Dataflow로 파이프라인을 구축한 경험의 1편이다. Dataflow 도입 배경과 서비스 동작 원리, Flex 템플릿 빌드와 CI/CD 배포까지를 다룬다.
핵심 포인트- 시계열 통계 수요예측은 1년치 과거 데이터가 필요해 BigQuery 기반이면서, 실시간 주문을 빠르게 반영해야 해 준실시간 서빙이 필요했다.
- Dataflow는 배치·스트리밍을 완전관리형으로 처리하고 auto-scaling·rebalancing을 자동 수행해 인프라 관리 부담을 줄인다.
- 프로그래밍 모델은 Apache Beam(Batch+Streaming)으로, 실행 엔진은 Flink·Spark·Dataflow 등이 있고 Dataflow는 그중 하나다.
- 작업은 준비 단계(launcher VM이 그래프 생성)와 실행 단계(worker VM이 코드 실행)로 나뉜다.
- 반복 배포를 위해 파이프라인을 Flex 템플릿(도커 이미지와 GCS 스펙 파일)으로 패키징하고 GitHub Actions로 CI/CD를 구성했다.
상세 정리- 파이프라인 필요성: 주문 데이터는 AWS MSK(Kafka)로 수집 후 BigQuery에 적재된다. Kafka는 최신 스트리밍만, BigQuery는 전체 과거 데이터를 보유해, 1년치 input이 필요한 통계모델은 BigQuery 기반 파이프라인이 필요했다.
- 준비 단계(Queued): launcher VM이 환경 설정(라이브러리·도커 pull), 리소스 권한·유효성 검사(GCS·BigQuery·service account), Beam 메서드를 그래프 노드로 serialize한다. 문제가 있으면 여기서 중단되고, 정상이면 그래프를 json으로 Dataflow 엔드포인트에 전송한다.
- 실행 단계(Running): worker VM이 노드화된 메서드를 실제 실행하고, 자동확장 설정 시 리소스에 맞춰 worker 수를 조정한다.
- 배치 vs 스트리밍: 배치는 주기마다 작업 생성·종료로 launcher 기동에만 5분 이상 걸려 1분 배치는 실패했다. 스트리밍은 한 번 생성되면 계속 실행되나 unbounded 소스(Kafka·Pub/Sub)만 가능하고, BigQuery는 bounded라 스트리밍 모드로 걸어도 최초 1회만 실행된다.
- Flex 템플릿: 도커 이미지(Artifact Registry)와 템플릿 스펙 파일(GCS)로 구성한다. Dockerfile은 template-launcher-base 이미지에 apache-beam 버전을 명시(런칭 속도를 위해 requirements.txt에 넣지 않음)하고, Java I/O(ReadFromKafka 등)를 위해 JDK를 추가 설치한다. main.py는 save_main_session=True로 global import·함수를 세션에 저장한다.
- CI/CD: GitHub Actions에서 GCP 인증 후 기존 스트리밍 작업을 prefix로 찾아 cancel하고, 도커 이미지를 빌드해 버전·latest 태그로 push하며, flex-template build로 GCS에 스펙을 저장하고, flex-template run으로 service account·staging/temp 경로를 지정해 작업을 시작한다.
- 운영 팁: 스트리밍은 streaming engine을 켜 실행을 worker VM 대신 Dataflow 백엔드로 넘겨 비용과 오토스케일을 효율화한다. 권한은 worker service account뿐 아니라 Dataflow service agent에도 필요해, VPC 통신 시 service agent에 Compute Network User 역할이 없으면 1초 만에 실패한다.
왜 읽나GCP Dataflow/Beam으로 데이터·ML 서빙 파이프라인을 처음 구축하는 엔지니어에게 서비스 동작 원리와 Flex 템플릿·CI/CD·권한 함정을 정리한 입문 레퍼런스.
마켓컬리 Hello World·
Cloudflare Blog·
GitHub Engineering·