K8s · Airflow 데이터 수집 플랫폼 운영 & 장애 대응
데이터 수집 파이프라인을 Kubernetes 위 Airflow로 운영하며, 80개+ 크롤러의 스케줄·동시 실행·자원을 한곳에서 관리하고 반복 장애를 근본 원인 분석으로 해소한 운영
1운영해야 했던 규모
인턴과 팀원이 만든 크롤러가 80개를 넘으면서, 각자 서버에서 실행하던 방식으로는 실행 시간과 자원 사용을 통제하기 어려웠습니다. 외부 API의 rate limit, DB 연결 수, CPU·메모리, 네트워크 대역폭을 한꺼번에 봐야 했습니다.
2공통 실행 환경을 만든 방식
Airflow를 공통 스케줄러로 두고 KubernetesExecutor로 작업마다 Pod를 띄웠습니다. 크롤러별 실행 시간과 동시 실행 수를 나눴고, Airflow pool과 재시도 정책으로 외부 API 호출이 한 번에 몰리지 않도록 했습니다.
- 수집 주기는 데이터의 시급성으로 정했습니다. 취약점 정보는 고객사가 빨리 대비할수록 가치가 있어 20분 주기로 수집하고 1시간 배치와 맞물려 약 1시간 안에 고객사까지 도달, 라이브러리 버전은 새로 나와도 기업이 바로 코드를 고치지 않으므로 4시간 주기로 완화
- 크롤러별 DAG 분리와 Git-Sync로 DAG 변경 이력 관리
- CPU·메모리 요구량에 따라 Pod 자원 할당
- rate limit에 맞춘 pool·backoff·재시도 정책
- IDC 자원이 부족할 때 WireGuard로 연결한 In-house 워커까지 사용
3운영 중 해결한 문제
Pod가 생성되지 않거나 Init 단계에서 멈출 때는 재시작 전에 원인부터 확인했습니다. 노드 inode와 DiskPressure, CoreDNS, kube-proxy, etcd 응답 지연, Git-Sync 권한과 재시도 설정을 순서대로 확인했습니다.
토큰과 키 만료는 사전 알림을 달아 장애가 난 뒤 교체하는 일을 줄였습니다. 특정 서버에 작업이 몰리는 경우에는 스케줄과 자원 요청량을 다시 조정했습니다.
4역할을 나눈 방식
각 크롤러의 수집 로직과 데이터 오류는 해당 담당자가 수정했습니다. 저는 여러 크롤러가 함께 쓰는 스케줄링, Kubernetes 자원, 네트워크, DB 연결, 모니터링을 설계하고 운영했습니다. 공통 장애가 생기면 원인을 찾아 담당자가 다시 같은 문제를 겪지 않도록 설정과 런북에 반영했습니다.