Airflow 공식 문서에서 Airflow Executor를 읽고 번역 및 정리한 글이다.
Executor Types
- 크게 2가지 타입의 Executor 존재
- one run tasks locally (inside the scheduler process)
- other one run their tasks remotely (usually via a pool of workers)
- 기본적으로 local executor인
SequentialExecutor을 사용할 수 있지만, parallel task가 실행되지 않기에 production 용도로서는 적합하지 않다. some Airflow features (e.g. running sensors)은 제대로 동작하지 않을 수 있다. ⇒ 따라서 작은 단일 머신으로 설치한다면LocalExecutor을 사용해야하고 multi-machine/cloud installation를 위해서는 remote executor 중 하나를 사용하는 것이 좋다.
Local Executors
- Airflow tasks는 scheduler process에서 run 된다.
- 장점 : Very easy to use, fast, very low latency, and few requirements for setup.
- 단점 : Limited in capabilities and shares resources with the Airflow scheduler.
- Examples:
Remote Executors
- remote executor는 2가지 카테고리로 나누어진다
- Queued/Batch Executors
- Containerized Executors
- Queued/Batch Executors
- Airflow tasks는 central queue에 보내지고, 이 central queue를 통해 worker들은 실행할 tasks를 가져온다
- 장점 : 워커를 the scheduler process와 분리하기에 더 견고성을 가짐. 워커들은 많은 tasks를 처리(often in parallel)하는 large hosts가 될 수 있고, 그것은 비용 효율적이다. 워커들은 항상 실행 상태로 유지되며, 큐에서 작업을 즉시 가져올 수 있도록 설정할 수 잇기에 Latency도 상대적으로 낮을 수 있다.
- 단점 : shared worker는 같은 호스트의 자원을 두고 경쟁하거나 환경/시스템 구성 방식에 대해 경쟁(충돌?)을 일으키는 noisy neighbor 문제를 가진다. 또한 작업량이 일정하지 않은 경우, idle worker를 가지게 될 수 있고, 자원이 과도하게 스케일링될 수 있으며, 스케일 up / down을 신경써야 한다.
- Examples:
- Containerized Executors
- Airflow tasks는 ad hoc inside containers/pods 방식으로 실행된다. 각 task가 queue에 쌓이면, 자신의 고립된 containerized environment에서 실행된다. 0o0!!
- 장점 : 각 airflow task는 자신의 컨테이너에서 실행(고립)되기에 noisy neighbor problem이 일어나지 않는다. The execution environment은 specific tasks (system libs, binaries, dependencies, amount of resources, etc)을 위해 커스텀마이징이 가능하다.
- 단점 : 작업이 시작되기 전에 컨테이너 또는 pod가 배포되어야 하므로 초기 지연이 발생할 수 있다. 따라서 짧고 작은 task가 많은 경우, 비효율적일 수 있다. 워커에 대한 관리는 없지만, k8s 클러스터 같은 시스템 관리가 필요하다
- Examples:
Using Multiple Executors Concurrently
하나의 airflow 시스템(클러스터)에서 여러 종류의 Executor를 사용하는 것에 관한 설명.
! Multiple Executors configuration 는 현재 lpha/experimental feature로서, 예고없이 변경될 수 있다.
Starting with version 2.10.0, Airflow can now operate with a multi-executor configuration. Each executor has its own set of pros and cons, often they are trade-offs between latency, isolation and compute efficiency among other properties (see here for comparisons of executors). Running multiple executors allows you to make better use of the strengths of all the available executors and avoid their weaknesses. In other words, you can use a specific executor for a specific set of tasks where its particular merits and benefits make the most sense for that use case.
Configuration
[core]
executor = 'KubernetesExecutor,my.custom.module.ExecutorClass'Multiple Executors는 잘 사용하지 않을거 같아서 자세한 내용은 스킵. 필요하다면 해당 링크 참조
Writing Your Own Executor
All Airflow executors는 a common interface를 구현하여 플러그형으로 사용할 수 있으며, All Airflow executors는 Airflow 내 모든 기능과 통합에 대해 접근할 수 있다. 주로 Airflow 스케줄러가 executor와 통신하기 위해 이 interface를 사용하지만 로깅, CLI, 백필과 같은 다른 구성 요소도 이 인터페이스를 사용한다. The public interface는 BaseExecutor이다. 세부적이고 최신 interface는 코드를 통해 확인할 수 있지만, 주요사항을 요약하였다. (For more information about Airflow’s public interface see Public Interface of Airflow.)
custom executor를 사용하는 케이스
- An executor does not exist which fits your specific use case, such as a specific tool or service for compute.
- You’d like to use an executor that leverages a compute service from your preferred cloud provider.
- You have a private tool/service for task execution that is only available to you or your organization.
custom executor도 현재 사용할 일이 없어서 자세한 내용은 스킵함. 필요하다면 해당 링크 참조
조금 정리하자면
현재는 하나의 host에서 docker를 이용하여 local executor와 celery executor를 사용하는 것을 고민중이기에 이 측면에 대하여 위 글을 읽고 생각을 정리해본다.
하나의 서버에서 local executor로 사용하는 것보다는 host의 자원이 꽤 풍족한 경우 celery executor를 활용하는 것이 좋을 거 같다. 각 컨테이너 별로 cpu 자원을 설정하는 경우, local executor는 스케줄러 컨테이너에서 task가 처리되고 worker만을 스케일링 할 수 없지만 celery executor로는 각 컨테이너에 대한 자원을 알맞게 설정할 수 있고 worker를 스케일링 할 수 있기에 작업량이 많거나 적어지는 경우 스케일을 조정하여 효율적으로 자원을 활용할 수 있을거라 생각하기 때문이다. 또한 celery executor를 통해 여러개의 worker를 뛰우면 비교적 안정적으로 운영이 가능하지 않을까 싶다. 물론 여러 개의 서버가 있는게 속도가 더욱 빠르고 안정적이겠지만…
