K8s · Airflow 데이터 수집 플랫폼 운영·장애 대응
여러 크롤러가 함께 쓰는 스케줄, 자원, 네트워크와 장애 대응 경로를 관리했습니다.
작업 요약
80개+ 크롤러 공통 실행 환경 운영
80개가 넘는 크롤러를 함께 실행해야 했습니다
인턴과 팀원이 만든 크롤러가 80개를 넘으면서, 각자 서버에서 실행하던 방식으로는 실행 시간과 자원 사용을 통제하기 어려웠습니다. 외부 API의 rate limit, DB 연결 수, CPU·메모리, 네트워크 대역폭을 한꺼번에 봐야 했습니다.
공통 실행 환경을 만든 방식
Airflow를 공통 스케줄러로 두고 KubernetesExecutor로 작업마다 Pod를 띄웠습니다. 크롤러별 실행 시간과 동시 실행 수를 나눴고, Airflow pool과 재시도 정책으로 외부 API 호출이 한 번에 몰리지 않도록 했습니다.
- 수집 주기는 데이터가 얼마나 빨리 필요한지에 따라 정했습니다. 취약점 정보는 고객사가 빠르게 대응해야 하므로 20분 주기로 수집하고 1시간 배치와 맞물려 약 1시간 안에 고객사까지 도달, 라이브러리 버전은 새로 나와도 기업이 바로 코드를 고치지 않으므로 4시간 주기로 완화
- 크롤러별 DAG 분리와 Git-Sync로 DAG 변경 이력 관리
- CPU·메모리 요구량에 따라 Pod 자원 할당
- rate limit에 맞춘 pool·backoff·재시도 정책
- IDC 자원이 부족할 때 WireGuard로 연결한 In-house 워커까지 사용
운영 중 해결한 문제
2026년 9월에는 DAG의 내부 식별자를 유지한 채 표시명을 수집 대상별로 정리했습니다. 스케줄러에서 대상 DAG 21개의 표시명과 import 오류가 없음을 확인했습니다. 파일을 지워도 Airflow 메타데이터에 남는 작업은 별도로 정리해 코드 목록과 운영 화면이 어긋나지 않도록 했습니다. 원인은 git-sync worktree 경로가 커밋마다 바뀌어 삭제 판정이 어긋나는 것이었고, 남아 있던 DAG 20건을 지워 활성 DAG 92개와 파일 92개를 맞췄습니다.
같은 달에 DAG 실패 알림을 카카오워크에서 Slack으로 옮겼습니다. DAG 53개가 쓰는 공통 watcher 한 곳만 고쳤고, 원인 줄은 마지막 줄 대신 첫 예외 줄에서 뽑습니다. Airflow가 원래 예외를 감싸 다시 던지기 때문에 실제 실패 6건 중 4건에서 두 줄이 달랐습니다. 밖에서 돌던 수집기를 이 실행 환경으로 옮긴 과정은 별도 항목에 적었습니다.
Pod가 생성되지 않거나 Init 단계에서 멈출 때는 재시작 전에 원인부터 확인했습니다. 노드 inode와 DiskPressure, CoreDNS, kube-proxy, etcd 응답 지연, Git-Sync 권한과 재시도 설정을 순서대로 확인했습니다.
토큰과 키 만료는 사전 알림을 달아 장애가 난 뒤 교체하는 일을 줄였습니다. 특정 서버에 작업이 몰리는 경우에는 스케줄과 자원 요청량을 다시 조정했습니다.
역할을 나눈 방식
각 크롤러의 수집 로직과 데이터 오류는 해당 담당자가 수정했습니다. 저는 여러 크롤러가 함께 쓰는 스케줄링, Kubernetes 자원, 네트워크, DB 연결, 모니터링을 설계하고 운영했습니다. 공통 장애가 생기면 원인을 찾아 담당자가 다시 같은 문제를 겪지 않도록 설정과 런북에 반영했습니다.