01. Workflow Orchestrator가 필요한 이유 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• Workflow orchestrator는 단순 scheduler와 무엇이 다른가?
• 여러 batch와 검증 작업이 얽힌 상황에서 Airflow가 어떤 운영 판단을 가능하게 하는가?
• DAG 성공과 데이터 품질 성공은 왜 분리해서 봐야 하는가?
• Java/Spring 백엔드 개발자는 어떤 경우 scheduler만으로 충분하고 어떤 경우 orchestrator가 필요한가?

개요

workflow orchestrator는 여러 작업의 순서와 상태를 관리하는 시스템이다.

cron은 “언제 실행할지”에 집중한다.

orchestrator는 “무엇이 무엇을 기다리고, 어디서 실패했고, 어디부터 다시 실행할지”까지 다룬다.

주문 추출, 결제 검증, mart 생성, 리포트 발송이 순서대로 연결되어 있다면 단순 scheduler만으로 운영하기 어렵다.

Airflow는 이런 작업들을 DAG로 표현하고 task 상태, retry, log, backfill, SLA를 관측하게 해준다.

Scheduler와 Orchestrator

단순 scheduler는 시간 트리거를 제공한다.

03:00 run extract
03:30 run transform
04:00 run report

이 구조에서는 extract가 실패해도 transform이 실행될 수 있다.

실패 복구도 사람이 로그를 찾아 순서를 판단해야 한다.

orchestrator는 dependency를 표현한다.

extract_orders -> validate_raw -> build_mart -> send_report

upstream이 실패하면 downstream은 실행되지 않는다.

어느 task부터 재실행할지 상태로 확인할 수 있다.

필요한 순간

orchestrator는 다음 상황에서 필요해진다.

• 작업이 세 개 이상이고 순서가 중요하다.
• 실패한 task만 다시 실행해야 한다.
• 과거 날짜를 backfill해야 한다.
• task별 retry와 timeout이 다르다.
• 완료 시각 SLA가 있다.
• 데이터 품질 검증을 workflow에 넣어야 한다.
• 여러 팀이 같은 pipeline 상태를 봐야 한다.

작업 하나를 매일 실행하는 수준이면 Spring Scheduler나 cron으로 충분할 수 있다.

작업 간 의존성과 재처리 범위가 운영 이슈가 되면 orchestrator가 필요하다.

DAG 성공과 데이터 성공

Airflow task가 success여도 데이터가 맞는 것은 아니다.

SQL이 0건을 insert하고도 성공할 수 있다.

API 호출이 200을 반환했지만 source 데이터가 비어 있을 수 있다.

따라서 DAG에는 validation task가 필요하다.

extract -> transform -> load -> validate_quality -> publish_report

report 발송은 validation 이후로 둔다.

품질 검증이 실패하면 DAG는 실패하거나 별도 incident를 만들어야 한다.

운영 가시성

orchestrator는 운영 질문에 답하게 해준다.

• 어느 task가 실패했는가?
• 몇 번째 retry인가?
• upstream 때문에 기다리는가, worker queue 때문에 밀렸는가?
• SLA를 넘겼는가?
• backfill run과 regular run이 충돌하는가?
• 실패한 날짜 partition은 무엇인가?

이 질문에 답하지 못하면 장애 때 사람이 로그를 조합해야 한다.

Airflow의 가치는 Python 코드보다 이 운영 가시성에 있다.

백엔드 관점

백엔드 개발자는 Airflow를 업무 로직 저장소로 보지 않아야 한다.

복잡한 정산 계산은 Spring Batch나 service module에서 테스트한다.

Airflow task는 그 job을 parameter와 함께 호출하고 결과를 관측한다.

Airflow task
  -> java -jar batch.jar --job=build-order-mart --date={{ ds }}

이렇게 하면 업무 로직은 백엔드 코드로 버전 관리하고, Airflow는 실행 순서와 상태를 관리한다.

실패 모델

• cron으로 여러 job을 따로 돌려 upstream 실패를 downstream이 모른다.
• DAG에 업무 계산 로직을 많이 넣어 테스트와 배포가 어렵다.
• validation 없이 report 발송 task가 실행된다.
• backfill run이 regular run과 같은 target을 동시에 쓴다.
• SLA miss와 task failure를 같은 알림으로 처리한다.

이 실패들은 “job이 실행됐다”는 사실만으로는 보이지 않는다.

workflow 상태와 데이터 검증을 함께 봐야 한다.

운영 지표

• DAG run success/failure count: workflow 결과다.
• task retry count: 일시 오류 빈도다.
• task duration: task별 지연이다.
• queued task count: worker capacity 문제다.
• SLA miss count: 늦은 성공이다.
• validation failure count: 데이터 품질 실패다.
• backfill run count: 과거 재처리 실행량이다.

DAG failure와 validation failure는 분리해서 봐야 한다.

원인이 task 실행 실패인지 데이터 내용 실패인지 대응이 다르다.

개인 프로젝트 기준

개인 프로젝트에서는 Airflow를 크게 꾸미지 않아도 된다.

하나의 DAG에 extract, transform, validate, publish task를 둔다.

한 task를 실패시켜 downstream이 실행되지 않는지 확인한다.

과거 날짜 하나를 backfill하고 target이 중복되지 않는지 확인한다.

이 네 가지가 orchestrator의 필요성을 보여준다.

위험 신호!

• Airflow를 cron 대체품으로만 쓴다.
• DAG에 복잡한 business 로직이 들어간다.
• validation 없이 DAG success를 데이터 success로 본다.
• backfill과 regular run 충돌 정책이 없다.
• task owner와 alert channel이 없다.

확인 질문

확인 질문

• 이 workflow에서 upstream 실패가 downstream 실행을 막는가?
  • dependency가 DAG에 표현되어야 한다.
• DAG success 이후 데이터가 맞는지는 무엇으로 검증하는가?
  • validation task와 품질 SQL이 필요하다.
• 이 작업은 scheduler로 충분한가, orchestrator가 필요한가?
  • task 수, dependency, retry, backfill, SLA 요구로 판단한다.

참고 문서

• Apache Airflow Documentation
• Spring Batch Reference
• Martin Kleppmann, Designing Data-Intensive Applications