#3 Airflow Concepts documentation 부수기 [Architecture]

Airflow Tutorial documentation까지 읽었다면, 사실 python code가 어느 정도 익숙하다면 바로 작성해 보는 것도 좋다.

 

하단 이미지는 요새 회사에서 작성하고 있는 data pipeline의 일부분이다.

airflow 도입 결정 1주일 정도에 이 정도 작성했는데,  물론 단순한 aws hook을 불러와서 실행시키는 작업들이 있기는 하지만, 복잡한 dependency를 만족해야 하는 workflow를 간단하게 작성한다는 것 자체가  Airflow가 정말 쉽고 좋다는 방증이다.

저 빨간 에러 하나 때문에 골머리 썩는 중..

아무튼 조금 더 Airflow 지식과 시간적인 여유가 생기면 Airflow 사이드 프로젝트도 블로그에 포스팅할 예정이다.

 

일단 이 포스팅은 좀 더 개념적으로 Airflow에 대해 알아보기 위해 Airflow Concepts documentation을 정리해 보겠다.

 

Airflow Concepts에서 제공하는 큰 3가지 가지는 아래와 같다.

1. Architecture

2. Workloads

3. Communication

 

먼저 Architecture 를 정리해 볼 것이다. 주소는 하단과 같다.

https://airflow.apache.org/docs/apache-airflow/stable/concepts/overview.html

Architecture Overview — Airflow Documentation

Airflow의 전체 구조를 설명하는 documentation이다. 

 

Airflow는 특정한 작업 흐름을 정의하고 이를 실행시키는 플랫폼이다.

그리고 그 작업 흐름은, DAG(a Directed Acyclic Graph) 를 통해 표현한다. 

DAG 는 방향이 있는 비순환 그래프이다. 처음에 나도 이를 이해하는데 애를 먹었는데 곰곰이 말을 곱씹어 보면 이해가 된다.

방향성이 존재하지만 순환하지는 않는 특정 구조

 

그러면 방향성이 존재하지만 순환하지는 않는 특정 구조는 무엇으로 이루어져 있냐면,

Task 라고 불리는 일련의 작업들로 이루어져 있다.

각각의 task의 dependency와 data flow 조건들을 만족한 것이 DAG이다.

 

아래 이미지도 하나의 workflow(DAG) 의 예시가 될 수 있다.

저 초록색 박스가 Task 이고 이 화살표가 각각의 dependency를 의미한다.

이들 모임이 workflow(DAG)가 되는 것이다.

나는 이쯤 공부했을 때 이런 의문이 들었다.

"task를 python function 이라고 생각하고 work flow(DAG)를 그 fuction들의 조건식을 정교하게 작성한 main python script라고 생각하면 그냥 똑같은 것 아닌가? "

 

실제로 그게 맞다. task나 dag도 결국 python code로 이루어진 하나의 function이다.

추가로 Airflow는 각각의 task들을 개별적으로 관리할 수 있고, 에러 확인, 스케쥴링,  확장성, UI 등에서 상당히 고도화된 플랫폼이라고 이해하면 된다.

 

Airflow를 설치할 때 일반적으로 다양한 구성요소를 함께 설치한다. 각각을 알아보자.

 

1. scheduler

스케쥴러는 예약된 workflow에 대해 실행을 관리하는 스케쥴링 작업을 하고, workflow 내에 있는 다양한 Tasks 를 Executor에게 제출하여 실행하게 함.

 

2. executor 

executor(실행자) 는 동작하는 task들을 관리한다. default Airflow 설치에서는, 이러한 실행들이 scheduler에서 진행되었는데, 실제 일을 하는데 적합한 executor 들은 workers 에게  task를 push 하여 실행하게 한다.

 

3. webserver

웹 서버는 각종 DAG 및 Task들에 대해 제대로 실행되는지 검사하고, trigger, Debug 기능을 편리하게 제공하는 UI를 제공하는 서버이다. 

 

4. folder of DAG files

scheduler 혹은 executor 가 읽은 Dag files 의 폴더이다.(혹은 executor 가 workers 에게 넘긴 dag 일 수도)

 

5. Metadata Database

scheduler, executor 그리고 webserver 의 상태를 저장하는 Database이다.

참고로 Metadata는  데이터에 대한 데이터로 일반적으로 데이터를 관리(더 잘 사용.. 등등) 하기 위해 저장한다.

Airflow에서는 다양한 component 를 관리하기 위해 사용한다.

 

 

일반적으로 대부분의 executor는 그들이 관리하는 workers 에게 또 다른 구성요소와 대화하도록 다른 구성요소에 대한 정보를 준다. ( task queue와 같이)

