[에어플로우] 아파치 에어플로우(Apache Airflow)란?

아파치 에어플로우(Apache Airflow)

image

  • 에어비앤비에서 개발한 워크 플로우 스케쥴링, 모니터링 플랫폼이다.
  • 실제 데이터의 처리가 이루어지는 곳은 아니다.
  • 2016년 아파치 재단에서 인큐베이터 프로그램(incubator program)으로 뽑아 관리를 시작했다.
  • 현재는 아파치의 탑 레벨 프로젝트로 관리되고 있다.
  • 에어비엔비, 야후, 페이팔, 인텔 등에서 사용중이다.
  • 위 회사에서 느끼는 공통적인 문제가 있을 것이다.

워크 플로우(Workflow) 관리 문제

image

  • 만약 매일 10시에 주기적으로 돌아가는 데이터 파이프 라인을 만들어야 한다고 가정한다.
  • 워크 플로우가 하나라면 크론 스크립트로 관리하면 됐다.
  • 하지만 이 방식의 문제점이 존재했다.

기존 방식의 문제점

  • 실패 복구: 언제 어떻게 다시 실행할 것인지, 백필(Backfill)은 어떻게 할 것인지에 대한 문제가 있었다.
  • 모니터링: 잘 돌아가고 있는 지 확인하기 힘들었다.
  • 의존성 관리: 데이터 파이프 라인 간 의존성이 있는 경우 상위 데이터 파이프 라인이 잘 돌아가고 있는 지 파악이 힘들었다.
  • 확장성: 중앙화해서 관리하는 툴이 없기 때문에 분산된 환경에서 파이프 라인을 관리하기 힘들었다.
  • 배포: 새로운 워크 플로우를 배포하기 힘들었다.

에어플로우의 등장

image

  • API를 통해 데이터를 다운로드하는 프로세스가 실패했다고 가정한다.
  • 만약 이런 파이프 라인이 수십 개 있다면, 엔지니어가 관리하기 굉장히 버거워 진다.
  • 에어플로우는 워크 플로우를 작성하고 스케쥴링하고 모니터링하는 작업을 프로그래밍할 수 있게 해주는 플랫폼이다.
    • 파이썬으로 쉬운 프로그래밍이 가능하다.
    • 분산된 환경에서 확장성이 있다.
    • 웹 대시보드(UI)를 제공한다
    • 커스터마이징이 가능하다.

워크 플로우

  • 의존성으로 연결된 작업(task)들의 집합이다.
    • DAG(Directed Acyclic Graph)

image

DAG(Directed Acyclic Graph)

image

  • 위 이미지에서 위 테이블은 DAG이고, 아래 테이블은 DAG가 아니다.
  • DAG는 무한 순환되지 않는다.

image

  • 위 이미지는 UI 상에서의 DAG이다.

에어플로우의 구성

  • 웹 서버: 웹 대시보드 UI이다.
  • 스케쥴러: 워크 플로우가 언제 실행되는 지 관리한다.
  • 메타스토어(Metastore): 메타 데이터를 관리한다.
  • 익세큐터(Executor): 테스크가 어떻게 실행되는 지 정의하는 컴포넌트이다.
  • 워커(Worker): 테스크를 실행하는 프로세스이다.

오퍼레이터(Operator)

  • 하나의 테스크를 정의하는데 사용된다.
  • 액션 오퍼레이터(Action Operators)
    • 실제 연산을 수행한다.
  • 트랜스퍼 오퍼레이터(Transfer Operators)
    • 데이터를 옮긴다.
  • 센서 오퍼레이터(Sensor Operators)
    • 테스크를 언제 실행시킬 지 트리거를 기다린다.

테스크(Task)

  • 오퍼레이터를 실행시키면 테스크가 된다.
  • 테스크는 오퍼레이터 인스턴스이다.

에어플로우의 유용성

  • 데이터 웨어하우스, 머신 러닝, 분석, 실험, 데이터 인프라 관리에서 쓰이게 된다.

