[Airflow]Executor(실행기) 선택 가이드

데이터 파이프라인을 구축할 때 Apache Airflow를 도입하기로 했다면, 가장 먼저 부딪히는 아키텍처적 고민이 바로 "어떤 Executor(실행기)를 사용할 것인가?"입니다.

Airflow의 스케줄러가 '언제' 작업을 할지 결정한다면, Executor는 '어디서, 어떻게' 작업을 실행할지 결정하는 핵심 컴포넌트입니다.
인프라의 규모, 예산, 그리고 데이터 볼륨에 따라 스케일 업(Scale-up)을 할지 스케일 아웃(Scale-out)을 할지 결정하는 중요한 기준이 되죠.

오늘은 Airflow의 뼈대가 되는 4가지 핵심 Executor의 특징과 세팅 방법, 그리고 DA(Data Architect) 관점에서의 추천 환경을 정리해 보겠습니다.

---

1. SequentialExecutor: 가장 단순한 시작

이름 그대로 한 번에 단 하나의 태스크만 순차적으로 실행하는 기본 실행기입니다.

• 동작 방식: 단일 프로세스 내에서 태스크를 1개씩 순서대로 처리합니다.
• 필수 세팅: * Airflow를 설치하면 기본값으로 설정되어 있습니다.
  • 메타데이터 DB로 SQLite를 사용해야 합니다. (SQLite의 동시 쓰기 제약 때문)
  • airflow.cfg 설정: executor = SequentialExecutor
• 장점: 설정이 아예 필요 없을 정도로 단순하며, 인프라 리소스가 거의 들지 않습니다.
• 단점: 병렬 처리가 불가능하므로 앞선 작업이 지연되면 파이프라인 전체가 밀리게 됩니다.

💡 (Use Case)
실제 운영(Production) 환경에서는 절대 사용하지 마세요. 로컬 PC에서 Airflow를 처음 띄워보거나, 간단한 DAG 문법 테스트 용도로만 적합합니다.

2. LocalExecutor: 단일 서버의 한계를 돌파하다

단일 노드(서버) 환경에서 멀티프로세싱을 통해 여러 태스크를 동시에 병렬로 실행합니다.

• 동작 방식: 설정한 Worker 수(parallelism)만큼 프로세스를 생성하여 태스크를 동시에 처리합니다.
• 필수 세팅:
  • 다중 연결을 지원하는 RDBMS(MySQL, PostgreSQL)로 메타 DB를 변경해야 합니다.
  • airflow.cfg 설정: executor = LocalExecutor
• 장점: 별도의 큐(Queue) 시스템이나 클러스터 구축 없이, 서버 한 대의 리소스만으로 훌륭한 병렬 처리가 가능합니다. 인프라 관리 포인트가 적어 운영이 매우 편리합니다.
• 단점: 스케일 아웃(Scale-out)이 불가능합니다. 단일 서버의 CPU나 메모리가 한계에 도달하면 더 이상 처리량을 늘릴 수 없습니다.

💡 (Use Case)
파이프라인 개수가 수십 개 이하이고, 고성능 가상머신(VM) 한 대로 충분히 커버 가능한 초기/중소규모 프로젝트의 운영 환경으로 강력히 추천합니다.

3. CeleryExecutor: 엔터프라이즈를 위한 무한한 확장

분산 아키텍처의 표준입니다. 여러 대의 Worker 서버를 두고 대규모 워크로드를 분산 처리합니다.

• 동작 방식: 중앙의 메시지 브로커(Message Broker)에 태스크를 밀어 넣으면, 네트워크로 연결된 다수의 Worker 노드들이 작업을 가져가(Pull) 병렬로 실행합니다.
• 필수 세팅:
  • MySQL/PostgreSQL 메타 DB 필수.
  • Worker 간 통신과 작업 분배를 위한 Redis 또는 RabbitMQ 설치 및 연동 필수.
  • airflow.cfg 설정: executor = CeleryExecutor 및 broker_url 설정.
• 장점: Worker 노드만 추가하면 이론상 무한대로 스케일 아웃이 가능합니다.
• 단점: Redis/RabbitMQ라는 추가 인프라를 관리해야 하므로 아키텍처가 복잡해지고 운영 난이도가 급격히 올라갑니다.

💡 (Use Case)
매일 수백~수천 개의 무거운 데이터 파이프라인이 동시에 돌아가야 하는 대규모 통합 프로젝트에 적합합니다.

4. KubernetesExecutor: 클라우드 네이티브의 완성

클라우드 인프라의 꽃, Kubernetes(K8s) 환경에 최적화된 실행기입니다.

• 동작 방식: 태스크가 큐에 들어올 때마다 K8s 클러스터 상에 독립적인 Pod을 하나씩 생성하여 작업을 수행하고, 작업이 끝나면 Pod을 즉시 삭제(회수)합니다.
• 필수 세팅:
  • 실행 가능한 Kubernetes 클러스터 (EKS, AKS, GKE 등).
  • airflow.cfg 설정: executor = KubernetesExecutor 및 K8s 인증(kubeconfig) 설정.
• 장점: 자원 효율이 극한으로 좋습니다. 특정 무거운 작업에만 자원을 많이 할당할 수 있고, 작업이 없을 때는 Worker 리소스가 0으로 수렴하여 클라우드 비용을 절감합니다. 완벽한 태스크 격리(Isolation)가 보장됩니다.
• 단점: 매번 Pod을 생성하므로 태스크 시작 시 지연(Latency)이 발생할 수 있으며, K8s 자체에 대한 높은 기술적 이해도가 필요합니다.

💡 (Use Case)
이미 사내에 K8s 인프라가 표준으로 구축되어 있거나, 특정 시간대에만 배치가 집중되는 스파이크성 워크로드를 처리하여 비용을 최적화해야 할 때 최고의 선택입니다.

---

📊 한눈에 보는 요약 테이블

구분	병렬 처리	분산 확장(Scale-out)	필수 추가 인프라	운영 난이도
Sequential	❌	❌	없음 (SQLite)	하
Local	⭕	❌	MySQL / PostgreSQL	중
Celery	⭕	⭕	MySQL/PG + Redis/RabbitMQ	상
Kubernetes	⭕	⭕	K8s 클러스터 환경	최상

성공적인 데이터 파이프라인 구축을 위해서는 현재 우리 조직의 데이터 볼륨, 인프라 예산, 그리고 팀원들의 운영 숙련도를 객관적으로 파악하고 그에 맞는 Executor를 선택하는 것이 가장 중요합니다.