본 글은 공식문서 Architecture Overview를 보고 작성하였습니다.

 

 

Introduction

Airflow는 workflows를 build하고 실행할 수 있게 해주는 platform이라고 했다.

Airflow의 architecture에는 어떤 Component로 구성되어 있고, 각 기능이 무엇인지, 어떤 역할을 하는지 알아보자!

 

 

Workflows

모든 workflows는 Dag(a Directed Acyclic Graph)로 표현되고 Task라는 개별 work들이 포함되어 있다. 이때 각 task는 dependencies과 data 흐름을 고려해서 배치된다.

  • Dag: Task들 간의 dependencies를 명시하며, 이로부터 Task의 실행 순서를 정의한다.
  • Task : 무엇을 해야할지(data를 가져오기, 분석하기, 다른 system을 trigger하기 등)를 설명한다.

Airflow 자체는 무엇을 실행하고 있는지에 대해서는 관여하지 않는다.

provider가 제공하는 high-level 지원을 사용하든, shell 명령이나 Python Operator를 통해 직접 실행하든 상관없이,

무엇이든 orchestrate하고 실행한다.

 

 

Airflow components

Required Components

Airflow에는 필수로 다음과 같은 components가 필요하다

  • Scheduler
    • 역할: 예약된 workfows를 trigger하거나 실행할 tasks를 executor에게 전달. Control Tower임.
    • executor
      1. 분리된 component가 아니라 scheduler process 내에서 실행된다.
      2. scheduler의 configuration peroperty. 즉 execution mode 설정이라고 생각하면 된다
      3. task를 어떻게 실행할지를 결정하는 역할
      4. 기본으로 제공되는 executors가 있고, 내가 직접 custom해도 된다 .
  • Dag Processor
    • 역할: Dag files를 parsing(해석)하여 metadata database에 저장할 수 있는 형태로 변환하여(serialize) 저장
  • webserver
    • 역할: UI를 통해서 Dag와 Task의 상태를 확인(inspect), 실행(trigger), debug할 수 있게 보여주는 역할
  • Dag files의 folder
    • 역할: user가 작성한 file들을 저장하는 곳
    • scheduler는 이 folder를 수시로 읽어서, 어떤 task를 언제 실행할지 판단한다.
  • metadata database
    • 역할: tasks의 상태(실패/성공), Dags, variables를 저장하는 곳
    • PostgreSQL 혹은 MySQL을 주로 사용

 

Optional components

Airflow에서 순서대로 Scalability, Performance, Extensibility를 보다 더 향상시킬 수 있는 component들임.

  • worker
    • 역할: scheduler(정확히는 Executor임)로부터 할당받은 tasks를 실제로 실행시킨다.
    • 기본 설치시, worker가 분리된 component가 아니라 scheduler의 일부일 수도 있다.
      즉 LocalExecutor를 사용할 경우 구현 상 scheduler process에 포함될 수 있음.
    • CeleryExecutor에 의한 worker → long running process(24시간 켜져있는 worker)로 실행됨
      KubernetesExecutor에 의한 worker → kubernetess의 POD로 실행됨
    • Throughput이 많아지면 별도의 worker 서버를 분리함으로써 Scalability를 확보
  • triggerer
    • 역할: deferred task(지연된 작업)들을 실행하고 관리한다.
    • asyncio(비동기 방식) event loop를 사용함.
    • EX) 외부 API 응답이 올 떄까지 1시간 지연해야 하는 task
      → worker의 자원을 계속 점유하지 않고 조건이 충족되면 해당 task를 worker에게 넘긴다
    • 기본 설치시, 필요하지 않다. (deferred tasks를 사용하지 않아서..)
    • 수천 개의 task를 효율적으로 실행해야 하는 경우 Performance 향상
  • plugins의 folder
    • 역할: Airflow에 없는 새로운 기능을 확장하는 곳, Extensibility를 향상 (package 설치와 비슷)
    • scheduler, Dag Processor, tirggerer, webserver가 읽어서 원래 있던 기능처럼 사용 가능

 

Deploying Airflow components

