소개, 기본 구조
- 오픈소스 워크플로우 관리 플랫폼
- 일련의 작업 흐름을 DAG(Directed Acyclic Graph)로 관리
- 가볍게 cron 대용으로 사용할 생각으로 시작했는데 생각보다 강력한 툴
- 서버 7~8대 붙여서 몇십명이 붙어 사용하기도 한다
Basic airflow architecture
metadata database
dag 정보, 실행이력, 스케줄링 이력, 유저 정보 등 실행하는 workflow에 필요한 메타데이터를 저장한다.
web server & scheduler
에어플로우 웹서버와 스케줄러는 분리된 프로세스로, metadata database와 상호작용한다.
executor
위 그림에서는 executor와 scheduler가 분리되어있지만, 사실 executor는 scheduler 안에서 동작한다. 작업을 worker가 수행하는 방식을 결정한다.
worker(s)
다른 요소들과 상호작용하며, 실제 작업을 수행한다.
airflow.cfg
configuration file로 timezone, database connection 등 실행에 필요한 다양한 정보를 저장한다. 웹서버, 스케줄러, 워커가 접근할 수 있어야 한다.
dags
python code로 만들어진 data pipeline 정의 파일로, 이것 역시 웹서버, 스케줄러, 워커가 접근할 수 있어야 한다.
도입 계기
요구사항
- python 배치를 스케줄링하여 실행할 수 있는 툴
- 여러 서버에 일을 시킬 수 있으면 더 좋다
- 수행 이력이 남아야 함
- 동시접근 가능
- 유지/배포/모니터링 용이
다른 후보들
- CI 툴
- Workflow 관리 도구
- Azkaban
- Oozie
- Airflow
- luigi
why airflow
- 친근한 python으로 DAG를 설정할 수 있다.
- 세팅이 간단해보였다. ㅠㅠ
- 더 쉬운 Luigi는 scheduling 기능이 내장되어있지 않아 따로 세팅 필요
- 나름 예쁜 UI 제공
- CI툴에 대한 거부감
- 왜 배포용 툴로 배치 스케줄링을 하지..?
- 젠킨스를 조직 내 많은 사람들이 오랫동안 써왔기 때문에 모두가 익숙하게 사용할 수 있다는 장점도 무시할 수 없었고, 세팅도 그렇게 복잡하지 않았다.
- 다만 workflow 관리 용도로 나온 도구가 아니기때문에, workflow 관리를 위해서는 이런저런 플러그인이 필요하고, 이 플러그인들이 더 관리를 복잡하게 만든다.
- workflow 관리에 필요한 기능들
- 일부 Task가 실패한 경우 인지 및 재실행
- 선행조건과 수행시간이 다른 각 Task의 수행 순서 설정
- Task별 수행시간 분석과 로그 비교
- 여러 서버에 존재하는 Task의 스케쥴링
- 과거 누락된 일부 Task를 과거 기준으로 재수행
참고