[Kubernetes] Airflow의 웹서버 개념

Airflow WebServer

Apache Airflow를 쿠버네티스(Kubernetes) 환경에서 운영할 때, Airflow WebServer는 Airflow 시스템의 UI를 제공하는 핵심 구성 요소임.

사용자는 WebServer를 통해 DAG(Directed Acyclic Graph) 편집, 모니터링, 실행 상태 확인, 로그 확인, 설정 변경 등을 수행할 수 있음.

특히 쿠버네티스에서 Airflow를 운영할 때에는 WebServer 역시 컨테이너로 배포되어 동작하며, Helm 차트 등을 활용해 스케일링, 보안, 네트워킹 등 다양한 요소를 관리할 수 있음.

 

Airflow 컴포넌트 개요

1. Scheduler

DAG을 해석하고, 태스크를 스케줄링함.

 

2. Worker

스케줄링된 태스크(작업)을 실행함. (CeleryExecutor, KubernetesExecutor 등)

 

3. WebServer

Flask + Gunicorn 기반의 웹 UI를 제공함.

 

4. Metadata DB

Airflow의 모든 메타데이터(DAG 실행 이력, 태스크 상태 등)를 저장하는 데이터베이스.

 

5. (Optional) Flower

CeleryExecutor에서 Worker 상태 모니터링을 제공하는 UI.

 

쿠버네티스 상에서 운영할 때는 보통 Helm 차트(공식 Airflow Chart, Bitnami Chart, Astronomer Chart 등)를 사용하거나, 직접 쿠버네티스 매니페스트를 작성하여 Deployment, StatefulSet 등을 구성할 수 있음.

 

Airflow WebServer의 역할과 특징

1. UI 제공

Airflow WebServer는 사용자가 DAG을 확인·관리할 수 있는 웹 인터페이스를 제공함.

DAG 그래프 뷰, 트리 뷰, Gantt 차트 등 다양한 시각화 툴을 통해 작업 상태를 모니터링할 수 있음.

 

2. Flask + Gunicorn 구조

Airflow WebServer는 Flask 기반 애플리케이션으로 구현되어 있음.

Gunicorn을 통해 멀티워크(multi-worker) 프로세스로 동작함.

Gunicorn 설정(워크 프로세스 수, 워커 타입, 타임아웃 등)을 통해 WebServer의 동시성(Concurrency)을 조절할 수 있음.

 

3. Meta DB 연동

WebServer는 Metadata DB(예: PostgreSQL, MySQL 등)와 통신하여 DAG 상태, 태스크 로그 위치, 실행 이력 등을 조회함.

DAG이 메타DB에 올바르게 등록되어 있어야 WebServer에서 DAG을 올바르게 확인할 수 있음.

 

4. DAG 파일 로딩

WebServer는 DAG 디렉터리에 배포된 Python 파일들을 통해 DAG을 파싱한 후, 이를 DB에 등록하고 UI에 반영함.

쿠버네티스 환경에서는 NFS, Git-sync, S3, GCS, Helm Chart의 Volume Mount 등 다양한 방식으로 DAG 파일을 WebServer/Scheduler/Worker에게 공유할 수 있음.

 

5. Auth & RBAC

Airflow 1.10.0 이후로 Role-Based Access Control(RBAC)이 기본 제공되며, WebServer에서 사용자 인증, 권한 부여를 관리함.

OAuth, LDAP, Google, GitHub 등 다양한 인증 방식을 플러그인 형태로 연동할 수 있으며, 쿠버네티스 환경에서는 Secret, ConfigMap 등을 통해 인증 정보를 안전하게 주입할 수 있음.

 

Kubernetes에서 WebServer 배포 - Helm 활용

1. Deployment

WebServer Pod를 구성하는 기본 리소스임.

replicaCount를 통해 WebServer의 복제(스케일)를 조절할 수 있음.

 

2. Service

WebServer Pod에 대한 서비스를 노출함.

ClusterIP, NodePort, LoadBalancer 중 어떤 타입을 쓸지 결정함.

 

3. Ingress

Kubernetes Ingress 리소스를 사용해 도메인(URL)과 TLS 인증서(HTTPS)를 설정함.

 

Kubernetes에서 WebServer 배포 - StatefulSet vs Deployment

