[Airflow] Airflow 개념과 전체적인 구조 정리

 

이번 포스트에는 Airflow의 구조에 대해서 간단하게 정리 해보겠습니다.

---

1. LocalExecutor를 사용하는 Single Node Architecture

Single Node Architecutre에는 크게 4가지 모듈이 있습니다.

• WebServer:
  • Airflow의 웹서버는 사용자가 DAG의 상태를 확인하거나 로그를 조회할 수 있도록 웹 인터페이스를 제공
  • 기본적으로 Flask로 구축되어 있음
• Scheduler: 
  • Airflow 스케줄러는 정의된 DAG(Directed Acyclic Graph)의 Task를 스케줄에 따라 실행
  • 여러 DAG에서 병렬 작업을 관리하며, Executor와 연동해 작업을 처리
• Metastore: DAG, USER, 권한, 실행 이력과 같은 테이블을 저장하고 있으며, PostgreSQL, MySQL과 같은 DB와 연결해서 사용하며, 기본적으로는 SQLite를 사용(병렬처리에 부적합)
• Executor(Queue): 여기에서는 Redis, RabbitMQ와 같은 외부 Queue를 사용하지 않고, 기본적으로는 Python의 멀티프로세싱을 기반으로 구현( Airflow가 실행되는 로컬 머신에서 Python의 multiprocessing 라이브러리를 사용하여 병렬 작업을 처리)
• StatsD:  애플리케이션에서 발생하는 메트릭 데이터를 수집하고, 이를 모니터링 시스템(예: Graphite, Prometheus, Datadog 등)으로 전달하는 데 사용되는 프로토콜 및 데몬
  • Airflow는 DAG 실행, Task 성공/실패, 스케줄러 상태 등과 같은 다양한 이벤트를 메트릭으로 노출합니다.
  • StatsD를 활성화하면 Airflow는 이러한 메트릭을 StatsD 서버로 전송하여 모니터링 및 분석이 가능해집니다.
  Airflow에서 StatsD로 전송되는 주요 메트릭:
  1. Task 관련 메트릭
     • Task 성공/실패/재시도 횟수
     • Task 실행 시간
  2. DAG 관련 메트릭
     • DAG 실행 상태
     • DAG 스케줄링 지연 시간
  3. Scheduler 관련 메트릭
     • Scheduler 루프 실행 시간
     • Scheduled Task의 수
  4. Worker 관련 메트릭
     • Worker 실행 상태
     • Queue에서 처리된 작업 수

동작 순서

1. 웹서버와 스케줄러는 이런 정보를 읽어오고 Executor로 보내 실행
2. 이렇게 실행된 DAG의 task instance는 메타스토어로 다시 보내져서 상태를 업데이트
3. 업데이트된 상태를 웹서버와 스케줄러가 읽어와서 task가 완료됐는지 확인
4. executor안에는 Queue라는 것이 존재해서 task의 순서를 정하여 진행

---

2. (Celery)Multi Node Architecture

Airflow Multi-Node Architecture도 크게 다를 바는 없는데, 여기서 다수의 worker를 다룰 Celery Broker와 Redis, RabbitMQ같은 Queue가 추가적으로 필요합니다.(Flower와 같은 Celery monitoring 도구는 옵션)

• WebServer:
  • Airflow의 웹서버는 사용자가 DAG의 상태를 확인하거나 로그를 조회할 수 있도록 웹 인터페이스를 제공
  • 기본적으로 Flask로 구축되어 있음
• Scheduler: 
  • Airflow 스케줄러는 정의된 DAG(Directed Acyclic Graph)의 Task를 스케줄에 따라 실행
  • 여러 DAG에서 병렬 작업을 관리하며, Executor와 연동해 작업을 처리
• Metastore: DAG, USER, 권한, 실행 이력과 같은 테이블을 저장하고 있으며, PostgreSQL, MySQL과 같은 DB와 연결해서 사용하며, MultiNode Cluster에는 SQLite를 사용하지 못함(병렬처리를 해야 하기 때문에)
• Executor(Queue): 여기에서는 Redis, RabbitMQ와 같은 외부 Queue를 사용하며, Celery Executor를 사용
• StatsD:  애플리케이션에서 발생하는 메트릭 데이터를 수집하고, 이를 모니터링 시스템(예: Graphite, Prometheus, Datadog 등)으로 전달하는 데 사용되는 프로토콜 및 데몬

Celery vs Redis

동작 순서

1. Queue가 Executor 바깥에 존재(Redis, RabbitMQ)
2. Airflow UI 와 스케줄러가 메타스토어의 실행 정보를 읽어옴
3. 읽어온 정보를 Celery Broker에 순서대로 담음
4. 순서대로 담긴 task를 worker들이 실행
5. 완료된 후에는 Metastore, celery executor에 보고 되고 스케줄러가 완료된 것을 확인