Airflow를 쿠버네티스에 운영하기 위한 고민

회사에서 DataOps를 위해 Airflow를 구성하고, 안정적인 운영 환경을 제공해야 하는 태스크가 있었다.
요즘 같은 세상에 컨테이너 혹은 Kubernetes 차트 등을 이용하여 편하게 배포할 수 있지만, DevOps로써는 보다 많은 고민이 필요했고, 본 글은 Airflow 운영 3개월차가 작성하는 다른 누군가에게 도움이 되기를 기대하며, 또 미래의 내가 찾아 볼 수 있는 하나의 기록으로써 남기는 글이다.

Managed Workflow Apache Airflow vs EKS

• SaaS 형태의 Apache Airflow를 이용하는 것은 실질적으로 Apache Airflow를 모르는 상태에서 운영하게 될것으로 예상했다.
  • 놀랍게도 이는 SaaS를 이용하는 대다수의 이유기도 하지만, 우리 회사의 경우 데이터 사업 회사기 때문에 ETL 파이프라인을 잘 모르는 상태로 배포하는 것은… (이하생략)
• 또한 MWAA에 대해 찾아보니, 커스터마이징이 생각보다 까다롭고 문제가 발생했을 때 추적이 어렵다는 후기들을 보고 온프레미스로 배포하기로 결정했다.
  • 그리고 비용…😂

Airflow의 Executor를 무엇으로 선택하는게 좋을까?

• Celery Executor vs Kubernetes Executor
• Celery Executor의 경우 등록된 워커의 리소스를 이용하여 워크플로우를 처리한다. 이 경우 “워커 관리”라는 관리 지점이 생기고 워커의 자원에 따라 태스크 실행이 제한될 수 있다.
  • N 대의 워커 운용
  • 분산된 워커 환경에 대한 관리
  • 워커 failover
  • concurrency 제한
• 이러한 이유로 인해 Kubernetes Executor를 선택하여 DAG를 처리하는 방안을 선택했다.
  • DAG 실행 시 각 Task에 대한 Pod가 생성되기 때문에,, 워커의 실패가 없다.
  • Cluster Autorscaler (Karpenter)를 통한 능동적인 워커 자원 관리
  • Airflow 환경 설정 = concurrency 설정 → 워커로 부터 자유롭다.

Kubernetes Executor, 조금 더 섬세하고 자유롭게 운영하고 싶은데..

• Kubernetes Executor는 Pod Template을 통해 Task를 실행할 Pod의 스펙을 정할 수 있다. 이를 통해 목적별, 작업별, 심지어 그룹별로 Pod가 실행될 템플릿을 미리 정하고, executor_config을 통해 template을 지정하여 사용할 수 있다.
  • 이에 따라서 Spot Instance, GPU, CPU, CPU Architecture, 그리고 자원량 까지 정할 수 있다.
  • Pod Template에 대해 Airflow Pool을 지정한다면, 더 멋진 관리가 가능하다.
• Airflow를 Kubernetes와 이용한다면 Kubernetes Pod Operator라는 것을 접하게 되는데, 나는 사용하지 않기로 했다.
  1. Kubernetes Pod Operator의 “격리된 실행 환경”을 보장하라는 철학에 따라 Kubernetes Executor의 작업을 처리하기 위해 생성된 Task Pod와는 별개로… 또 하나의 Pod가 생성되어 처리된다. 즉.. 하나의 Task에 두 개의 Pod가 생성된다. 이는 불필요한 자원낭비로 이어질 수 있다.
  2. 보기도 힘들고.. 심지어 둘 간의 의존성이 혹시라도 끊어진다면, 작업의 유실로 이어지기 때문에.. Kubernetes Executor만 사용하기로 했다.
• 그렇다고 KPO 자체에 의문을 갖는것은 아니다. 일반화 할순 없지만, 분명 더욱 세분화 해야 하는 작업이 있을것이고 이에 따라 따른 세밀한 제어가 필요할 때 사용할 수 있다.