에어플로우(Airflow)는 워크플로우를 구축하고 실행하는 플랫폼으로, 방향성 비순환 그래프(DAG)를 통해 개별 작업(Task)들의 실행 순서와 의존성을 정의합니다. 최소한의 에어플로우 아키텍처는 워크플로우를 실행하는 스케줄러(scheduler), UI를 제공하는 웹서버(webserver), DAG 파일이 담긴 폴더, 그리고 상태를 저장하는 메타데이터 데이터베이스(metadata database)로 구성됩니다. 메타데이터 데이터베이스는 워크플로우와 작업의 상태, 실행 이력, 메타데이터 등을 저장하는 핵심 구성 요소로, PostgreSQL, MySQL, SQLite 등 다양한 관계형 데이터베이스를 지원하며, 프로덕션 환경에서는 고가용성과 성능을 위해 PostgreSQL이나 MySQL이 주로 사용된다. 더 나은 확장성과 성능을 위해, 실제 작업을 수행하는 별도의 워커(worker)나 지연된 작업을 처리하는 트리거(triggerer) 같은 선택적 컴포넌트를 추가하여 분산 환경으로 확장할 수 있습니다. 이러한 유연한 구조 덕분에 에어플로우는 단일 머신에서 간단하게 운영하거나, 보안 및 성능을 위해 각 컴포넌트를 분리한 복잡한 분산 아키텍처로 배포하는 것이 모두 가능하다.
1. Airflow 구성 요소 설명
Apache Airflow의 아키텍처는 여러 구성 요소로 이루어져 있으며, 각 구성 요소는 최소 설치에 필수적인 것과 확장성, 성능, 확장 가능성을 향상시키기 위한 선택적 구성 요소로 나뉩니다.
필수 구성 요소
최소한의 Airflow 설치에는 다음과 같은 핵심 구성 요소들이 반드시 필요하다. 스케줄러(Scheduler)는 예약된 워크플로우를 트리거하고 실행할 작업들을 실행기(Executor)에 제출하는 역할을 담당한다. 실행기는 별도 구성 요소가 아닌 스케줄러의 설정 속성으로, 스케줄러 프로세스 내에서 실행되며, 다양한 내장 실행기를 사용하거나 사용자 정의 실행기를 작성할 수도 있다. 웹서버(Webserver)는 DAG와 작업의 동작을 검사하고, 트리거하고, 디버깅할 수 있는 편리한 사용자 인터페이스를 제공합니다. DAG 파일 폴더는 스케줄러가 읽어서 어떤 작업을 언제 실행할지 결정하는 DAG 정의 파일들이 저장되는 곳이다. 메타데이터 데이터베이스는 모든 Airflow 구성 요소가 워크플로우와 작업의 상태를 저장하는 데 사용하는 핵심 저장소로, Airflow가 작동하기 위해 반드시 필요하다.
선택적 구성 요소
다음과 같은 선택적 구성 요소들은 Airflow의 확장성과 성능을 크게 향상시킬 수 있다. 워커(Worker)는 스케줄러로부터 받은 작업을 실제로 실행하는 구성 요소입니다. 기본 설치에서는 워커가 스케줄러의 일부일 수 있지만, CeleryExecutor에서는 장기 실행 프로세스로, KubernetesExecutor에서는 POD로 독립적으로 실행할 수 있습니다.트리거러(Triggerer)는 asyncio 이벤트 루프에서 지연된 작업들을 실행하는 구성 요소로, 지연 작업을 사용하지 않는 기본 설치에서는 필요하지 않습니다. DAG 프로세서(DAG Processor)는 DAG 파일들을 파싱하여 메타데이터 데이터베이스로 직렬화하는 역할을 합니다. 기본적으로는 스케줄러의 일부로 실행되지만, 확장성과 보안상의 이유로 별도 구성 요소로 분리하여 실행할 수 있으며, 이 경우 스케줄러가 DAG 파일에 직접 접근할 필요가 없어집니다. 플러그인 폴더는 Airflow의 기능을 확장하는 방법을 제공하며, 설치된 패키지와 유사한 역할을 합니다. 플러그인은 스케줄러, DAG 프로세서, 트리거러, 웹서버 등 모든 주요 구성 요소에서 읽혀져 Airflow의 기능을 확장하는 데 사용됩니다. 이러한 구조적 설계를 통해 Airflow는 단순한 단일 머신 설치부터 대규모 분산 환경까지 다양한 배포 시나리오에 유연하게 대응할 수 있으며, 각 구성 요소의 독립적 확장을 통해 성능과 보안을 최적화할 수 있습니다.
2. Deploying Airflow components
Apache Airflow의 모든 구성 요소는 Python 애플리케이션으로, 다양한 배포 메커니즘을 통해 배포할 수 있으며, 각각의 Python 환경에 커스텀 오퍼레이터나 센서, 플러그인 등을 위한 추가 패키지를 설치할 수 있다. Airflow는 단일 머신에서 스케줄러와 웹서버만으로 간단하게 실행할 수도 있지만, 확장성과 보안을 고려하여 설계되었기 때문에 각 구성 요소를 서로 다른 머신에서 독립적으로 실행하고 여러 인스턴스로 확장할 수 있는 분산 환경에서의 배포가 가능하다. 구성 요소의 분리는 보안성을 크게 향상시키는데, 예를 들어 DAG 프로세서를 스케줄러에서 분리하면 스케줄러가 DAG 파일에 직접 접근하지 않아도 되어 DAG 작성자가 제공한 코드를 실행할 위험을 제거할 수 있다. 복잡한 설정에서는 배포 관리자(설치 및 구성 담당), DAG 작성자(워크플로우 개발 담당), 운영 사용자(실행 및 모니터링 담당) 등 다양한 역할의 사용자들이 시스템의 서로 다른 부분과 상호작용하게 되어, 이는 안전한 Airflow 배포의 중요한 측면이 된다.
- Airflow 아키텍처 다이어그램
Airflow 아키텍처 다이어그램에서 사용되는 연결선들은 각각 다른 의미를 가진다:
- 갈색 실선: DAG 파일의 제출 및 동기화
- 파란색 실선: 설치된 패키지와 플러그인의 배포 및 접근
- 검은색 점선: 스케줄러가 실행기를 통해 워커를 제어하는 흐름
- 검은색 실선: 워크플로우 실행 관리를 위한 UI 접근
- 빨간색 점선: 모든 구성 요소의 메타데이터 데이터베이스 접근
1. 기본 Airflow 배포 (Basic Airflow Deployment)
배포 특징: 기본 Airflow 배포는 가장 단순한 형태로, 일반적으로 단일 머신에서 운영되고 관리된다. 이 배포 방식은 LocalExecutor를 사용하여 스케줄러와 워커가 동일한 Python 프로세스 내에서 실행되며, DAG 파일들은 스케줄러가 로컬 파일시스템에서 직접 읽어온다.
구성 요소 배치:
- 스케줄러와 웹서버가 같은 머신에서 실행
- 워커가 스케줄러와 동일한 프로세스에서 동작
- 트리거러 구성 요소가 없어 작업 지연(task deferral) 기능 사용 불가
- 모든 구성 요소가 단일 머신에 집중
사용자 역할: 이러한 설치에서는 사용자 역할이 분리되지 않으며, 배포, 구성, 운영, 작성, 유지보수가 모두 동일한 사람에 의해 수행됩니다. 구성 요소 간에 보안 경계가 없어 단순하지만 보안 측면에서는 제한적이다.
적용 시나리오: 개발 환경, 소규모 프로젝트, 또는 Airflow를 처음 시작하는 단계에서 적합하며, 복잡한 설정 없이 빠르게 시작할 수 있는 장점이 있다.
2. 분산 Airflow 아키텍처 (Distributed Airflow Architecture)
배포 특징: 분산 아키텍처에서는 Airflow의 구성 요소들이 여러 머신에 분산되어 배치되며, 다양한 사용자 역할이 도입됩니다. 이는 확장성과 보안성을 크게 향상시키는 배포 방식이다.
사용자 역할 분리:
- 배포 관리자(Deployment Manager): 시스템 설치, 구성, 패키지 및 플러그인 관리
- DAG 작성자(DAG Author): 워크플로우 개발 및 DAG 파일 작성
- 운영 사용자(Operations User): DAG 실행 트리거 및 모니터링, DAG 작성 권한 없음
보안 강화 요소: 웹서버는 DAG 파일에 직접 접근하지 않으며, UI의 Code 탭에서 보여지는 코드는 메타데이터 데이터베이스에서 읽어옵니다. 웹서버는 DAG 작성자가 제출한 코드를 실행할 수 없고, 오직 배포 관리자가 설치한 패키지나 플러그인의 코드만 실행할 수 있습니다.
DAG 파일 동기화: DAG 파일들은 스케줄러, 트리거러, 워커 등 이를 사용하는 모든 구성 요소 간에 동기화되어야 합니다. 이는 Git, NFS, S3 등 다양한 메커니즘을 통해 구현할 수 있으며, Kubernetes 환경에서는 Helm Chart를 통한 배포가 일반적이다.
확장성 및 성능: 각 구성 요소를 독립적으로 확장할 수 있어 워크로드에 따라 스케줄러, 워커, 웹서버의 인스턴스 수를 조절할 수 있다.
3. 별도 DAG 처리 아키텍처 (Separate DAG Processing Architecture)
고급 보안 설계: 보안과 격리가 중요한 복잡한 설치에서는 독립적인 DAG 프로세서 구성 요소가 추가됩니다. 이는 스케줄러가 DAG 파일에 직접 접근하는 것을 완전히 차단하는 아키텍처이다.
격리의 이점:
- 스케줄러와 DAG 파일 간의 완전한 격리
- DAG 작성자가 제공한 코드가 스케줄러 컨텍스트에서 절대 실행되지 않음
- 파싱된 작업들 간의 격리 강화
보안 강화: DAG 프로세서가 DAG 파일을 파싱하고 메타데이터 데이터베이스에 직렬화하여 저장하면, 스케줄러는 이미 처리된 안전한 메타데이터만 사용합니다. 이는 악의적인 DAG 코드가 스케줄러에 영향을 미치는 것을 방지한다.
멀티테넌트 준비: Airflow가 아직 완전한 멀티테넌트 기능을 지원하지는 않지만, 이러한 아키텍처는 향후 멀티테넌트 환경을 위한 기반을 제공하며, 현재도 테넌트 간 격리 효과를 어느 정도 달성할 수 있다.
운영 복잡성: 이 아키텍처는 가장 높은 수준의 보안과 격리를 제공하지만, 동시에 가장 복잡한 배포와 관리를 요구합니다. 대규모 기업 환경이나 높은 보안 요구사항이 있는 환경에서 적합하다.
각 아키텍처는 요구사항과 환경에 따라 선택할 수 있으며, 단순한 개발 환경에서 시작하여 점진적으로 더 복잡하고 안전한 아키텍처로 발전시킬 수 있다.
4. Workloads
Apache Airflow에서 DAG는 일련의 작업(Task)들을 통해 실행되며, 일반적으로 세 가지 유형의 작업을 볼 수 있다. 미리 정의된 작업으로 빠르게 연결하여 DAG의 대부분을 구성할 수 있는 Operators, 외부 이벤트 발생을 기다리는 특수한 Operator 서브클래스인 Sensors, 그리고 사용자 정의 Python 함수를 작업으로 패키징한 TaskFlow-decorated @task이다. 내부적으로 이 모든 요소들은 실제로 Airflow의 BaseOperator의 서브클래스이며, Task와 Operator의 개념은 어느 정도 상호 교환 가능하지만, 본질적으로 Operators와 Sensors는 템플릿 역할을 하고 DAG 파일에서 이를 호출할 때 실제 Task가 생성된다고 이해하는 것이 유용합니다. 이러한 구조를 통해 개발자는 기존의 검증된 Operators를 재사용하거나, 특정 요구사항에 맞는 커스텀 Task를 쉽게 생성할 수 있어 복잡한 워크플로우를 효율적으로 구성할 수 있다.
5. Control Flow
Airflow의 제어 흐름(Control Flow)에서 DAG는 여러 번 실행되도록 설계되어 있으며 병렬 실행이 가능하고, 데이터 간격(data interval)을 포함한 매개변수를 통해 파라미터화된다. 작업 간의 의존성은 », « 연산자나 set_upstream, set_downstream 메서드를 사용하여 선언되며, 이러한 의존성이 그래프의 “엣지”를 구성하여 Airflow가 작업 실행 순서를 결정하는 기준이 된다. 작업 간 데이터 전달은 작은 메타데이터를 위한 XComs, 대용량 파일을 위한 외부 스토리지 서비스, 그리고 자동으로 데이터를 전달하는 TaskFlow API 등 세 가지 방법을 제공합니다. DAG가 복잡해질수록 Airflow는 재사용 가능한 SubDAGs, UI에서 시각적 그룹핑을 위한 TaskGroups, 중앙 리소스 접근을 위한 Connections & Hooks, 동시성 제한을 위한 Pools 등의 메커니즘을 제공하여 지속 가능한 워크플로우 관리를 지원합니다. 또한 Airflow는 사용 가능한 워커에 작업을 분산하여 전송하므로, 동일한 DAG의 모든 작업이 같은 워커나 머신에서 실행된다는 보장은 없다.