K8s · Airflow 데이터 수집 플랫폼 운영 & 장애 대응

1배경

데이터 수집 파이프라인(크롤러/DAG)은 초기 Docker Compose 기반으로 단일 호스트에서 운영되어, 확장성·격리·복구성에 한계가 있었습니다. 수집 규모가 커지면서 Task 격리, DAG 형상 관리, 자원 분리가 필요해졌습니다.

• 한 Task의 자원 사용·실패가 다른 Task로 번지는 격리 부재
• DAG 배포가 수동이라 형상·이력 관리가 어려운 운영 부담
• 수집 파이프라인이 멈추면 RAW 데이터·다운스트림 전체가 영향받는 가용성 리스크

2아키텍처

2024-08, Airflow 운영을 Docker Compose → Kubernetes Helm Chart 기반으로 전환했습니다. KubernetesExecutor로 Task마다 독립 Pod를 띄워 격리하고, Git-Sync 사이드카로 DAG를 코드로 동기화(DAG-as-Code)했으며, 메타데이터는 PostgreSQL로 분리했습니다.

나아가 컨트롤플레인·워커 노드, 스토리지 클래스·Ingress·cert-manager를 포함한 K8s 클러스터를 직접 운영하고, 하이브리드(WireGuard + NAT) 구성으로 클러스터를 확장·트러블슈팅했습니다.

3장애 대응 (근본 원인 분석)

운영 중 발생한 주요 장애를 직접 원인 분석하고 복구했습니다.

• CoreDNS / Airflow scheduler CrashLoopBackOff — git-sync ↔ scheduler 통신 마비로 인한 스케줄러 다운을 복구
• 노드 Inode 고갈 · DiskPressure — 디스크 압박으로 인한 Pod Eviction 원인 분석 및 해소
• Airflow Task 실패 — etcd 응답 지연이 원인으로 확인되어 etcd HA 도입을 검토
• gitSshKey 장애 · 권한 만료 · 디스크 접근 실패 — DAG 동기화·실행 경로 복구

4정기 운영 & 임팩트

크롤러/DAG 일상 운영과 함께, 수집 RAW 데이터 및 DB 백업 경로를 관리했습니다.

5역할

데이터 엔지니어 · 인프라 운영으로서 Airflow 플랫폼의 K8s 전환 → 클러스터 운영 → 장애 대응 → 안정화를 담당했습니다. 단순 복구에 그치지 않고 CrashLoopBackOff·DiskPressure·etcd 지연 같은 문제를 근본 원인까지 추적해 고가용성을 개선했습니다.

관련: 같은 시기 데이터파트의 DB 플랫폼 고도화(업그레이드·아키텍처 분리)는 별도 항목으로 정리.