다중 실행기 동시 운용과 별칭(Alias)
Apache Airflow Official Documentation (in-repo snapshot) — Apache Software Foundation core-concepts/executor/index.rst - Using Multiple Executors Concurrently (2.10.0+), Statically-coded Hybrid Executors
이 모듈을 다 읽으면
- 2.10.0부터 지원되는 다중 실행기 구성 문법을 읽고 쓸 수 있다
- Task/Dag 단위로 executor를 지정하는 방법을 설명할 수 있다
- Alias 문법이 왜 필요한지, 특히 멀티팀 환경에서 어떻게 쓰이는지 설명할 수 있다
- 3.0.0에서 폐지된 정적 하이브리드 실행기(LocalKubernetesExecutor 등)를 대신하는 방법을 안다
Airflow 2.10.0부터 하나의 환경에서 여러 실행기를 동시에 구성해, 태스크마다 가장 적합한 실행기를 선택할 수 있다. 이 모듈은 다중 실행기 구성 문법, Task/Dag 단위 실행기 지정, 동일 실행기의 여러 인스턴스를 구분하는 별칭(Alias), 그리고 이 기능이 대체한 정적 하이브리드 실행기의 폐지 배경을 다룬다.
다중 실행기 구성 문법
Airflow 2.10.0부터 다중 실행기(multi-executor) 구성이 가능해졌다. 각 실행기는 지연(latency), 격리(isolation), 컴퓨트 효율 등에서 서로 다른 트레이드오프를 가지므로, 여러 실행기를 함께 쓰면 각 실행기의 강점을 살리고 약점을 피할 수 있다. 즉 특정 용도의 태스크 집합에는 그 목적에 가장 잘 맞는 실행기를 지정할 수 있다.
구성은 단일 실행기와 같은 [core] executor 옵션을 쓰되, 콤마로 구분된 목록 표기를 쓴다. 목록의 첫 번째 실행기는 2.10.0 이전과 동일하게 동작한다 — 즉 그 환경의 기본 실행기가 되어, 특정 실행기를 지정하지 않은 모든 Task/Dag가 이 실행기를 쓴다. 목록에 있는 나머지 실행기들은 모두 초기화되어 Task/Dag에서 지정하면 쓸 수 있는 상태가 되며, 이 목록에 없는 실행기는 태스크 실행에 전혀 쓸 수 없다.
핵심 포인트
- 실행기 목록은 콤마로 구분하며 첫 번째 실행기가 환경 기본 실행기가 된다
- 목록에 없는 실행기는 특정 Task/Dag에서 지정해도 사용할 수 없다
Alias — 같은 실행기를 여러 인스턴스로
Task/Dag에서 실행기를 더 쉽게 지정할 수 있도록, 실행기 구성은 별칭(alias)을 지원한다. 별칭은 커스텀 실행기의 모듈 경로와 내장 코어 실행기 모두에 쓸 수 있으며, `executor = LocalExecutor,short_name:my.custom.module.ExecutorClass`처럼 `Alias:ExecutorName` 문법을 쓴다.
코어 실행기에 별칭을 다는 것은 특히 멀티팀 Airflow에서 유용하다. 같은 실행기가 전역(global) 레벨과 팀(team) 레벨에서 동시에 쓰일 때, 별칭을 이용하면 태스크가 어느 인스턴스를 쓸지 명시적으로 지정할 수 있다(예: `executor = global_celery_exec:CeleryExecutor;team1=team_celery_exec:CeleryExecutor`). 다만 같은 Executor 클래스를 두 인스턴스로 쓰는 것은 멀티팀 Airflow에서만 지원된다 — 예를 들어 두 개의 서로 다른 팀은 각자 CeleryExecutor를 쓸 수 있지만, 한 팀이 CeleryExecutor 두 인스턴스를 동시에 쓸 수는 없다. 실행기는 전역과 팀에서 동시에 쓰일 수도 있다.
핵심 포인트
- 별칭 문법은 executor = alias:ExecutorClass 형태이며 커스텀 경로와 내장 실행기 모두에 적용된다
- 동일 Executor 클래스를 전역과 팀 레벨에서 동시에 쓸 때(멀티팀) 별칭으로 어느 인스턴스를 가리키는지 구분한다
- 같은 Executor 클래스를 두 인스턴스로 쓰는 것은 멀티팀에서만 지원되며, 단일 팀이 같은 실행기를 두 번 쓸 수는 없다
Task/Dag에 실행기 지정하기
Dag가 구성되지 않은 실행기를 태스크에 지정하면 Dag 파싱이 실패하고 Airflow UI에 경고 대화상자가 표시된다. 따라서 사용하려는 모든 실행기는 스케줄러·워커 등 어떤 Airflow 컴포넌트가 실행되는 호스트/컨테이너에서든 Airflow 설정에 명시되어 있어야 한다.
태스크에 실행기를 지정하려면 Operator의 executor 파라미터를 쓴다: `BashOperator(task_id="hello_world", executor="LocalExecutor", bash_command="echo 'hello world!'")` 또는 `@task(executor="LocalExecutor")`. Dag 전체에 실행기를 지정하려면 기존 Airflow 메커니즘인 default_args를 활용한다 — `default_args={"executor": "LocalExecutor"}`로 두면 개별 태스크가 명시적으로 오버라이드하지 않는 한 Dag의 모든 태스크가 이 실행기를 쓴다. 태스크는 자신이 설정된 실행기를 Airflow 데이터베이스에 저장하며, Dag가 파싱될 때마다 변경 사항이 반영된다.
핵심 포인트
- Operator의 executor 파라미터 또는 Dag의 default_args로 실행기를 지정할 수 있고, 개별 태스크가 우선한다
- 설정되지 않은 실행기를 Dag가 참조하면 파싱이 실패하고 UI에 경고가 뜬다 — 모든 컴포넌트 호스트에 동일하게 실행기를 설정해야 한다
- 태스크에 설정된 실행기는 DB에 저장되며 Dag가 다시 파싱될 때마다 반영된다
모니터링과 3.0.0에서 폐지된 정적 하이브리드 실행기
단일 실행기를 쓸 때 Airflow 메트릭은 2.9 이전과 동일하게 동작한다. 다중 실행기가 구성되면 실행기 메트릭(executor.open_slots, executor.queued_slots, executor.running_tasks)이 구성된 실행기마다 각각 발행되며, 메트릭 이름 뒤에 실행기 클래스명이 붙는다(예: executor.open_slots.<executor class name>). 로깅은 단일 실행기 때와 동일하게 동작한다.
과거에는 LocalKubernetesExecutor, CeleryKubernetesExecutor라는 두 개의 '정적으로 코딩된(statically coded)' 하이브리드 실행기가 있었지만, Airflow 3.0.0부터 더 이상 지원되지 않는다. 이들은 Task Instance의 queue 필드를 이용해 어느 하위 실행기로 보낼지 표시·유지했는데, 이는 queue 필드의 오·남용이었고 이 하이브리드 실행기를 쓰는 동안에는 그 필드를 본래 용도로 쓸 수 없게 만들었다. 또한 이런 실행기는 가능한 조합마다 손수 '구체(concrete)' 클래스를 만들어야 해서, 실행기가 늘어날수록 유지보수 부담이 감당하기 어려워졌다. 이런 방식의 실행기는 더 이상 지원되지 않으며, 대신 다중 실행기 동시 운용 기능을 쓰는 것이 권장된다.
핵심 포인트
- 다중 실행기 사용 시 executor.open_slots 등의 메트릭 이름에 실행기 클래스명이 붙어 실행기별로 발행된다
- LocalKubernetesExecutor, CeleryKubernetesExecutor 같은 정적 하이브리드 실행기는 queue 필드를 오·남용했고 조합마다 별도 클래스가 필요해 Airflow 3.0.0부터 폐지되었다
- 하이브리드 실행기의 대체재는 다중 실행기 동시 운용 기능이다