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

컬리는 관리형 Airflow를 Kubernetes로 옮겨 성능과 비용을 최적화하는 과정에서 스케줄러 CPU 급등, 워커 OOM, 실행 로그 누락과 태스크 지연을 겪었다. DAG 분석 주기를 조정하고, 메모리 request·limit과 Taint·Tolerations로 자원을 격리했으며, 로그 상태와 실행 흐름을 추적해 워커 수를 늘리는 방식으로 지연을 줄였다. 전환 후 관리형 서비스의 고정 비용이 Kubernetes 노드 비용으로 바뀌며 약 50% 감소했고, 로그 수집과 모니터링을 더 고도화해야 한다는 과제도 확인했다. 운영 환경을 직접 관리하면 시행착오가 따르지만, 원인을 추적하고 조정하는 경험이 Airflow와 Kubernetes에 대한 기술 역량을 높인다는 점을 배웠다.

• DAG 변경이 잦지 않다면 `min_file_process_interval`을 늘려 스케줄러의 파일 분석 빈도와 CPU 사용량을 낮출 수 있다.
• Kubernetes의 메모리 OOM은 컨테이너·kubelet·OS 수준에서 발생할 수 있으므로 사용량을 관찰해 적절한 request와 limit을 설정해야 한다.
• 컴포넌트별 자원 요구량이 다르면 네임스페이스 전체에 일괄 제한을 두기보다 Taint와 Tolerations로 노드를 분리하는 방식을 검토할 수 있다.
• Airflow 태스크가 `scheduled`에서 `queued`로 넘어가는 흐름을 알면 로그가 남지 않은 실행의 원인을 좁히는 데 도움이 된다.
• 워커의 동시 처리량이 부족할 때는 자원 증설뿐 아니라 워커 수를 늘리는 스케일 아웃도 선택지가 된다.