그렇다면 Airlflow는 왜 역할과 책임이 분리된 많은 component들로 구성되어 있을까? 그리고 컴포넌트를 분리했을 때 그 이점은 무엇일까? 

 

1. 다양한 deployment mechanism으로 배포 가능

  • 모든 component들은 다양한 배포 방식으로 실행할 수 있는 Python applications이다. 
  • 각 component의 Python 환경에 필요한 package를 추가로 설치할 수 있다.
  • Custom Operator나 Sensor를 설치하거나, Custom plugin을 통해 Airlfow 기능을 확장할 수 있다.

 

2. Distributed Environment를 고려하여 설계됨

  • Airflow는 single machine이나 간단한 installation(scheduler랑 webserver만 배포된 경우)로도 실행 가능하지만, scalable하고 secure하게 분산 환경에 실행 가능하도록 설계되었다.
  • 즉, 다양한 components가 서로 다른 machines에서 실행될 수 있고, 서로 다른 Security Perimeter(방화벽 같은 보안 경계를 의미)를 가질 수 있다.
  • 앞선 Component들을 multiple instance로 여러 개 실행하여 확장할 수 있다. 

 

3. Security 강화 

  • Component를 각각 격리시키고 각각 다른 taskf를 수행하도록 함으로써 보안을 강화할 수 있다. 
  • EX) Dag Processor와 scheduler를 분리 → shceduler가 Dag file를 직접 접근할 수 없음, Dag 작성자가 작성한 코드를 직접 실행할 수 없음

 

4. Role- based 관리

  • 한 사람이 혼자서 Airlfow를 관리하고 실행할 수는 있다.
  • 규모가 큰 복잡한 Airflow Deployment에서는 system의 각 부분과 상호작용 할 수 있는 다양한 user의 역할을 포함할 수 있다. 
  • EX) Role
    • Deployment Manager: Airlfow를 설치하고 구성하고 전체적인 배포를 관리
    • DAG author: DAG를 작성하고 Ailfow에 제출
    • Operations User : DAG와 task를 실행하고 실행 상태를 모니터링

 

Architecture Diagrams

자 이제 Airflow로 배포하는 여러 방법들의 Diagram을 볼 것이다!

아주 단순한 하나의 machine과 한 사람이 배포하는 방식에서 component와 user 역할이 분리되고 Security Perimeters가 격리된 복잡한 형태까지.. 단계별 Deployment 방식을 알아보자! 

 

그 전에 digaram의 선의 의미는 다음과 같다.

갈색, 파란색, 검은색 dash, 검은색, 빨간색 dash

사실 텍스트로만 적어도 되는데 이렇게 정리해보고 싶었다. 우하하

 

그냥 빨간 선은 정보가 저장되는 흐름, 갈색은 Dag file의 흐름, 검정은 task의 흐름, 파랑은 package나 plugin의 흐름

이라고 생각하면 쉽다!

 

Basic Airflow deployment

가장 단순한 Airflow deployment로, 보통 single machine에서 운영 및 관리된다.

 

 

1. Component

  • Scheduler
    • LocalExecutor 사용: Scheduler와 Worker가 동일한 Python process 내에서 실행된다.
    • 또한 scheduler가 parsing(Dag Processor), Executing(Executor)의 역할까지 모두 담당한다는 것을 알 수 있다. 
  • Dag files
    • scheduler가 local filesystem에서 직접 읽는다.
  • webserver
    • scheduler와 같은 machine에서 실행된다. 

2. etc 

  • triggerer component가 없기 때문에 Task deferral은 불가능하다
  • 이런 Deployment는 일반적으로 User 역할을 구분하지 않는다.
  • deployemnt, configuration, operation, authoring, matinencane가 모두 한 사람이 처리한다.
  • component 간에 security perimeters가 없다.

Distributed Airflow architecture

이 구조는 Airflow components들이 mutilple machine에 분산되어 있고 다양한 user의 역할(1. Deployment Manager 2. Dag author 3.Operations User)이 도입된 형태다. 

 

