Airflow 해부 (1) 오케스트레이션 문제와 Airflow 구조

Airflow 해부 시리즈의 1편입니다. 전체 목차는 0편에 있습니다.

cron이 못 하는 것

매일 새벽 데이터를 수집하고, 끝나면 집계하고, 끝나면 학습하는 세 작업을 cron으로 걸면 세 가지가 수작업으로 남습니다.

• 의존 순서: cron은 시각만 압니다. 수집이 늦게 끝나면 집계가 빈 데이터로 돌아갑니다. 시간 간격을 넉넉히 두는 것은 해결이 아니라 회피입니다
• 실패 처리: 재시도, 실패 알림, 어디까지 성공했는지의 추적을 스크립트마다 직접 짜야 합니다
• 과거 재실행: “지난주 화요일 집계가 잘못됐으니 그날 것만 다시”를 cron은 표현할 수 없습니다

Airflow는 작업 의존성을 코드로 선언하면 이 셋을 대신합니다. 왜 이것이 ML 파이프라인에서 중요한지는 머신러닝 실전 워크플로 11편에 있습니다.

세 층 개념: DAG, task, task instance

Airflow의 개념은 세 층으로 정리됩니다.

• DAG: 작업 묶음의 정의. “수집, 집계, 학습을 이 순서로, 매일” 이라는 선언입니다. DAG는 Directed Acyclic Graph의 약자로, 의존성에 순환이 없어야 한다는 제약이 이름에 들어 있습니다
• task: DAG 안의 실행 단위 하나. “수집”이 task입니다
• task instance: 특정 날짜의 task 실행. “7월 21일의 수집”이 task instance이고, 상태(success, failed, running)는 이 단위로 관리됩니다

UI에서 보게 될 격자의 칸 하나가 task instance입니다. 재시도와 재실행도 이 단위로 일어납니다.

구성요소

구성요소	역할
scheduler	DAG 파일을 주기적으로 파싱하고, 실행 시각이 된 task instance를 executor에 넘긴다
executor	task를 실제로 어디서 실행할지 결정한다. LocalExecutor(같은 머신), CeleryExecutor와 KubernetesExecutor(분산)
metadata DB	DAG 정의, 실행 이력, 상태의 저장소. 개발은 SQLite, 운영은 PostgreSQL
web UI	DAG 조회, 수동 트리거, 로그 확인, 재실행
worker	분산 executor 구성에서 task를 실행하는 별도 프로세스

동작 흐름은 한 문장으로 요약됩니다. scheduler가 “지금 무엇을 돌릴 차례인지”를 metadata DB를 보고 판단하고, executor가 그것을 실행하고, 결과 상태가 다시 DB에 남는 순환입니다.

DAG 파일 ──파싱──> scheduler ──"이 task 돌릴 차례"──> executor ──실행──> task
                      ▲                                              │
                      └────────────── metadata DB <───상태 기록───────┘

이 구조에서 두 가지 함의가 나옵니다.

• scheduler는 DAG 파일을 계속 재파싱합니다. DAG 파일 상단에 무거운 코드를 두면 안 되는 이유이고, 6편의 함정으로 다시 나옵니다
• 모든 상태가 metadata DB에 있으므로, DB가 곧 Airflow의 단일 진실입니다. 운영에서 SQLite를 못 쓰는 이유도 여기 있습니다

Airflow가 아닌 것

경계를 정확히 잡아야 설계가 틀어지지 않습니다.

• 데이터 처리 엔진이 아닙니다. task 안에서 pandas나 Spark가 일하는 것이고, Airflow는 그 실행을 지휘합니다. 큰 데이터를 task 사이에서 직접 주고받는 설계는 3편의 XCom 한계에서 다룹니다
• 스트리밍 도구가 아닙니다. 배치 스케줄링이 본령이고, 초 단위 이벤트 처리는 다른 도구(Kafka 계열)의 영역입니다

다음 편에서 설치하고 첫 DAG를 돌립니다.

다음 글: Airflow 해부 (2) 설치와 첫 실행: constraint와 standalone