에어플로우의 구조

  • DAG의 생성부터 실행까지 알아볼 것이다.
  • 에어플로우의 환경은 크게 두 가지로 나눌 수 있다.
    • 하나의 서버에서 실행되는 원 노드 아키텍쳐(One-node Architecture)
    • 분산된 서버에서 실행되는 멀티 노드 아키텍쳐(Multi-nodeArchitecture)

원 노드 아키텍쳐(One-node Architecture)

image

  • 원 노드 아키텍쳐는 크게 네가지 모듈로 나눌 수 있다.
    • 웹 서버(Web server)
    • 메타스토어(Metastore)
    • 스케쥴러(Scheduler)
    • 익세큐터(Executor)
  • 메타스토어가 DAG에 대한 정보를 담고 있어서 웹 서버와 스케쥴러가 그 정보를 읽어오고 익세큐터로 이 정보를 보내 실행시키게 된다.
  • 실행된 테스크 인스턴스(Task instance)는 메타스토어로 다시 보내져서 상태를 다시 업데이트하게 된다.
  • 업데이트된 상태를 다시 웹 서버와 스케쥴러가 읽어와서 테스크가 완료되었는 지 확인하게 된다.
  • 익세큐터 안에는 큐(Queue)라는 것이 존재해서 테스크의 순서를 정할 수 있다.

멀티 노드 아키텍쳐(Multi-nodeArchitecture)

image

  • 멀티 노드 아키텍쳐에서는 큐가 익세큐터 바깥에 존재한다. 이것이 원 노드 아키텍쳐와의 차이이다.
  • 멀티 노드 아키텍쳐에서는 셀러리 브로커(Celery Broker)가 밖에 나와있는데 이것이 원 노드 아키텍쳐의 큐와 같다.
  • 두 가지의 점선 박스와 외부의 셀러리 브로커와 메타 스토어까지 세 가지 파트로 나눌 수 있다.
  • 처음 실행 될 때 에어플로우 UI와 스케쥴러가 메타 스토어의 정보를 읽어오고, 이렇게 읽어온 데이터를 셀러리 익세큐터로 브로커에 담게 된다.
  • 순서대로 담긴 테스크를 워커들이 하나씩 가져가서 순서대로 실행 시킬 수 있게 된다.
  • 실행된 DAG들은 완료된 다음 다시 셀러리 익세큐터, 메타 스토어로 보고되고 완료된 상태를 UI와 스케쥴러가 다시 읽어온다.

동작 방식

  • DAG를 작성하여 워크 플로우(Workflow)를 만든다.
    • DAG는 테스크(Task)로 구성되어 있다.
  • 테스크는 오퍼레이터(Operator)가 인스턴스화 된 것이다.
  • DAG를 실행시킬 때 스케쥴러는 DagRun 오브젝트를 만든다.
  • DagRun 오브젝트는 테스크 인스턴스를 만든다.
  • 워커(Worker)가 테스크를 수행 후 DagRun의 상태를 ‘완료’로 바꿔놓는다.

DAG의 생성과 실행

image

  • 유저가 새로운 DAG를 작성 후 Folder DAGs 안에 배치한다.
  • 웹 서버와 스케쥴러가 DAG를 파싱하여 읽어온다.
  • 스케쥴러가 메타스토어를 통해 DagRun 오브젝트를 생성한다.
  • DagRun 오브젝트는 사용자가 작성한 DAG의 인스턴스이다.
  • DAG의 상태를 ‘러닝(Running)’의 상태로 바꿔놓는다.
  • 스케쥴러는 테스크 오브젝트 인스턴스를 스케쥴링하게 된다.
  • 트리거가 상황이 맞으면 스케쥴러가 테스크 인스턴스를 익세큐터로 보내게 된다.
  • 익세큐터는 테스크를 실행 시킨 다음 완료 후 메타 스토어에 보고한다.
  • 완료된 테스크 인스턴스는 DagRun을 업데이트 하게 되고 스케쥴러는 DAG가 실행이 됐나 확인 하여 DagRun의 상태를 ‘완료’로 바꿔놓는다.
  • 마지막으로 메타 스토어에 대한 정보를 다시 웹 서버가 읽어옴으로서 UI를 업데이트하고 사용자도 워크 플로우가 성공했다는 것을 볼 수 있게 된다.
0%