K8S Airflow 동작 방식과 pod 종류 확인하기

Airflow 자세히 확인하기

 

k8s 내에 있는 airflow pod 확인

구성 요소	역할	비유
Webserver	UI 제공	가게 카운터 및 메뉴판
Scheduler	작업 스케줄링	지배인 (주문서 작성)
PostgreSQL	메타데이터 저장소	가게 장부 (누가 언제 뭘 했나)
Redis	메시지 브로커	주문 대기표 (작업 순서 대기열)
Worker	실제 작업 수행	주방장 (Trino에 쿼리 던지기)
Flower	Celery 모니터링	주방 모니터링 CCTV
DB Migration	DB 스키마 업데이트	인테리어/공사팀 (기초 공사)

 

주요 Executor 방식 비교

구분	CeleryExecutor	KubernetesExecutor
동작 방식	일정한 수의 Worker Pod이 항상 떠서 대기함.	작업이 생길 때마다 새로운 Pod을 띄워서 실행함.
추가 부품	Redis(브로커), Flower(모니터링) 필수.	없음 (K8s API가 직접 관리).
확장성	Worker 개수를 미리 정해둬야 함 (고정적).	작업량에 따라 무한대로 Pod이 생김 (유연함).
자원 효율	일이 없어도 Worker가 자원을 점유함.	일이 없을 땐 자원을 하나도 안 씀.
격리성	한 Worker에서 여러 작업이 돌아 충돌 위험 있음.	작업마다 독립된 Pod이라 완벽히 격리됨.

 

2. 장단점 상세 분석 (엔지니어 관점)

CeleryExecutor (현재 방식)

• 장점:
  • 응답 속도가 빠름: 워커가 이미 떠 있어서 작업을 던지면 즉시 실행돼.
  • 부하 예측 가능: 워커 개수를 고정해두니 인프라 전체 자원 소모가 안정적이야.
• 단점:
  • 낭비되는 자원: 밤에 분석 작업이 없어도 워커 Pod들은 계속 떠서 월급(CPU/Mem)을 받아가.
  • 관리 포인트 증가: Redis랑 Flower까지 네가 관리해야 할 Pod이 늘어나지.

KubernetesExecutor

• 장점:
  • 극강의 효율: 일이 있을 때만 Pod이 뜨니까 클러스터 자원을 아주 알뜰하게 써.
  • 환경 자유도: 작업 A는 Python 3.8, 작업 B는 Python 3.10 이미지로 각각 다르게 띄울 수 있어. (이미지 태그를 다르게 설정 가능)
• 단점:
  • 기동 지연 (Overhead): 작업마다 Pod을 새로 만드니, 실제 코드가 돌기 전까지 5~10초 정도 준비 시간이 걸려.
  • K8s 부하: 작업이 수천 개면 K8s API 서버가 Pod 생성하느라 정신없어질 수 있어.

---

3. 어떤 환경에서 뭐가 더 좋을까?

CeleryExecutor가 유리한 경우

• "빨리빨리"가 중요한 환경: 1~2분 안에 끝나는 짧은 작업이 엄청나게 많이 몰아칠 때 좋아.
• 자원이 넉넉한 환경: 회사 내부 클러스터(L.Cloud 등) 자원이 여유로워서 워커 몇 개 상시 띄워두는 게 안 아까울 때.
• 이미 익숙한 운영: 지금처럼 Redis, Flower 구조가 이미 잡혀 있고 트러블슈팅이 익숙할 때.

KubernetesExecutor가 유리한 경우

• "자원 아끼기"가 최우선인 경우: 작업이 간헐적으로(예: 새벽에만 왕창) 돌 때.
• 작업마다 사양이 다를 때: 어떤 작업은 메모리 32GB가 필요하고, 어떤 건 1GB면 될 때 (Pod마다 Resource 설정을 다르게 줄 수 있음).
• 인프라 관리 최소화: Redis 같은 외부 브로커 관리가 귀찮고 K8s 기능만으로 끝내고 싶을 때.