Airflow Workflow Orchestrator
3줄 요약
Airflow Workflow Orchestrator 챕터는 여러 batch, 검증, 적재, 알림 작업의 순서, 재시도, SLA, backfill을 DAG로 관측하고 제어하는 방법을 다룬다.- 핵심은 Airflow가 업무 로직 실행기가 아니라 dependency, schedule, task state, retry, catchup, operational visibility를 관리하는 orchestrator라는 점이다.
- Java/Spring 백엔드 개발자는 Spring Batch가 처리 로직을 맡고 Airflow가 workflow 운영을 맡는 경계를 설명할 수 있어야 한다.
핵심 정리
Workflow Orchestrator가 필요한 이유: orchestrator는 여러 작업의 순서와 상태를 한곳에서 보게 해 실패 지점, 재시도 범위, downstream 영향 범위를 찾게 한다.DAG Task Operator 개념: DAG는 의존성 그래프, task는 재시도와 상태를 갖는 실행 단위, operator는 Python, Bash, HTTP, Kubernetes 등 실행 방식이다.Dependency Retry SLA: dependency는 순서, retry는 일시 오류 흡수, SLA는 늦은 성공도 운영 사건으로 만드는 기준이다.Airflow DAG 예시: 좋은 DAG는 schedule, catchup, task boundary, idempotency, validation task, owner와 alert가 코드에 드러난다.백엔드 Batch와 Airflow 경계: Spring Batch는 업무 처리와 chunk transaction에 강하고, Airflow는 여러 job의 orchestration과 관측에 강하다.- 이 챕터는 Web-Database의 query/transaction이 아니라 pipeline 작업들의 실행 순서, 실패 복구, 지연 관측을 다룬다.
헷갈리는 지점
- Airflow를 batch 처리 로직을 작성하는 곳으로 오해하기 쉽다.
- 복잡한 업무 로직은 테스트 가능한 Spring Batch나 service code에 두는 편이 낫다.
- DAG에는 dependency, schedule, parameter, retry, alert, validation을 남긴다.
- DAG 성공을 데이터 성공으로 착각하기 쉽다.
- task가 모두 success여도 source와 target count, freshness, accuracy 검증이 실패할 수 있다.
- 그래서 validation task와 품질 rule이 DAG에 연결되어야 한다.
- catchup과 backfill을 켜면 과거 데이터가 자동으로 안전하게 채워진다고 보기 쉽다.
- 과거 DAG run은 운영 DB와 target mart에 대량 부하를 줄 수 있다.
- task idempotency, rate limit, range 검증 없이 catchup을 켜면 장애를 키운다.
확인 질문
- 이 챕터의 핵심 판단 기준은 무엇인가?
- 어떤 task가 어떤 upstream을 기다리고, 실패 시 어디부터 재시도하며, SLA miss와 데이터 품질 실패를 어떻게 분리해 볼 수 있는지다.
- Web-Database와의 경계는 무엇인가?
- Web-Database는 DB 내부 query와 transaction을 다루고, 이 챕터는 여러 batch/pipeline 작업의 orchestration과 운영 상태를 다룬다.
- 개인 프로젝트에서 최소로 챙길 것은 무엇인가?
- DAG 하나, 3개 이상 task dependency, retry 설정, catchup 의도, validation task, 실패 후 재실행 방법이다.