AI Briefing

Airflow 개발 환경을 Docker Compose로 컨테이너화하기

·2023.12.04 15:30

Docker Compose로 로컬 Airflow를 배포 환경에 가깝게 맞추고 PyCharm 디버깅까지 가능하게 만들었다.

Airflow 개발 환경과 배포 환경의 실행 방식 차이로 생기던 설정 불일치를 줄이기 위해, 로컬 환경을 Docker Compose 기반으로 다시 구성했다.

기존에는 로컬에서 쓰는 Python 가상환경과 운영 환경이 서로 어긋나거나 OS 차이로 문제가 생겼고, “로컬에서는 되는데 배포 후 깨지는” 상황을 피하기 어려웠다. 컨테이너화로 동일한 형상에서 테스트하고, requirements.txt 변경도 격리된 환경에서 검증할 수 있게 했다.

구성의 핵심은 Airflow의 역할을 분리해 이해하는 것이었다.

  • Scheduler: DAG 실행을 스케줄링하고 메타데이터 DB에 상태를 기록
  • Executor: task 실행 방식을 결정하고 Worker를 조정
  • Webserver: UI로 DAG 상태를 확인

실행 방식은 Executor에 따라 달라졌다. 개발 환경에서는 단순한 SequentialExecutor를 썼고, 배포 환경에서는 확장성이 좋은 CeleryExecutor를 사용했다. 로컬에서도 배포 환경과 비슷한 실행 흐름을 만들기 위해, Redis, PostgreSQL, airflow-init, Scheduler, Webserver 등을 Docker Compose로 묶었다.

Compose를 선택한 이유는 멀티 컨테이너의 의존 관계를 한 번에 관리하기 좋기 때문이다. 먼저 RedisPostgreSQL을 띄우고, 그다음 airflow-init에서 variable과 connection을 초기화한 뒤, 마지막으로 Airflow 서비스들이 실행되도록 순서를 잡았다. depends_on으로 의존성을 정의하고, fragment와 extension 문법으로 YAML 중복도 줄였다.

배포 환경과의 정합성을 위해 다음도 반영했다.

  • 운영 환경에서 쓰는 Docker image를 base image로 사용
  • country, hadoop platform, phase 등을 환경변수로 주입
  • DB connection, logging, Python path 설정 반영
  • 로컬 DAG 디렉토리를 volume mount로 연결

이 작업을 마치면 단일 명령 docker compose up 으로 로컬에서 Celery executor mode의 Airflow를 실행할 수 있었다.

다음 과제는 PyCharm에서 이 컨테이너 환경을 개발·디버깅용으로 다루는 일이었다. 다만 PyCharm의 Docker Compose 지원에는 제약이 있었고, 실행 오류의 원인도 추적하기 어려웠다. 그래서 image를 변수로 두는 설계 대신, 국가별로 분리된 YAML을 만들고 latest 태그를 바라보게 바꿔서 IDE가 해석 가능한 형태로 맞췄다.

개발용 executor는 리소스가 무거운 CeleryExecutor 대신 LocalExecutor로 타협했다. 더 가볍고 빠르면서도, 기존 SequentialExecutor보다 병렬성을 확보할 수 있었기 때문이다. 구조는 공통 설정을 담은 YAML과 Local/Celery용 YAML을 분리해 관리하는 방식으로 정리했다.

PyCharm 실행과 디버깅을 위해서는 Run/debug configuration도 다시 설계했다. 초기화와 DAG 실행을 분리하는 방식은 재사용이 편하지만 관리 부담이 컸고, docker compose command로 단일화하는 방식은 매번 초기화를 다시 수행해야 했다. 최종적으로는 후자를 기본으로 두고, --force-recreate--exit-code-from 옵션을 활용해 테스트 종료와 컨테이너 정리를 자동화했다.

결과적으로 얻은 것은 두 가지였다.

  • 로컬에서도 배포 환경에 가까운 방식으로 DAG 실행을 확인
  • PyCharm에서 breakpoint를 찍고 DAG를 테스트·디버깅 가능

여기에 더해 Makefile target으로 테스트와 Airflow 관련 명령을 통일하고, 로컬의 airflow.cfg와 배포 환경의 Helm value를 Helm value 중심으로 정리해 관리 비용도 줄였다. Run configuration naming convention까지 정리하면서, 이후 DAG가 늘어나도 유지보수하기 쉬운 개발 환경을 만들었다.

이 요약은 원문 이해를 돕기 위한 큐레이션입니다. 저작권은 원저작자에게 있으며, 정확한 내용과 맥락은 원문을 확인하세요.

요약 오류, 출처 표기 문제, 삭제 요청은 문의 · 건의로 알려주세요.