일반적으로 Airflow WebServer는 상태를 내부적으로 많이 갖지 않고(메타정보는 DB에 저장), 스케일아웃이 자유로우므로 Deployment 리소스를 활용함.

DAG 파일 공유(혹은 Git-sync) 등 때문에 WebServer Pod에 Persistent Volume이 필요한 경우가 있으나, WebServer에 일관된 스토리지 세션이 반드시 필요하지는 않음.

세션은 DB, Redis 등 외부 세션 스토어를 사용할 수 있음.

 

WebServer 설정 및 튜닝 포인트

1. Gunicorn 워커 수 및 동시성

AIRFLOW__WEBSERVER__WORKERS, AIRFLOW__WEBSERVER__WORKER_CLASS 등의 설정을 통해 동시 접속자를 처리할 수 있는 워커 수를 조절함.

너무 적으면 요청 처리가 느려지고, 너무 많으면 CPU 자원을 과도하게 소모할 수 있음.

CPU 및 메모리 리소스를 고려하여 조정함.

 

2. 워커 타임아웃(timeouts)

DAG 파싱 시간이 오래 걸리는 경우나, 로그 조회 시 응답이 지연되는 경우에 대비하여 Gunicorn timeout 설정을 적절히 늘리는 것이 좋음.

web_server_worker_timeout 설정 등을 통해 워커 타임아웃을 조절할 수 있음.

 

3. DAG 파싱 성능

DAG 로딩 및 파싱 시간은 WebServer 응답 속도에 영향을 미침.

DAG이 많거나 DAG 파일이 복잡하면 파싱 시간이 늘어날 수 있음.

scheduler와 webserver 모두에서 load_examples=False(불필요 예제 DAG 로딩 비활성화), DAG 파티셔닝, 파일 구조 단순화, DAG 수 줄이기 등의 방법을 쓰면 파싱 부담이 줄어듬.

 

4. 리소스 제한(쿼터) 및 요청(Requests/Limits)

쿠버네티스 Pod에 대해 CPU, 메모리 한도(Limits)와 요청(Requests)를 적절히 설정함.

Airflow WebServer가 DAG 파싱 시 CPU 사용량이 급등할 수 있으므로, 충분한 CPU Limit을 배정하거나 HPA(Horizontal Pod Autoscaler)로 자동 확장을 고려할 수 있음.

 

5. 로그 저장 및 보안

WebServer 로그는 컨테이너 stdout으로 출력되므로, 쿠버네티스 로깅 파이프라인(예: FluentBit, Fluentd, ELK 등)과 연계해 중앙화할 수 있음.

태스크 로그(task logs)는 S3, GCS, NFS, PVC 등에 저장하는 방식을 많이 사용함.

DAG 모니터링 시 WebServer가 해당 로깅 스토리지로부터 로그를 읽어와 UI에 표시함.

 

인증 및 RBAC 운영

1. 기본 보안 고려

WebServer는 DAG이나 운영 상태 등에 대한 민감한 정보를 포함하므로, HTTPS(SSL/TLS) 종단을 반드시 적용하고, 외부 접근을 제어해야 함.

쿠버네티스 Ingress를 이용해 TLS Termination을 설정하거나, Istio/NGINX 등 외부 LB를 통해 HTTPS를 구현할 수 있음.

 

2. 사용자 인증(Authentication)

Airflow는 기본적으로 airflow.contrib.auth.backends.password_auth와 RBAC 모델을 제공함.

기업 환경에서는 LDAP, OAuth, SAML, GitHub, Google, Keycloak 등을 통해 Single-Sign-On(SSO)을 구성하기도 함.

쿠버네티스 Secret, ConfigMap, Environment 변수 등을 이용해 인증 정보를 안전하게 주입함.

 

3. Role-Based Access Control(RBAC)

Airflow UI의 각 메뉴(예: DAG 수정, 태스크 트리 보기, 로그 보기)에 대해 권한을 세분화하여 부여할 수 있음.

Admin, Op, User, Viewer 등 역할(Role)을 기본 제공하며, 필요한 경우 커스텀 역할을 만들어 권한 체계를 정교하게 관리할 수 있음.

 

스케일링 전략

1. 수직 확장(Vertical Scaling)