그러나 여전히 executor 와 workers 는 Airflow에서 실제 작업을 실행하는  하나의 논리적인 구성 요소라고 생각해도 좋다.

 

또한 Airflow 는 무엇이 실행되는지 상관없이 다 설계 및 실행이 가능하다.

Airflow 가 제공하는 provider 를 사용해도 좋고, shell 이나 python operator를 선언해서 사용해도 좋다.

 

Workloads

Dag는 일련의 Task 들을 실행하는데, 일반적으로 Task 는 다음과 같이 3가지 종류로 나뉘게 된다.

 

1. Operators

아마 가장 많이 사용하게 될 Operator 인데, 미리 정의 해 놓은 task 들을 연결하여 빠르고 쉽게 Dag 의 대부분을 구성할 수 있다.

 

2. Sensors

외부 이벤트가 발생하기를 기다리는 특수 subclass이다

 

3.  TaskFlow

@task 라고 표현 가능한데, 사용자가 정의한 Python 함수를 패키징 하는 역할인 듯하다. 나중에 자세히 다뤄봐야겠다.

 

내부적으로 이들은 모두 BaseOperator의 하위 클래스다. 또한 Operators 와 Task 의 개념은 비슷한 경우가 있지만, 둘을 분리된 개념으로 생각하는 게 생각하는 것이 유용하다.

기본적으로, Operators 와 Sensors 는 templates 이기 때문에 DAG 파일에서 불러와서 Task를 만든다.  

 

Control Flow

DAGs 는 여러 번 실행되고, 동시에 병렬적으로 실행되도록 설계되어 있다.  DAG 의 파라미터 중 반드시 포함되는 execution_date를 통해 언제 실행할지를 나타낸다. 또 다른 선택적인 파라미터도 같이 포함된다.

 

Tasks 는 각 Task 마다 dependency가 서로 존재하고 이는 >> 혹은 << 연산자로 표현할 수 있다.

 

first_task >> [second_task, third_task]
third_task << fourth_task

혹은  set_upstream or set_downstream method 를 활용해도 좋다.

 

first_task.set_downstream([second_task, third_task])
third_task.set_upstream(fourth_task)

 

이러한 dependency는 전체 workflow graph 의 가장자리 부분을 구하는 요소이며, Airflow 가 작업 실행 순서를 정의한다. 또한 Airflow 의 default setting 은 먼저 선행되어야 하는 작업이 성공해야 뒤에 작업이 순차적으로 실행된다.

그러나 이것은 사용자가  Branching, LatestOnly, and Trigger Rules 과 같은 feature 를 customizing 해서 변경 가능하다.

 

task 사이에 데이터를 주고받으려면 두 가지 옵션이 있는데,

1. XComs

xcoms(Cross-communications) 는 task 사이 작은 메타데이터를 주고받을 수 있는 시스템이다.

 

2. storage service 

실행 중인 파일 혹은 public cloud 일부에서 대용량 파일을 업로드 및 다운로드하는 경우.

 

Airflow 에서 작업을 실행할 공간이 마련되게 되면 worker 에게 task 를 보내기 때문에 DAG의 모든 task 가 동일한 시스템 및 worker에서 실행된다는 보장이 없다.

 

Airflow 에서 Dag 를 설계할 때 Dag 가 매우 복잡해질 수 있기 때문에, 지속 가능성을 늘리기 위해 Airflow에서는 몇 가지 메커니즘을 제공하는데,

SubDAGs 같은 경우 재 사용성을 늘리기 위해 다른 Dag 에 내장하여 사용할 수 있도록 제공한다.

TaskGroups 같은 경우 UI 에서 task 를 group 화 하기 위해 제공한다.

 

추가적으로 중앙 resource에 쉽게 접근하도록,  Connections & Hooks 를 제공하고 Pools 을 통해 동시성을 제한한다.

User interface

Airflow 의 또 다른 장점 중에 하나는 DAG 및 Task 를 trigger 하고, log 를 보고, DAG 관련 문제를 디버깅하고 해결할 수 있는 UI 를 제공한다.

docker에서 실행한 Airflow UI

일반적으로 Airflow 의 상태를 확인하는 가장 좋은 방법은, 일단 전체를 다 설치하고, 각각의 Dag 에 들어가서 전체 layout을 확인하고, task 의 log 나 instance 그리고 status 등을 확인하는 게 가장 좋은 방법이다.

 

이번엔 Airflow의 Concepts documentation 중 Architecture 부분을 정리해 봤다. 

다음 포스팅 에는 이어서 Airflow의 핵심인 DAG에 대해 정리한 Documentation을 정리하겠다.