Airflow 아키텍쳐 2.0 -> 3.0 변경사항 알아보기

 

 

Airflow 아키텍쳐에 대한 개요와 

2.0 -> 3.0으로 버전이 변경될 때 변경사항을 정리했습니다.

 

 

* 인프런 강의 "Airflow 마스터 클래스" 내용을 참고하였습니다.

---

 

 

 

아키텍쳐 

 

Airflow 버전별 구조

 

좌측 2.0 버전 / 우측 3.0 버전

 

3.0 아키텍쳐의 컴포넌트

• scheduler
• dag_processor
• trigger
• worker
• 웹서버 (api)
• meta db

2.0과 비교했을 때 가운데 API Server Layer가 추가된 것이 가장 큰 변화

• 모든 컴포넌트가 Meta DB에 붙게되면 
  • 보안이슈: 개별 컴포넌트가 DB의 모든 정보에 접근할 수 있게되므로 보안 이슈에 상대적으로 취약한 구조
  • 많은 세션으로 인한 DB 과부하: I/O가 증가하면서 성능 저하 가능성
• 따라서 Meta DB에 접근해야만 하는 스케쥴러를 제외하고는 API Server 레이어를 통해 인터페이스 할 수 있도록 구조 분리
  • 추후 GPU를 사용하는 On-Prem 노드까지 오케스트레이션할 수 있는 것을 염두에 둔 구조 --> DB와의 결합도를 느슨한 구조로 만들었기 때문에, 워커노드가 다른 방식으로 추가되더라도 API Server와의 통신만 가능하면 추가가 가능해짐
  • 실제로 오퍼레이터중 On-Prem 노드에 대한 지원도 계속해서 추가 되는 중
• 스케쥴러 컴포넌트의 경우 2.0에서는 Dag Processor 역할까지 하다가 3.0에서 이를 별도의 컴포넌트로 분리
  • SRP (Single Responsibility Principle) 원칙에 부합

 

컴포넌트별 역할

 

아키텍처 구성

• Scheduler: DAG 파싱 및 실행 시점 관리
• Worker: Task 실행
• Webserver: UI 제공
• MetaDB: 실행 및 설정 정보 저장
• Airflow 3.0부터 Webserver → API Server 구조로 변경 (보안·확장성 개선)

 

메타 DB

• DAG, Task, Connection 등 메타정보 저장
• 공식 지원 DB: PostgreSQL, MySQL
• MSSQL은 테스트 중, MariaDB는 비공식 (2025.12기준)
• 주요 테이블
  • dag_run: DAG 실행 이력
  • job: Job별 실행 이력log: Airflow 내 로그 기록
  • task_instance: Task별 실행 이력
  • task_reschedule: 재시도 이력 (poke/reschedule 방식 관련)

 

XCom (Cross Communication)

• Task 간 데이터 공유 기능
• 메타DB의 xcom 테이블에 JSON 직렬화 형태로 저장
• xcom_push(), xcom_pull() 사용
• 소량 데이터만 저장 (대용량은 S3, GCS 등 외부 스토리지 사용)

kwargs

• 함수에 전달되는 Airflow 실행 컨텍스트(dict)
• ti, execution_date, dag_run 등 포함
• ti.xcom_pull() 형태로 접근 가능

Template / Macro

• Jinja 템플릿: 런타임 시 변수값을 문자열에 치환
• 예시 변수: {{ ds }}, {{ data_interval_start }}, {{ data_interval_end }}
• templates_dict로 Task 간 매크로 전달 가능

https://airflow.apache.org/docs/apache-airflow/stable/templates-ref.html

Templates reference — Airflow 3.1.7 Documentation