distributed deployment에서는 각 component의 security가 중요하다. 이를 위해 user마다 역할을 명확히 제한하고 각 Component 역시 접근할 수 있는 권한이 다르다. 

 

1. Component

Basic에서 달라진 점 위주로 본다면

  • scheduler
    • Scheduler와 Worker가 다른 Component로 분리되어 있다. 
  • webserver 
    • DAG file에 직접 접근할 수 없다. 
    • UI의 'Code' tab의 모든 code들은 file이 아니라 metadata base에서 읽어온 것이다. 
    • 2. DAG author가 제출한 code를 실행할 수 없다. 
    • 대신 1. Deployment Manager가 직접 설치한 pacakge와 plugin code만 실행할 수 있음
  • triggerer
    • deferral task를 감시하고 관리하는데 활용된다. 

 

2. User Role

각 User는 자신의 역할에 한정된 권한만 수행할 수 있도록 분리되어있다. EX) Opseration User는 Dag author의 작업을 수행할 수 없음

  • Operations User
    • UI에 접속하여 Dag와 Task를 trigger하고 monitoring 하는 역할 
  • DAG Author
    • Dag를 직접 수정하거나 작성하는 역할 
  • Deployment  Manager
    • 필요한 plugin이나 pacakge를 설치하고 관리하는 역할

 

3. DAG files Synchronization 

현재 구조는 여러 machine에 Component가 분산되어 있기 때문에 Dag를 사용하는 모든 components(scheduler, triggerer, workers)간에는 파일 동기화가 반드시 필요하다!

 

다음과 같은 상황을 가정해보자. 

  • DAG Author가 A라는 Dag file을 작성했고 이 DAG는 dog dataset을 사용하도록 정의
  • 해당 DAG 파일은 scheduler, triggerer, worker 각 컴포넌트에 전달되어 실행

이후 DAG Author가 Dag file을 dog dataset에서 cat dataset으로 업데이트했다. 만약 동기화가 이루어지지 않는다면?

 

각 Component는 DAG 파일이 변경되었는지를 스스로 인지할 수 없기 때문에, scheduler는 cat version으로 task를 수행시키는데, worker는 여전히 dog version을 사용하는 등 불일치가 발생할 수 있다. 

 

이를 위해서는 다양한 동기화 mechanism이 사용되는데, 일반적으로 Helm Chart(Kubernetes 환경에서 Airflow를 배포하는 대표적인 방법 중 하나) documentation의 Manage Dag files에 확인할 수 있다. 

 

Separate Dag processing architecture

security와 isolation이 매우 중요한 복잡한 installation에서는 독립형 Dag Processor Component를 도입한다. 보통 Parsing된 tasks 간의 격리가 필요할 때 적합하다. 완벽한 multi-tenant 기능(완전히 독립적으로 사용)을 지원하는 것은 아니다! 

1. Component

달라진 점을 살펴보자!

  • Dag Processor
    • Dag file을 parsing 하는 역할
  • scheduler
    • DAG file에 직접 접근할 수 없다. 오직 Metadata database로만 Dag를 읽을 수 있다. 
    • DAG Author가 제공한 code는 절대로 scheduler process 내에서 실행되지 않는다.
    • 즉 순수하게 scheduling만 담당한다. 

 

2. DAG file synchronization

Dag file이 변경될 때, scheduler와 worker가 최신 상태를 반영하기 전까지 서로 다른 Dag version을 보는 불일치 상황이 발생할 수 있다고 위에서 언급했었다! 이 구조도 같은 문제가 발생할 수 있는데.. 

 

이때 Dag Processor가 분리된 아키텍쳐에서는 scheduler가 Dag file를 직접 읽을 수 없기에 아래와 같은 방식으로 해결할 수 있다. 

  • DAG deployment(업데이트) 중에는 DAG를 비활성화(deactivated)
    deployment가 완전히 종료된 후 다시 활성화 
  • 필요한 경우 DAG folder를 scan하고 동기화하는 주기(cadence)를 설정에서 변경

 

 

Workloads

하나의 Dag는 여러 개의 tasks를 순차적으로 실행한다. 

