Airflow

DAG 중심 배치 오케스트레이터의 구조와 장단점은 무엇인가.

Scope

핵심 질문

Apache Airflow는 DAG 기반 워크플로 오케스트레이터로서 어떤 구조와 장단점을 가지는가?

Research

핵심 근거

Airflow scheduler는 DAG와 task 상태를 모니터링하고 의존성이 충족된 task instance를 executor에 넘긴다.
Airflow는 Python으로 DAG를 정의하지만 실행 시에는 scheduler, metadata database, executor, worker 등의 운영 구성요소가 필요하다.
배치 데이터 파이프라인과 backfill에 강하지만 매우 동적인 애플리케이션 워크플로에는 복잡성이 커질 수 있다.

참고 자료

Airflow Scheduler 3.3.1: https://airflow.apache.org/docs/apache-airflow/stable/concepts/scheduler.html

Draft

Apache Airflow는 작업 간 의존성을 DAG로 정의하고 스케줄링, 실행상태, 재시도, backfill을 관리하는 대표적인 워크플로 오케스트레이터다.

실행 구조

Airflow에서 DAG는 어떤 task가 어떤 task 뒤에 실행되어야 하는지를 표현한다. Scheduler는 DAG와 task 상태를 지속적으로 확인하고 실행 가능한 task instance를 executor에 넘긴다. Executor는 실제 실행 위치와 방식을 결정한다.

Metadata Database는 DAG run, task instance, 스케줄, 상태 같은 운영정보를 저장한다. 규모가 커지면 scheduler, web UI, worker, database를 별도 구성요소로 운영하게 된다.

강점

Airflow는 정기 배치와 데이터 파이프라인에 매우 잘 맞는다. 날짜별 실행, 과거 기간 backfill, 실패 task 재실행, 실행 이력 확인 같은 기능이 성숙해 있다.

Python으로 DAG를 작성하므로 일반 코드와 연동하기 쉽고 생태계도 크다.

복잡성이 생기는 지점

Airflow 자체가 상당한 운영시스템이므로 몇 개의 단순한 스크립트만 돌리는 환경에서는 과할 수 있다. 또한 DAG parse, metadata DB, scheduler와 executor의 상호작용을 이해해야 장애를 진단할 수 있다.

워크플로가 실행 중 동적으로 계속 형태를 바꾸거나 장시간 외부 이벤트를 기다리는 경우에도 DAG 중심 모델이 어색할 수 있다.

적합한 사용처

정기적인 ETL, 데이터 웨어하우스 적재, ML batch pipeline처럼 '언제 어떤 순서로 무엇을 실행했는가'가 중요한 환경에 특히 적합하다.

Airflow의 핵심 가치는 task 실행 그 자체보다 반복 가능한 스케줄, 상태 추적과 운영 이력 관리에 있다.