[Airflow] Airflow on Kubernetes - Kubernetes에서 Airflow 운영하기

 

데이터 엔지니어링 학습 중 다양한 데이터 파이프라인을 구축해보면서 복잡한 워크플로우를 자동으로 관리하고 모니터링하는 시스템에 대한 필요성이 커졌습니다. 이번 포스팅에서는 Airflow와 Kubernetes를 통해 안정적이고 효율적인 데이터 파이프라인을 구축을 위해 필요한 기본 개념에 대해 알아보겠습니다.

 

이번 포스팅은 Line Engineering의 Kubernetes를 이용한 효율적인 데이터 엔지니어링(Airflow on Kubernetes VS Airflow Kubernetes Executor)글을 참고하여 작성하였습니다.

https://engineering.linecorp.com/ko/blog/data-engineering-with-airflow-k8s-1

Kubernetes를 이용한 효율적인 데이터 엔지니어링(Airflow on Kubernetes VS Airflow Kubernetes Executor) - 1

 

 

Airflow란?

Apache Airflow는 데이터 파이프라인을 프로그래밍 방식으로 작성, 스케줄링, 모니터링하는 오픈 소스 플랫폼입니다. Airflow의 핵심 개념은 'DAG(Directed Acyclic Graph)'이며, 이는 여러 Task의 의존 관계를 정의한 워크플로우를 의미합니다.

• DAGs as Code: 파이썬 코드로 워크플로우를 정의하므로, 버전 관리, 테스트, 재사용성이 뛰어납니다.
• Rich UI: 웹 기반의 강력한 사용자 인터페이스를 통해 워크플로우의 실행 현황과 로그를 한눈에 확인할 수 있습니다.
• 다양한 오퍼레이터: 여러 클라우드 서비스(AWS, GCP, Azure), 데이터베이스, 외부 API 등과 쉽게 연동할 수 있는 Task 모듈을 제공합니다.

 

Airflow 기본 동작 원리

다음의 그림을 통해 Airflow의 핵심 컴포넌트들이 어떻게 상호작용하는지 살펴보겠습니다.

출처: https://engineering.linecorp.com/ko/blog/data-engineering-with-airflow-k8s-1

 

• Scheduler: Airflow의 '심장' 역할을 합니다. 모든 DAG와 태스크를 모니터링하고 관리합니다. DAG 스크립트를 주기적으로 읽고, 실행 조건이 충족된 Task(Find Executable Task)를 찾아 실행 가능한 상태로 변경합니다.
• DAG Script: 개발자가 작성한 파이썬 코드로, Task들의 의존 관계를 정의합니다. 스케줄러는 이 코드를 바탕으로 Task를 생성합니다.
• Meta DB: 모든 Airflow 컴포넌트의 상태를 저장하는 중앙 데이터베이스입니다. 스케줄러는 Task를 생성하고(Create Task), Task의 상태를 설정하며(Set Task Status), 웹서버도 Task 상태를 조회하거나(Read DAG) 설정합니다.
• Executor: 스케줄러로부터 실행 명령을 받은 Task를 실제로 실행하는 '엔진'입니다. Task를 Queue에 넣는(Enqueue Task) 역할을 합니다.
• Queue: Executor가 Task를 넣으면, Worker가 이를 가져갈 때까지 Task가 대기하는 공간입니다.
• Worker: Queue에서 Task를 가져와서(Dequeue Task), 실제 명령(Run CLI Command)을 실행하는 주체입니다. 작업이 완료되면 Task의 최종 상태를 Meta DB에 다시 기록합니다(Set Task Status).
• Web Server: 사용자 인터페이스를 제공하는 컴포넌트입니다. Meta DB의 정보를 읽어와서 DAG 목록, Task 상태, 로그 등을 웹 화면에 표시합니다.

 

Airflow를 Kubernetes에서 운영하는 이유