일반적으로 다음과 같이 3가지 유형의 Task를 볼 수 있다.  

  • Operators
    미리 정의된 task. 여러 Operator를 이어 붙여 Dag의 대부분을 빠르게 구성할 수 있다. 
  • Sensors
    Operator의 특수한 한 subclass로, 외부 event가 발생할 때까지 대기하는 역할 만을 수행한다. 
  • TaskFLow
    Python 함수 위에 @task 라는 Decorator를 붙여서 packaging한 하나의 Custom Task이다. 

내부적으로 모두 Airflows의 BaseOperator의 subclass다.

 

🤔 Operator vs Task
Task와 Operator의 개념은 서로 바꿔서 사용될 수 있지만 분리된 개념이라고 이해하는 것이 좋다. 
- Operator & Sensor = 일종의 template
- Task = Dag 파일 안에서 호출하는 순간, 실제 실행 단위인 Task가 생성

쉽게 말해, OOP에서 Object와 Instance의 관계와 비슷하게 이해하면 된다.  

 

 

Control Flow

DAG는 실제로 어떻게 돌아갈까?

 

1. Dag

먼저 Dag는 사실 여러 번 실행되도록 설계되었으며, 여러 번의 실행이 병렬(Parallel)로 진행될 수 있다.  

모든 Dag 실행에는 data interval 이는 parameter가 포함된다. 이는 해당 실행이 어떤 기간의 데이터를 처리하는 가를 정의한다. 

 

 

2. Task

그 다음 Dag 안의 Task들은 선언된 dependencies를 가지고 있다! 이는 task들이 실행되는 순서를 정하는 정하는 방법으로 graph의 edges를 그리는 것이라 생각하면 쉽ㄴ다. 다음과 같이 dependencies를 정의한다. 

 

  • >>, << operators
first_task >> [second_task, third_task]
fourth_task << third_task

 

  • Method 사용
first_task.set_downstream([second_task, third_task])
fourth_task.set_upstream(third_task)

 

위의 두 코드 모두 

 

  • first_task가 끝나면 seond와 third를 동시에 실행
  • third_task가 먼저 실행된 후에 fourth_task를 실행

하라는 의미이다. 

 

 

기본적으로 task는 upstream(앞의 task)이 성공할 때까지 기다리지만 Branching, LatestOnly, Trigger Rules와 같은 기능을 통해 규칙을 바꿀 수 있다. 

 

3. Data Passing

 

Airflow는 Worker에 사용가능한 space가 생길 때마다 Task를 실행시킨다다. 이때 하나의 DAg에 포함된 모든 Task들이 같은 Worker나 같은 Machine에서 실행된다는 보장이 없다. 

따라서 Task 간에 data를 주고받는 3가지 방법을 소개한다. 

 

  • XComs (Cross-communications)
    • 작은 bit의 metadata를 push하고 pull 방식으로 주고받을 수 있는 system
  • storage service
    • large files를 uploading하고 downloading
    • 직접 운영하는 storage나 pulic cloud storage
  • TaskFlow API
    • 암묵적인 XCom를 통해 task 간에 data가 자동으로 전달 

Dag를 확장하다보면 구조가 점점 복잡해질 수 있기 때문에 Airflow는 유지 가능하도록 여러 mechanism을 제공한다. 

  • TaskGroups : UI 상에서 Task들을 시각적으로 그룹화 
  • Connections & Hooks 기능: datastore와 같은 중앙 리소스에 대한 접근을 미리 설정
  • Pools: 동시 실행(concurrency)을 제한

 

User interface

UI에서는 Dag와 그 Task들이 무엇을 하고 있는지, Dags의 실행을 수동으로 trigger, logs 조회, Dag 관련 문제를 제한된 범위 내에서 debugging을 하는 등의 기능을 제공한다. 

 

 

끝!!! 

'DevOps > Airflow' 카테고리의 다른 글

[Airflow] Docker Compose로 Installation  (0) 2026.01.14
[Airflow] Overview  (0) 2026.01.06

티스토리툴바