본문 바로가기
프로그래밍/DevOps & MLops 관련정보

[Airflow] Airflow 기본 구성요소

by 물박사의 저장공간 2025. 8. 30.

ChatGPT의 도움을 받아서 Airflow의 기본 컴포넌트를 한 번 정리하고 가겠습니다. 

1. Web Server

역할: 사용자가 DAG(Workflow)와 Task 상태를 확인하거나 실행을 제어할 수 있는 UI 제공

Flask 기반의 웹 애플리케이션

DAG 실행 상태 모니터링, Task 로그 확인, DAG trigger/중단 등 관리 기능 수행

 

2. Scheduler

"무슨 일을 언제 할지 결정하는 두뇌"

역할: DAG(Directed Acyclic Graph) 정의를 읽고 언제 어떤 Task가 실행되어야 하는지 결정

 

DAG가 할 일의 순서를 그린 설계도라면, Operator는 그 설계도에서 각 칸에 들어갈 ‘실제 할 일의 내용

 

1) DAG

https://airflow.apache.org/docs/apache-airflow/2.5.2/core-concepts/dags.html

 

DAGs — Airflow Documentation

 

airflow.apache.org

 

2) Operator

특정 작업을 어떻게 수행할지 정의합니다.

하나의 Operator 인스턴스가 DAG 안에서 Task가 됩니다. 
(즉, "Operator" = Task 템플릿, "Task" = DAG에 넣은 Operator의 인스턴스)

- Dependency를 확실히 구분하고 어떤 Task를 다시 시작해야하는지 식별하기 위함

BashOperator Bash 쉘 명령어 실행
PythonOperator 파이썬 함수 실행
EmailOperator 이메일 전송
HttpOperator HTTP 요청 보내기
DummyOperator 아무 일도 안 하는 placeholder
PostgresOperator PostgreSQL 쿼리 실행
DockerOperator Docker 컨테이너 실행
from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime

with DAG(
    dag_id='example_dag',
    start_date=datetime(2025, 1, 1),
    schedule_interval='@daily',
    catchup=False
) as dag:

    task_hello = BashOperator(
        task_id='print_hello',
        bash_command='echo "Hello Airflow!"'
    )

 

3. Metadata Database

역할: Airflow의 상태 저장소 (single source of truth)

  • DAG 정의, DAG 실행 기록(DAG Run, Task Instance)
  • Task 상태(success, failed, queued 등)
  • 사용자/권한 정보

일반적으로 PostgreSQL 또는 MySQL 같은 RDBMS 사용

Scheduler, Web Server, Executor 모두 DB를 통해 정보를 주고받음

 

4. Executor  

"작업 실행을 지시하는 관리자"

역할: 실제로 Task를 실행할 방식을 결정하고 지휘하는 컴포넌트

1) SequentialExecutor: 단일 프로세스 실행 (개발용)

2) LocalExecutor: 병렬 실행, 로컬 머신에서 multi-process 기반

3) CeleryExecutor: 분산 실행, 여러 Worker 노드에 Task 분산 처리

4) KubernetesExecutor: K8s Pod 단위로 Task 실행

 

 

5. Worker

Executor의 지시를 받아 실제로 Task를 수행하는 프로세스/노드

주로 CeleryExecutor, KubernetesExecutor 환경에서 등장

Task 실행 → 로그 수집 → 결과 상태를 Metadata DB에 기록

 

6. Triggerer (Airflow 2.2 이상에서 도입) 

"특정 이벤트를 기다렸다가 조건이 충족되면 Task를 깨우는 감시자"

비동기 이벤트 기반 Task 실행 지원

전통적인 Worker : 동기 방식 → I/O 대기 시간이 긴 Task (예: API polling, sensor) 에서 비효율 발생

Triggerer : asyncio 기반 이벤트 루프 사용 → 대기 시간이 긴 작업도 효율적으로 관리 가능