Airflow는 왜 복잡해지는가

Scope

핵심 질문

Airflow는 작은 DAG에서 시작해도 운영 규모가 커질수록 왜 복잡성이 빠르게 증가하는가?

Research

핵심 근거

scheduler, metadata DB, executor, worker와 DAG parsing이 서로 연결되어 운영문제가 발생한다.
작업 수와 DAG 수가 늘면 scheduler throughput, DB 부하, parsing time이 중요해진다.
비즈니스 로직과 orchestration logic이 DAG 파일에 과도하게 섞이면 테스트와 재사용이 어려워진다.

참고 자료

Airflow 3.3.2, Architecture Overview (scheduler, DAG processor, executor and metadata database): https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html
Airflow 3.3.2, Dag File Processing (DAG parsing and processor tuning): https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/dagfile-processing.html

Draft

Airflow의 복잡성은 DAG 문법 자체보다 운영 구성요소와 상태가 늘어나는 데서 생긴다.

Scheduler와 Metadata DB

Scheduler는 DAG 상태를 읽고 실행 가능한 task를 판단하며 모든 실행상태는 metadata DB에 누적된다. 규모가 커지면 DB latency와 scheduler throughput이 전체 시스템 성능에 직접 영향을 준다.

Executor와 Worker

실행방식에 따라 local, Celery, Kubernetes 등 추가 계층이 생긴다. Task 실패가 코드 문제인지 worker 문제인지 queue 문제인지 구분해야 한다.

DAG Parsing

Airflow의 DAG processor는 DAG 정의 파일을 읽고 파싱한다. import 시 무거운 작업이나 외부 시스템 조회가 반복되면 파싱 시간에 영향을 줄 수 있지만, scheduler·processor 배치와 성능 영향은 Airflow 버전과 설정·DAG 수에 따라 확인해야 한다.

코드 경계

ETL 로직까지 DAG 파일 안에 넣으면 Airflow 없이는 테스트하기 어렵다. 독립 함수나 package로 비즈니스 로직을 분리하고 DAG는 wiring에 집중하는 편이 낫다.

핵심

Airflow는 작업이 많아져서만 복잡해지는 것이 아니다. orchestration, execution, metadata, deployment가 한 운영시스템에서 만나는 지점이 많기 때문에 복잡해진다.