WebServer Pod에 할당된 리소스(CPU, 메모리)를 늘려서 더 많은 동시 사용자를 처리할 수 있게 함.

DAG 파싱 부하가 크게 걸리는 경우, 리소스를 늘려도 응답 지연이 발생할 수 있으니 DAG 구조 최적화도 함께 진행함.

 

2. 수평 확장(Horizontal Scaling)

replicaCount(Deployment)나 HPA(Horizontal Pod Autoscaler)를 사용해 WebServer Pod를 복수 개로 띄움.

Airflow 웹 요청이 인입될 때, 쿠버네티스 Service가 여러 WebServer Pod로 로드밸런싱함.

DAG 상태 등 메타 정보는 DB에 저장되므로, WebServer 간에 세션 정보 공유 문제가 비교적 적음.

단, 각 WebServer 인스턴스의 DAG 파싱 로드가 중복으로 발생할 수 있어, 대규모 환경에서는 DAG 파싱 효율화 방안이 필요함.

 

운영 및 모니터링

1. 메트릭 수집

Airflow와 Gunicorn에서 제공하는 메트릭(CPU, 메모리, 요청 수, 응답 시간 등)을 Prometheus, StatsD 등을 통해 수집 및 분석함.

Airflow 2.x부터는 Prometheus metrics를 쉽게 내보낼 수 있는 구성이 가능하며, 쿠버네티스 환경에서는 Sidecar Exporter 등을 쓸 수 있음.

 

2. 로그 모니터링

WebServer의 stdout 로그(접속 로그, 에러 로그 등)는 쿠버네티스의 중앙 로깅 솔루션(ELK, Loki 등)과 연동해 보관·분석할 수 있음.

태스크 실행 로그는 Airflow가 별도로 설정한 로그 스토리지(S3, GCS, PVC)에 저장하고, WebServer UI에서 이를 조회함.

 

3. Health Check & Auto Restart

Gunicorn 프로세스가 응답하지 않는 경우를 대비해, 쿠버네티스 livenessProbe와 readinessProbe를 설정함.

WebServer Pod가 임계 상태(예: OOM, CPU 스로틀링)에 도달하면 쿠버네티스가 자동으로 Pod를 재시작해 가용성을 유지함.

 

4. 업데이트/배포 전략

Rolling Update, Blue-Green Deployment 등을 통해 WebServer 버전을 업그레이드하면서도 UI 다운타임을 최소화할 수 있음.

DAG 파일 업데이트도 GitOps 방식을 사용하면, Git push → CI/CD → 쿠버네티스 배포 파이프라인으로 자동 적용이 가능함.

 

Airflow WebServer 정리

1. Deployment 및 Service 설계

Helm 차트 또는 직접 매니페스트를 작성하여 WebServer Pod를 안정적으로 운영하고, Ingress와 연계해 HTTPS/TLS를 구성해야 함.

 

2. 리소스 설정 및 스케일링

Gunicorn 워커 설정, CPU/메모리 Limit, HPA(수평 확장) 적용 등을 통해 부하 상황에 대응해야 함.

 

3. DAG 파싱 성능 최적화

DAG 파일 개수와 파싱 복잡도에 따라 WebServer 응답 시간이 달라짐.

DAG 최적화와 Serialization, 읽기 전용 볼륨 공유 등을 검토함.

 

4. 보안 및 RBAC

민감한 작업을 다루는 만큼, WebServer 접근에 대한 인증(SSO, LDAP, OAuth 등)과 권한(Role) 관리를 체계적으로 설정해야 함.

 

5. 모니터링 및 로깅

Prometheus/Grafana, Elasticsearch/Kibana(ELK), Loki/Grafana 등과 연동하여 WebServer 상태와 로그를 중앙 관리할 수 있어야 함.

 

Airflow WebServer는 DAG과 워크플로 관리를 위한 사용자 인터페이스이자, Airflow 시스템의 가시성을 제공하는 핵심 요소임.

쿠버네티스와의 통합 운영 시에는 Helm, Ingress, Deployment, RBAC 등 쿠버네티스 표준 리소스 및 구성 요소들을 적극적으로 활용해야 함.

DAG 파싱 최적화, 보안, 모니터링 등을 체계적으로 설정하여 안정적이고 확장 가능한 데이터 파이프라인 환경을 구축할 수 있음.