8편 · 약 21분

운영 대시보드: SLA miss, queue delay, task duration, scheduler health

Airflow 대시보드는 “성공/실패 표”가 아니라 control plane 계기판이다

Airflow를 처음 운영하면 대시보드가 DAG별 성공/실패를 보는 화면처럼 느껴진다. 하지만 운영 관점에서는 그보다 더 중요한 질문이 있다.

DAG가 제시간에 시작했는가?
task가 worker를 배정받기 전 queue에서 얼마나 기다렸는가?
실행이 시작된 뒤 어느 task가 오래 걸렸는가?
scheduler, triggerer, DAG processor, metadata DB는 살아 있고 충분히 빠른가?

이 질문을 분리하지 못하면 “DAG가 늦었다”는 하나의 증상 아래 서로 다른 원인이 섞인다. 예를 들어 같은 40분 지연이라도 원인은 전혀 다를 수 있다.

scheduler가 DAG 파일을 늦게 파싱했다.
task가 scheduled에서 queued로 전환되지 못했다.
executor queue에는 들어갔지만 worker slot이 없었다.
task code 자체가 느려졌다.
metadata DB가 느려져 상태 전이가 밀렸다.
외부 warehouse/API가 느려져 task duration이 늘었다.

운영 대시보드의 목적은 예쁜 그래프를 만드는 것이 아니라, 이 원인을 몇 분 안에 갈라내는 것이다.

1. 먼저 지표를 네 층으로 나눈다

Airflow 관측성은 DAG 화면 하나로 끝나지 않는다. 최소한 다음 네 층을 분리해야 한다.

Deadline / SLA

정해진 완료 시각

deadline miss / SLA miss

→

Scheduling

logical date → queued

schedule delay / queued 수

→

Execution

start → finish

task duration / retry / failure

→

Control plane

scheduler / DB / triggerer

heartbeat / parse time / pool

대시보드는 “늦었다”를 “deadline 문제인지, queue 문제인지, 실행 문제인지, scheduler health 문제인지”로 빠르게 분류해야 한다.

Airflow 운영 대시보드의 네 층

이 네 층을 섞으면 알림도 쓸모없어진다. task duration이 늘어난 DAG와 scheduler heartbeat가 끊긴 Airflow는 대응자가 다르고, 완화책도 다르다. 전자는 query, Spark job, 외부 API, 데이터 skew를 보지만, 후자는 scheduler process, metadata DB, DAG parsing, executor capacity를 먼저 본다.

2. SLA miss와 Deadline Alert: “늦게 끝남”을 명시적으로 정의한다

Airflow 2.x에서는 task 수준의 sla와 sla_miss_callback을 많이 떠올린다. Airflow 3.1 이후에는 공식 문서에 Deadline Alerts가 추가되었다. Deadline Alert는 DAG run 기준으로 reference, interval, callback을 정의해 deadline 초과 시 callback을 실행하는 방식이며, Airflow 3.2 문서 기준 아직 experimental로 안내된다.

운영자가 기억할 점은 “SLA”라는 단어보다 기준 시각을 무엇으로 잡을지다.

기준	의미	적합한 상황
logical/scheduled time 기준	원래 스케줄 시각부터 완료 기한을 계산	매 시간/매일 정해진 시간까지 데이터가 나와야 하는 batch
queued time 기준	DAG run이 queue에 들어간 뒤 일정 시간 안에 완료되어야 함	scheduler/executor backlog를 포함한 처리 시간 감시
fixed datetime 기준	실제 업무 마감 시각을 기준으로 감시	“매일 08:30까지 리포트 발행” 같은 약속
historical average 기준	과거 평균 runtime에 여유분을 붙여 감시	workload 변동을 반영한 이상 징후 탐지

대시보드에는 deadline miss를 단순 count로만 두지 말고 다음 정보를 같이 보여주는 편이 좋다.

어느 DAG/run이 miss되었는가?
기준 시각이 logical date인지 queued time인지?
miss 폭은 몇 분인가?
같은 시점에 queue delay, executor queued tasks, scheduler heartbeat도 나빠졌는가?
task는 실행 중이었는가, queue에 있었는가, 이미 실패했는가?

예를 들어 “마감 20분 초과”만 보고 task owner를 호출했는데 실제로는 scheduler heartbeat가 멈춰 모든 DAG가 밀린 상황이면 대응이 늦다. 반대로 scheduler가 정상이고 특정 DAG의 한 task duration만 늘었다면 platform 장애가 아니라 workload 또는 downstream 장애로 좁혀야 한다.

