Airflow 워크플로우 플랫폼 구축

배경

팀원이 한 명씩 퇴사하여 2025년 초 데이터 파이프라인 관리 인력이 저 혼자가 되었습니다. 기존 인프라는 AWS Glue, Mac Studio, EC2, DW MySQL 4곳에 분산되어 있었고, 특정 Job이 실패했을 때 4곳을 모두 뒤져봐야 했습니다.

혼자서 유지하려면 관리 포인트를 하나로 통합하는 것이 필수였습니다.

왜 직접 구축했나

2022년에 팀 차원에서 Airflow를 검토했으나 Python 역량 부족으로 포기한 적이 있었습니다. 이후 개인적으로 터미널 환경을 깊이 익혔습니다. Neovim으로 LSP, 린팅, 포매팅, 디버깅을 배우면서 Airflow를 직접 구축할 수 있다는 자신감을 갖게 되었습니다.

관리형 서비스(MWAA) 대신 EC2에 Docker Compose로 직접 구축하는 방식을 선택했습니다. 인프라를 직접 통제할 수 있어야 문제 발생 시 빠르게 대응할 수 있기 때문입니다.

마이그레이션 전략

마이그레이션은 소스코드를 건드리지 않는 것을 원칙으로 삼았습니다. 기존 함수를 그대로 task화하여 1 DAG 1 task 형태로 먼저 옮기는 전략을 취했습니다.

• 4월 — Glue Job 마이그레이션
• 6월 — Mac Studio 스크립트 마이그레이션
• 9월 — 전체 레포지토리 통합 완료, 총 478개 DAG

Slave2 → S3 덤프 작업은 TaskFlow 동적 태스크 매핑으로 병렬 처리하여 1시간 걸리던 작업을 5~10분으로 단축했습니다.

메모리 누수 해결

Airflow 3 메이저 업그레이드 후 2일마다 메모리가 100%에 도달하며 서버가 다운되는 문제가 발생했습니다.

처음에는 자체 코드 문제로 판단하여 대규모 리팩토링을 진행했으나 해결되지 않았습니다. 이후 공식 docker-compose 구성을 분석하여 근본 원인을 찾았습니다.

• 불필요한 서비스(Redis, Worker, Flower) 제거
• 로그를 S3 원격 저장으로 전환하여 디스크 부하 제거
• Scheduler가 Worker를 대체하도록 아키텍처 재설계

통합 후 아키텍처

성과

• 4곳 분산 인프라 → 단일 Airflow 플랫폼으로 통합
• 총 478개 DAG 운영
• EC2 인스턴스: r7i(메모리 최적화) → c7i(컴퓨팅 최적화)로 전환
• CPU 사용률: 90~100% → 평균 10%
• RAM 사용률: 2일마다 100% → 평균 22%
• 장애 복구: 재시작 1시간 → 5분
• AWS Glue 제거로 연 400만원 비용 절감