서버리스에서 쿠버네티스로 - Airflow 운영 경험기

Context

데이터 파이프라인 Airflow를 관리형 서비스(AWS MWAA, GCP Composer)에서 운영하다가 기술 성숙도 향상과 비용 최적화를 위해 Kubernetes 환경으로 전환했습니다. 전환 과정에서 예상하지 못한 3가지 운영 이슈가 발생했습니다.

Technical Solution

• 스케줄러 CPU 과부하 해결: GitSync를 통해 DAG 추가 시 스케줄러의 파일 I/O 부하 증가(신규 배포: 0.25→0.45 core +80%, 개발용: 0.4→2.7 core +675%) → min_file_process_interval 파라미터를 증가시켜 DAG 파일 구문분석 주기를 늘려 파일 I/O 빈도 감소
• 워커 OOM 문제 해결: Kubernetes 오버커밋 환경에서 메모리 압축 불가능으로 인한 Container/Kubelet/OS 레벨 OOM 발생 → 워커의 CPU와 메모리 자원에 request(요청) 및 limit(제한) 설정을 통해 노드 할당 시 자원 충분성 사전 검증 및 Container 단계 OOM 조기 발동
• 워커 동시 처리 능력 증대: DAG 수 증가로 인한 태스크 큐 적체 및 scheduled 상태 장시간 대기 → 워커 수를 1대에서 2대로 확장하는 스케일 아웃 방식 채택
• Helm을 통한 Kubernetes 배포: Metadata DB, Redis 큐, 스케줄러, 트리거, 워커 등 Airflow 컴포넌트를 Kubernetes Pod 기반 아키텍처로 구성
• GitSync를 통한 DAG 버전 관리: 로컬 디렉토리 대신 Git 저장소에서 DAG 파일을 관리하여 다중 사용자 협업 편의성 증대

Impact

• 관리형 서비스 대비 Kubernetes 운영으로 고정 비용 50% 감소
• 스케줄러 CPU 사용량 감소(구체적 수치는 min_file_process_interval 조정 후 다시 정상 범위로 회복)
• 워커 확장 후 작업 지연 현상 확연히 감소

Key Takeaway

Kubernetes 환경에서 Airflow 운영 시 단순히 컨테이너화하는 것을 넘어 메모리 격리(request/limit), 파일 I/O 동작 주기(min_file_process_interval), 워커 동시성(worker_concurrency) 등 애플리케이션 계층과 인프라 계층의 상호작용을 이해하고 튜닝해야 안정적인 운영이 가능합니다. 특히 메모리는 압축 불가능한 자원이므로 사전 예방형 자원 제한 정책 수립이 필수입니다.