3. Queue delay: worker가 바쁜지, scheduler가 느린지 구분한다

queued 상태는 Airflow 운영에서 가장 중요한 중간 신호 중 하나다. task가 queued에 오래 머무른다는 것은 scheduler가 task를 실행 대상으로 넘겼지만 executor/worker/pool 쪽에서 아직 실행을 시작하지 못했다는 뜻에 가깝다. 하지만 모든 지연이 queue delay는 아니다. scheduled에 오래 머무르면 scheduler loop, dependency check, metadata DB, pool slot 계산을 의심해야 한다.

공식 metrics 문서는 StatsD 또는 OpenTelemetry로 Airflow metric을 내보낼 수 있다고 설명한다. Airflow가 제공하는 metric 중 queue와 capacity를 볼 때 자주 쓰는 축은 다음과 같다.

관측 대상	대표 metric 또는 화면	해석
executor queue	`executor.queued_tasks`	실행 대기 task가 쌓이는지 확인
executor running	`executor.running_tasks`	worker가 실제로 task를 처리 중인지 확인
executor open slot	`executor.open_slots`	capacity가 남는데도 queue가 쌓이는지 확인
pool slot	`pool.open_slots`, `pool.used_slots`, `pool.starving_tasks`	특정 pool 제한 때문에 밀리는지 확인
DAG run schedule delay	`dagrun.schedule_delay` 계열 timer	예정된 run이 실제 시작까지 늦어진 정도 확인
UI Gantt/Grid	queued 시간, run latency	특정 DAG/task 단위로 병목 구간 확인

해석 순서는 다음처럼 잡을 수 있다.

queued_tasks가 늘고 open_slots가 0에 가깝다.

- worker/executor capacity 부족, pool 제한, Kubernetes pod scheduling 지연을 본다.

queued_tasks가 늘지만 open_slots가 남는다.

- executor 통신, worker health, queue broker, pool 설정 불일치를 본다.

queued보다 scheduled가 오래 쌓인다.

- scheduler loop, metadata DB latency, DAG parsing, dependency check 비용을 본다.

특정 pool의 starving_tasks만 늘어난다.

- 외부 시스템 보호용 pool 제한이 의도대로 동작하는지, 아니면 너무 보수적인지 검토한다.

Queue delay 알림은 전역 평균 하나로 만들면 위험하다. backfill 중인 낮은 우선순위 DAG가 queue를 채우는 상황과, 매일 아침 고객 리포트 DAG가 queue에서 밀리는 상황은 심각도가 다르다. 중요한 DAG에는 별도 태그, pool, priority weight, deadline을 붙여 대시보드에서 분리하는 편이 낫다.

4. Task duration: 느린 task와 늦게 시작한 task를 분리한다

Airflow metric에는 task duration 계열 timer가 있다. legacy 형태로는 dag.<dag_id>.<task_id>.duration처럼 보일 수 있고, 최신 문서에서는 identifier가 tag로 붙는 metric도 설명된다. Datadog의 Airflow 모니터링 글도 Gantt Chart를 통해 task별 duration과 queued 상태를 분리해 latency 원인을 볼 수 있다고 설명한다.

실무 대시보드에서는 다음 세 값을 분리해서 봐야 한다.

값	계산 관점	원인 후보
queue time	queued_at → start_date	worker 부족, pool 제한, executor/broker 문제
run time	start_date → end_date	task code, SQL, Spark job, 외부 API, 데이터 skew
end-to-end latency	logical_date 또는 queued_at → end_date	schedule delay + queue delay + run time 전체

Task duration을 볼 때 흔한 실수는 평균만 보는 것이다. 평균은 retry, long tail, 특정 partition skew를 숨긴다. 운영 대시보드에는 최소한 p50/p90/p95 또는 “최근 20회 중 최대” 같은 긴 꼬리 지표를 같이 둔다.

Task duration 증가를 triage할 때는 다음 질문을 순서대로 닫는다.

모든 task가 비슷하게 느려졌는가, 특정 operator만 느려졌는가?
같은 DAG의 upstream이 늦어져 downstream이 늦게 시작했을 뿐인가?
retry가 duration을 늘린 것처럼 보이게 만들었는가?
데이터량, partition 수, 파일 수, query plan이 변했는가?
외부 시스템의 rate limit, lock, warehouse queue가 있었는가?
같은 시간대에 worker CPU/memory/IO 또는 Kubernetes eviction이 있었는가?

