대규모 크롤러 운영 안정성

크롤러는 만들기보다 굴리기가 어렵습니다. 데모에서 잘 돌던 수집기가 운영에 들어가면 대상 사이트 점검, 일시적 네트워크 오류, 예고 없는 개편, 봇 차단까지 온갖 이유로 흔들립니다. 소스가 서너 개면 사람이 챙기면 되지만 정책 공고 파이프라인처럼 소스가 109개면 안정성은 코드가 아니라 구조로 확보해야 합니다. 이 글은 그 구조, 즉 크롤러 운영 안정 설계를 다섯 층으로 정리합니다.

1층: 실패는 소스 단위로 격리한다

가장 먼저 정할 것은 실패의 반경입니다. 우리는 소스마다 실행을 격리해 한 소스의 예외가 다른 소스의 수집을 절대 멈추지 못하게 했습니다. 어떤 구청 홈페이지가 개편으로 깨져도 나머지 108개는 그날 정상 수집됩니다. 레코드 수준에서도 마찬가지로, 한 건의 파싱 실패는 그 건의 실패로만 기록됩니다.

격리가 없으면 어떻게 될까요. 수집 루프 중간에서 예외 하나가 전체 배치를 죽이고 아침에 보면 그날 데이터가 통째로 비어 있습니다. 원인은 사소한 사이트 하나인데 피해는 전체가 됩니다. 격리는 안정성 설계에서 가장 싸고 효과가 큰 투자입니다.

2층: 재시도는 물러서면서 한다

일시 장애는 크롤러 일상입니다. 대응은 지수 백오프 재시도입니다. 첫 실패엔 짧게 기다렸다가 실패가 반복될수록 대기 시간을 배로 늘리며 최대 6회까지 시도합니다. 대기 시간에는 무작위 편차(지터)를 섞어 여러 요청이 같은 순간에 몰려 재충돌하는 것을 막습니다. 쿼터 초과처럼 원인이 명확한 응답에는 별도의 더 긴 백오프를 적용합니다.

핵심은 물러서면서 재시도한다는 점입니다. 실패한 서버를 짧은 간격으로 두드리는 것은 장애를 연장시키고 차단을 부릅니다.

3층: 속도 제한은 매너이자 보험이다

우리는 요청 속도를 분당 30회로 제한했습니다. 수집 대상은 공개된 공고 페이지이고 이 속도는 사람이 열람하는 것보다 완만한 수준입니다. 속도 제한은 상대 서버에 대한 매너인 동시에, 트래픽 이상으로 차단 목록에 오르는 것을 막는 보험입니다. 장기 운영 크롤러일수록 "빨리 긁는 것"보다 "오래 긁을 수 있는 것"이 가치입니다.

4층: 차단은 감지하고, 수단을 바꿔 잇는다

방어를 다 해도 차단은 발생합니다. 우리는 차단 응답의 패턴(접근 거부 코드, 보안 문자 페이지 등)을 자동 감지해 일반 수집기가 막힌 소스는 클라우드 크롤러 경유로 전환해 수집을 이어가게 했습니다. 전환은 소스 단위로 일어나고 전환 이력도 기록됩니다.

여기에는 지켜야 할 선이 있습니다. 우리가 수집하는 것은 누구나 열람할 수 있는 공개 공고입니다. 속도 제한과 백오프로 서버 부담을 관리하고 로그인 뒤의 비공개 데이터는 다루지 않습니다. 차단 대응은 그 전제 안에서 수집 연속성을 지키는 장치입니다.

5층: 실행마다 감사 로그를 남긴다

안정성의 마지막 층은 관측입니다. 모든 실행은 소스별로 성공·부분 성공·실패가 감사 테이블에 기록되고 수집 전후의 행 수 변화도 함께 남습니다. "어제까지 하루 수백 건 들어오던 소스가 오늘 0건"처럼 조용한 고장은 에러 로그에는 안 잡히지만 행 수 델타에는 드러납니다. 운영자는 대시보드에서 소스 그리드와 실패 로그를 확인하므로, 이상 징후를 발견하는 데 DB 쿼리가 필요 없습니다.

크롤러 운영 안정 설계 한눈에 보기

다섯 층을 한 표로 정리하면 이렇습니다.

이 다섯 층은 게시판 크롤러든 API 수집이든 동일하게 적용됩니다. 수집 코드를 유형화해 유지보수를 줄이는 설계는 게시판 크롤러 템플릿 설계에서, 공공 API 특유의 함정은 공공데이터 API 연동 함정에서 다룹니다. 전체 시스템은 공공데이터 크롤링 자동화 사례에서 볼 수 있고 같은 원칙으로 운영한 다른 사례로 유통 가격·재고 모니터링이 있습니다.

자주 묻는 질문

크롤러 운영 안정성에서 가장 먼저 챙길 것은 무엇인가요?

실패 격리입니다. 소스 단위로 실행을 분리해 한 곳의 장애가 전체 수집을 멈추지 못하게 하는 것이 비용 대비 효과가 가장 큽니다. 그다음이 지수 백오프 재시도와 속도 제한, 마지막이 감사 로그와 델타 모니터링입니다.

크롤링 차단을 당하면 어떻게 대응하나요?

차단은 예방이 먼저입니다. 요청 속도를 제한하고 실패 시 물러서는 재시도를 쓰면 대부분의 차단은 일어나지 않습니다. 그래도 막히는 소스는 차단 패턴을 자동 감지해 클라우드 크롤러 경유로 전환하는 폴백을 두되, 공개 데이터와 완만한 수집 속도라는 전제를 지킵니다.

크롤러가 조용히 고장 나는 경우는 어떻게 잡나요?

에러 없이 수집량만 줄어드는 고장은 행 수 델타로 잡습니다. 실행마다 수집 전후의 레코드 수를 기록하고 소스별 추이를 대시보드에 노출하면, "며칠째 0건"인 소스가 바로 드러납니다. 에러 로그만 보는 모니터링은 이 유형을 놓칩니다.

수집 주기는 어떻게 정하나요?

데이터의 신선도 요구와 대상 서버에 대한 매너 사이에서 정합니다. 공고류는 하루 한 번 새벽 배치면 충분한 경우가 대부분입니다. 주기를 줄일수록 차단 위험과 운영 비용이 함께 올라갑니다. 짧은 주기는 정말 필요한 소스에만 예외로 적용하는 것이 좋습니다.

사이트가 개편되면 크롤러 수리는 얼마나 걸리나요?

구조에 따라 다르지만 수집 로직을 템플릿으로 유형화하고 사이트별 차이를 설정으로 분리해 두면 대부분 설정 수정 수준으로 끝납니다. 격리 덕에 개편된 소스 외에는 영향이 없어 수리 중에도 나머지 수집은 정상 운영됩니다.