[Airflow] Airflow는 왜 등장했을까? + 구성 요소

10명의 데이터 엔지니어가 500개의 ETL 파이프라인을 짜서 돌린다고 해보자. 각 파이프라인은 실행되는 시간과 주기가 다를 것이고 이에 필요한 리소스가 다를 것이다. 또한, 어떤 파이프라인을 누가 짰는지 구분하기 어려울테니 관리하기도 힘들 것이다.

이런 대량의 파이프라인들을 어떻게 스케줄에 맞춰 실행하고 관리할 수 있을까?

 

약 10년 전, Airbnb는 점점 복잡해지는 workflow를 관리하기 위해 Airflow를 개발하고 오픈 소스로 공개했다. 복잡한 workflow를 관리하는 문제는, 많은 회사에서도 맞닦뜨린 문제였기에 널리 쓰이는 플랫폼이 되었다. 그렇게 Airflow는 현재 데이터 파이프라인 관리, ETL(Extract, Transform, Load) 작업, 데이터 처리 및 분석 등의 다양한 용도로 활용되고 있다

 

 

그렇다면 Airflow를 구성하고 있는 요소들은 어떤게 있는지, 그리고 어떤 역할을 하는지 살펴보자

 

 

Airflow는 Scheculer, Executor, Worker, Web server, Meta Database로 구성되어 있다. 먼저 scheduler는 DAG directory를 주기적으로 스캔하며 새로운 DAG가 있는지 확인하고, 각 DAG의 시작 시간과 실행 주기를 확인한다. DAG가 실행되어야하는 시간이 되면 DAG 내 개별 태스크를 큐에 넣어준다. 이때 각 태스크의 종속성(다른 태스크가 먼저 실행되었는지 여부, 혹은 다른 태스크를 트리거하는지)를 확인하며 종속성이 충족된 태스크들(즉, 실행 준비가 된 태스크)을 큐에 순서대로 넣는다. 

 

또한 scheduler는 DAG 실행 스케줄링, 태스크 상태에 관한 데이터, 실행 기록 등을 metadata DB에 기록한다.

 

scheduler가 큐에 넣은 태스크들을 실제로 실행시키는건 executor다. executor를 아주 간략하게 설명하면, 큐에 쌓인 태스크들을 어떻게 실행할지 결정해 worker들에게 일을 분배하는 주체다. executor는 여러 전략으로 태스크를 분배하며, 대표적인 executor는 다음과 같다

 

1) Sequential Executor

• 모든 태스크가 단일 프로세스 내에서 순차적으로 실행된다. 따라서 하나의 태스크가 실행 중일 때 다음 태스크는 큐에 대기 상태로 남아있으며, 병렬 처리가 불가능하다
• 아주 작은 규모의 데이터 파이프라인이나 테스트 목적으로는 적합하지만, 병렬 실행이 필요하거나 큰 규모의 데이터 파이프라인에는 적합하지 않다

2) Local Executor

• 로컬 환경에서 실행할 때 사용되는 것으로, 하나의 서버에서 여러 태스크를 병렬로 처리한다. 각 태스크는 별도의 프로세스로 실행될 수 있고 일반적으로 executor와 worker가 같은 서버 내에서 모든 작업을 처리한다
• 단일 서버 내에서 다수의 코어를 활용해 태스크를 병렬 실행할 때와 중소 규모의 데이터 파이프라인에서는 적합하지만, 다수의 서버를 이용해야하는 경우엔 적합하지 않다. 즉, 확장성이 떨어진다

3) Celery Executor

• 분산 환경에서 분산 작업 큐를 이용해 태스크를 여러 워커에 분산해 실행한다. 여러 대의 워커에서 태스크를 병렬로 처리할 수 있으며 작업 부하가 증가하면 Celery를 통해 쉽게 추가 워커를 스케일 아웃할 수 있다
• 이때 worker에게 직접 일을 분배한다기보다, worker가 큐에 있는 태스크들을 가져가는 형태에 더 가깝다
• 분산 환경에서 태스크를 병렬로 처리하는 경우에 적합하며, 작업 부하에 따라 탄력적으로 확장할 수 있는 장점이 있다

4) Kubernetes Executor

• 최근 docker와 같은 컨테이너 기술로 애플리케이션을 포함한 환경 자체를 컨테이너로 패키징하고 배포하는 것이 일반적인데, Kubernetes Executor는 worker를 Pod(컨테이너)로 생성해 태스크를 실행한다. 또한, 하나의 Pod는 여러 개의 태스크를 처리할 수 있다
• 각각의 태스크 실행시마다 worker를 사용했다가 회수하는 형태이기 때문에 자원의 효율성이 올라가며 확장성이 좋다

worker는 이름에서도 알 수 있듯 배분 받은 각각의 태스크를 수행한다.

 

 

 

정리하자면, Airflow는 두가지 측면에서 장점이 있다

1. 전체 파이프라인을 한 눈에 확인할 수 있어, 실패한 데이터 파이프라인을 재실행하는데 용이하다

2. backfill(파이프라인 실패시 과거 데이터를 채우는 과정)이 용이하다. 이는 데이터 엔지니어의 업무를 효율적으로 만들어준다

 

많은 파이프라인들을 관리할 수 있는 여러 workflow 관리 도구가 나오지만, Airflow는 정말 많은 회사들이 쓰는 도구라는 점을 보면 좋은 workflow 관리 도구라는 것이 느껴진다. 오늘 Airflow가 필요해진 계기와 그 구성 요소들에 대해 살펴봤는데 이런 기술들을 잘 이해할 수 있는 관점은 '어떤 필요에 의해 만들어졌을까'인 것 같다. 좋은 기술은 필요와 align이 잘 되어있는게 아닐까?

 

 

도입 사례로 살펴보는 Airflow의 필요성

Airflow 도입부를 어떻게 작성하면 좋을까 하고 고민하다가 몇몇의 Airflow 환경 구축기를 보게 되었다. 이런 구축기들을 보면 Airflow의 필요성과 구성 요소들이 더 잘 이해되는 것 같다

• https://www.bucketplace.com/post/2021-04-13-%EB%B2%84%ED%82%B7%ED%94%8C%EB%A0%88%EC%9D%B4%EC%8A%A4-airflow-%EB%8F%84%EC%9E%85%EA%B8%B0/
• https://tech.socarcorp.kr/data/2021/06/01/data-engineering-with-airflow.html

쏘카 데이터 그룹 - Airflow와 함께한 데이터 환경 구축기(feat. Airflow on Kubernetes)

 

 

 

 

[출처] 데이터 엔지니어링 데브코스