대시보드에는 task duration 그래프 옆에 task log 링크, 최근 실패/재시도 count, 실행된 worker/pod, 관련 pool을 함께 배치하면 원인 분석 시간이 줄어든다.

5. Scheduler health: heartbeat 하나만으로는 부족하다

Airflow 공식 health 문서는 webserver의 /api/v2/monitor/health endpoint가 metadatabase, scheduler, triggerer, dag_processor 상태와 최근 heartbeat를 반환한다고 설명한다. 단, HTTP status code 200만 보고 healthy라고 판단하면 안 된다. endpoint 호출이 성공했다는 뜻일 뿐, JSON 내부 component status를 확인해야 한다.

Scheduler는 별도 health check server도 켤 수 있다.

[scheduler]
enable_health_check = True
scheduler_health_check_server_port = 8974

그리고 CLI로도 확인할 수 있다.

airflow jobs check --job-type SchedulerJob --local

HA scheduler라면 여러 scheduler 중 하나가 살아 있으면 전체 scheduler status가 healthy로 보일 수 있다. 이것은 “전체 Airflow가 완전히 정상”이라는 뜻이 아니다. 한 scheduler만 살아 있고 DAG parsing backlog가 커지는 상황도 가능하다.

운영 대시보드에서 scheduler health는 다음을 함께 봐야 한다.

신호	왜 필요한가
`scheduler_heartbeat` 또는 health endpoint의 latest heartbeat	scheduler process 생존 확인
`dag_processor_heartbeat` / DAG processor status	DAG parsing 계층 확인
`dag_processing.total_parse_time`	전체 DAG 파일 parse 시간이 너무 길어졌는지 확인
`dag_processing.import_errors`	DAG import 실패가 scheduling을 방해하는지 확인
`dag_processing.processor_timeouts`	복잡한 DAG 파일이 processor timeout을 내는지 확인
metadata DB latency/connection	scheduler가 상태 전이를 기록하지 못하는지 확인
executor queued/running/open slots	scheduler 이후 실행 계층이 막혔는지 확인

Scheduler 장애 알림은 “heartbeat 없음” 하나만 두면 늦다. heartbeat는 살아 있는데 parsing 시간이 길어져 새 DAG 반영이 늦거나, metadata DB slow query 때문에 scheduling throughput이 낮아지는 경우가 있다. 그래서 heartbeat, parse time, queued/scheduled backlog, DB slow query를 한 화면에서 같이 봐야 한다.

6. Grafana 패널을 운영 질문 중심으로 배치한다

좋은 Airflow Grafana dashboard는 metric 종류별 나열이 아니라 질문 순서대로 배치된다. 예시는 다음과 같다.

섹션	핵심 패널	즉시 답해야 하는 질문
Deadline/SLO	deadline miss count, miss minutes, critical DAG status	사용자에게 약속한 시간이 깨졌는가?
Scheduling	DAG run schedule delay, scheduled/queued task count	scheduler가 제때 실행 대상을 만들고 있는가?
Executor/Pool	queued/running/open slots, pool starving tasks	capacity 또는 pool 때문에 밀리는가?
Runtime	task duration p50/p95, slowest tasks, retry count	실행 자체가 느린가?
Control plane	scheduler/triggerer/dag processor heartbeat, parse time, import errors	Airflow control plane이 건강한가?
Metadata DB	DB CPU/IO, connection, slow query, table growth	metadata DB가 병목인가?

알림도 같은 구조로 나눈다.

Page 즉시 호출: critical DAG deadline miss, scheduler unhealthy, metadata DB unavailable, executor queue 폭증.
업무시간 확인: 특정 DAG p95 duration 증가, import error 증가, pool starving task 누적.
티켓/개선 과제: parse time 장기 증가, DAG 수 증가에 따른 scheduler capacity 재산정, noisy retry 패턴.

여기서 중요한 것은 threshold를 절대값으로만 정하지 않는 것이다. DAG마다 주기와 중요도가 다르다. 5분 지연이 심각한 실시간성 DAG도 있고, 30분 지연이 허용되는 야간 batch도 있다. 따라서 critical DAG는 별도 SLO와 deadline을 갖고, 비중요 backfill은 별도 pool과 낮은 alert severity로 분리한다.

