이번 시간에는 Airflow가 어떻게 작동하는지 간략히 알아보자.
우선 airflow 서버가 싱글/멀티 노드 여부에 따라 다르게 동작한다.
동작 방식에 설명에 앞서 이전에 설명했던 Airflow의 코어 컴포넌트에 대한 이해가 필요하다.

아키텍쳐

싱글 노드 아키텍쳐

싱글 노드의 경우 Web server, Scheduler, Metastore, Executor가 단일 머신 안에서 동작한다.
모든 컴포넌트는 Metastore(Meta DB)를 통해 통신한다.

• Web server는 Metastore에 저장된 메타데이터를 Fetch
• Scheduler는 Task를 생성하기 위해 Metastore와 통신
• Executor는 Metastore를 확인하여 생성된 Task를 Worker에게 할당, 종료 시 Status 업데이트
• 싱글 노드에서는 Queue는 Executor 내부에 존재하며, 어떠한 순서로 Task가 실행될지를 Queue를 통해 정의

싱글 노드는 단순한 테스트 용도로는 적합하지만, 어느 정도 이상의 task를 수행하기 위해서는 멀티 노드 구조가 필요하다.

멀티 노드 아키텍쳐

멀티 노드 구조에서는 코어 컴포넌트들이 아래와 같이 서로 다른 노드로 분리 배치된다.
1. Web server, Scheduler, Executor
2. Metastore, Queue
3. Airflow Worker #1
4. Airflow Worker #2
n. Airflow Worker #n

• Queue는 싱글 노드와 달리 Executor에서 분리되었으며, RabbitMQ나 Redis와 같은 서드파티 Queue를 사용한다.
• 또한, 싱글 노드와 달리 많은 수의 airflow worker를 가지게 된다
  따라서, 노드#1-2가 아닌 다른 노드로 Task가 분산되어 처리된다.
• Web server는 동일하게 Metastore의 정보를 fetch하여 보여주고
• Scheduler는 Executor와 Metastore에 새로운 task가 생겼음을 알려준다
• 각 Worker들은 Queue를 바라보고 있다가, Task가 생긴경우 fetch하여 실행한다.

구체적인 스케줄 예시

1. 새로운 파이프라인을 생성하여 dag.py를 dags 디렉토리에 추가하였다
2. Web server와 Scheduler는 dag.py를 각각 Parse한다.
3. Web server는 Parse하여 웹 UI에 노출시키고, Scheduler는 Metastore에 DagRun Object(DAG의 인스턴스)를 생성한다.
4. Dag가 트리거되면, DagRun의 status가 Running으로 바뀌고, 진행해야할 Task가 TaskInstance로 Metastore에 생성된다.
5. TaskInstance가 생성된 이후, TaskInstance는 Scheduler에 의해서 Executor로 전달된다.
6. Executor가 TaskInstance를 실행한 이후에(Task 종료 이후) Metastore의 TaskInstance 상태를 업데이트한다.
7. Scheduler는 지속적으로 Metastore를 확인하여 TaskInstance가 모두 종료되었는지 확인하고, 종료되었다면 DagRun의 status를 Completed로 업데이트
8. Webserver는 DagRun의 상태를 보고 웹 UI에서 업데이트

제대로 설명되어 있는 그림을 찾기 힘들어, 글로만 작성하였다.
나중에라도 그림을 찾게되면 첨부해둘 예정이다.