Airflow를 Kubernetes에서 운영하면 서로의 장점을 극대화하여 훨씬 강력한 워크플로우 시스템을 구축할 수 있습니다.

• 자원 효율성 및 확장성: KubernetesExecutor를 사용하면, Task 실행이 필요할 때만 Pod를 동적으로 생성하고, 작업이 끝나면 자동으로 종료합니다. 유휴 상태로 대기하는 워커가 없어 비용을 절감하고, 필요에 따라 수많은 Task를 동시에 실행할 수 있는 확장성을 확보합니다.
• 완벽한 격리: 각 Task는 독립된 Pod에서 실행되므로, 한 Task의 오류가 다른 Task나 Airflow 시스템 전체에 영향을 미치지 않습니다.
• GitOps 기반의 배포: git-sync 사이드카 컨테이너를 활용하면, Git 리포지토리에 DAG 코드를 푸시하는 것만으로 Airflow에 자동으로 코드가 배포됩니다.
• 유연한 환경 구성: Task마다 다른 Docker 이미지, 파이썬 라이브러리, 환경 변수, 리소스(CPU, 메모리)를 지정할 수 있어 유연한 환경 구성이 가능합니다.

Kubernetes가 무엇인지 좀 더 알고싶으시면 아래 포스팅 참고해주세요.

https://tjlog-tistory.tistory.com/111

[Kubernetes] Kubernetes란 무엇인가?

 

 

KubernetesExecutor & KubernetesPodOperator

airflow운영방식을 본격적으로 알아보기 전에 먼저 KubernetestExecutor와 KubernetesPodOperator에 대해 알아보겠습니다.

 

KubernetesExecutor와 KubernetesPodOperator는 이름은 비슷하지만 역할이 완전히 다릅니다.

• KubernetesExecutor:
  • 역할: Airflow의 핵심 실행 엔진입니다.
  • 기능: 스케줄러로부터 실행 명령을 받은 Task를 직접 실행하는 대신, Kubernetes API를 호출하여 Task를 위한 전용 Pod를 생성합니다. Task가 끝나면 Pod를 삭제하는 역할을 담당합니다.
  • 아래 그림은 일반적인 오퍼레이터를 사용했을 때 Kubernetes Executor의 동작 원리입니다.

출처: https://engineering.linecorp.com/ko/blog/data-engineering-with-airflow-k8s-2

• KubernetesPodOperator:
  • 역할: DAG 내에 정의하는 Task의 한 종류입니다.
  • 기능: Python 코드를 실행하는 일반적인 PythonOperator와 달리, KubernetesPodOperator는 Task 실행을 위해 특정 Docker 이미지와 명령어를 지정하여 완전히 새로운 Pod를 생성하도록 지시하는 역할을 합니다.
  • 특징: 해당 워커 POD에서 개발자가 직접 정의한 컨테이너 이미지를 POD 형태로 또 다시 실행한다는 차이점이 있습니다. 이런 특징때문에 Airflow 환경에서 다양한 퍼블릭 클라우드에 접근할 수 있는 자유로운 환경이 마련됩니다.
    • Task가 필요로 하는 최소한의 환경을 자유롭게 만들어서 사용가능
    • 라이브러리 충돌과 의존성 문제를 회피할 수 있어 다양한 퍼블릭 클라우드에 접근할 수 있는 자유로운 환경이 마련
  • 아래 그림은 일반 오퍼레이터가 아닌 KubernetesPodOperator를 사용했을 때의 동작 원리입니다.

출처: https://engineering.linecorp.com/ko/blog/data-engineering-with-airflow-k8s-2

 

• KubernetesExecutor vs KubernetesPodOperator
  • 오케스트레이션: KubernetesExecutor가 'Task를 실행해 줘'라고 지시하는 역할(오케스트레이션)을 한다면,
  • 실제 동작 환경: KubernetesPodOperator는 '실제 컴퓨팅'을 위한 최적의 환경을 제공합니다.