7. 장애 상황별 빠른 판별표

운영 중에는 긴 문서보다 첫 5분 판별표가 더 유용하다.

증상	먼저 볼 패널	가능성 높은 원인	첫 대응
모든 DAG가 늦게 시작	scheduler heartbeat, parse time, metadata DB latency	scheduler loop 지연, DB 병목, DAG parsing 폭증	scheduler/DB health 확인, 최근 배포 DAG rollback 검토
`queued` task가 급증	executor queued/running/open slots, pool starving	worker 부족, pool 제한, executor/broker 문제	worker scale-out, pool 임시 조정, broker/queue 확인
특정 DAG만 deadline miss	DAG Gantt, task duration p95, retry log	특정 task code/downstream 지연	owner 호출, downstream 상태 확인, rerun 기준 판단
scheduler healthy인데 실행이 안 됨	pool, executor open slots, worker logs	pool 고갈, worker registration 문제	pool/pod/worker 상태 확인
UI도 느리고 scheduler도 느림	metadata DB CPU/IO/connection/slow query	metadata DB 병목 또는 connection 고갈	DB connection budget, slow query, vacuum/analyze 상태 확인
DAG import error 증가	dag_processing.import_errors, scheduler logs	새 DAG 배포 오류	최근 배포 rollback, CI validation 강화

이 표는 완벽한 정답표가 아니라 “어느 팀과 어느 화면을 먼저 볼지”를 정하는 장치다. Airflow 장애는 scheduler, executor, metadata DB, 외부 시스템이 엮이기 쉬우므로 초기에 관측 축을 잘못 잡으면 복구가 길어진다.

8. 운영 체크리스트

Airflow 운영 대시보드를 만들 때 다음을 기준선으로 삼을 수 있다.

critical DAG 정의

- 모든 DAG에 같은 alert를 걸지 않는다. - 업무 마감이 있는 DAG에는 deadline 또는 SLO를 명시한다.

queue와 runtime 분리

- queue time, run time, end-to-end latency를 따로 본다.

scheduler health 다층화

- heartbeat, DAG processing, import error, metadata DB latency를 같이 본다.

pool을 관측 단위로 사용

- 외부 시스템 보호용 pool은 starving_tasks와 함께 관리한다.

metric cardinality 관리

- 모든 DAG/task label을 무제한 수집하면 비용과 cardinality 문제가 생길 수 있다. - Airflow의 metrics allow/block list를 사용해 필요한 범위를 조정한다.

UI와 metrics를 연결

- Grafana에서 이상을 보고 Airflow Grid/Gantt/task log로 바로 들어갈 수 있게 한다.

알림 피로 줄이기

- deadline miss, scheduler unhealthy, queue 폭증처럼 action이 명확한 알림부터 만든다.

대시보드 리뷰 주기화

- DAG 수, worker 수, executor 방식, Airflow version이 바뀌면 threshold도 바뀐다.

마지막으로, Airflow 대시보드는 Airflow만 보는 도구가 아니다. 실제 데이터 플랫폼에서는 warehouse queue, Kafka lag, Spark/Flink job, Kubernetes node, metadata DB, object storage 상태와 연결되어야 한다. Airflow는 “무엇을 언제 실행할지”를 조정하는 control plane이기 때문에, 대시보드도 control plane과 workload plane을 이어 주어야 한다.

References

Apache Airflow Documentation, “Metrics Configuration,” Airflow 3.2.2. <https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/logging-monitoring/metrics.html>
Apache Airflow Documentation, “Checking Airflow Health Status,” Airflow 3.2.2. <https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/logging-monitoring/check-health.html>
Apache Airflow Documentation, “Deadline Alerts,” Airflow 3.2.2. <https://airflow.apache.org/docs/apache-airflow/stable/howto/deadline-alerts.html>
Apache Airflow Helm Chart Documentation, “Production Guide.” <https://airflow.apache.org/docs/helm-chart/stable/production-guide.html>
Datadog, “How to monitor Airflow metrics, logs, and lineage,” 2025-05-13. <https://www.datadoghq.com/blog/how-to-monitor-airflow/>
Astronomer Docs, “Scaling Airflow to optimize performance.” <https://www.astronomer.io/docs/learn/airflow-scaling-workers>