seed, sitemap, HTML 링크에서 URL을 찾고 안전한 범위만 정규화합니다.
대규모 웹 크롤러
설계
크롤러의 성능은 많이 요청하는 능력이 아니라, 어떤 URL을 언제 멈추고 다시 방문할지 설명할 수 있는 능력에서 나옵니다. host 단위 frontier와 정책·중복 제거·복구 경로를 함께 설계합니다.
● 문제·규모FrontierPoliteness장애·운영진도 저장
30초 핵심 요약
수집 후보는 host-aware URL Frontier로 넣고, scheduler는 host의 다음 허용 시각이 지난 URL만 worker에 lease합니다. URL fingerprint는 방문 중복을, 콘텐츠 hash는 저장 중복을 줄입니다. `robots.txt`, 429/5xx, 응답 크기 제한은 성능 옵션이 아니라 안전한 수집의 경계입니다.
스케줄 단위host + next_allowed_at
중복 제어URL ID + content hash
복구 단위lease + durable outbox
01 · REQUIREMENTS
# 요구사항수집량과 예의성을 같은 요구사항으로 둔다
이 crawler는 공개 HTTP(S) 문서를 검색·아카이브 파이프라인에 전달합니다. 로그인 우회나 access control 우회는 범위 밖이며, robots 규칙·계약·network policy를 수집 결정에 반영합니다.
동시성, 요청 간격, 429와 5xx backoff를 host state에서 관리합니다.
URL 재방문과 동일 콘텐츠 저장을 각각 판단하고 재수집 이유를 남깁니다.
fetch 성공과 색인 전달을 분리해 후단 장애가 정책·fetch를 왜곡하지 않게 합니다.
02 · HIGH-LEVEL DESIGN
# 아키텍처URL frontier가 host의 리듬을 보존한다
발견기는 빨리 URL을 만들 수 있지만 worker가 그것을 즉시 가져가면 한 origin을 과부하할 수 있습니다. frontier는 host queue, robots 정책 cache, 다음 허용 시각을 결합해 준비된 작업만 내보냅니다.
정책 인식형 크롤러의 수집 경로 SVG DIAGRAM · DISCOVER / FRONTIER / FETCH / INDEX
사실과 판단: RFC 9309은 robots.txt의 위치·규칙 문법과 접근 상태의 해석을 정의합니다. 이 페이지의 host backoff와 정책 cache TTL은 예시이며, origin·계약·HTTP 신호에 맞춰 별도로 조정합니다.
03 · SCHEDULING FLOW
# 요청 흐름준비된 host만 하나씩 lease한다
URL을 worker 큐에 바로 쌓지 않고, `next_allowed_at`을 지난 host를 scheduler가 선택합니다. worker가 사라져도 lease가 만료되면 다른 worker가 안전하게 재시도할 수 있습니다.
seed, sitemap, HTML에서 찾은 URL을 scheme·host 정책과 길이 제한으로 거릅니다.
동일 normalized URL의 방문 중·최근 성공 상태를 확인하고 재방문 이유를 남깁니다.
URL은 host shard에 넣고 `next_allowed_at`과 priority를 함께 기록합니다.
정책을 확인한 scheduler가 준비된 host에서 하나를 lease해 worker에 전달합니다.
redirect, resolved IP, MIME, 응답 크기, 압축 비율을 제한해 stream으로 읽습니다.
link와 content hash를 추출하고 색인 전달은 durable outbox로 분리합니다.
04 · TRADEOFFS
# 트레이드오프coverage를 늘려도 policy를 건너뛰지 않는다
재방문 빈도와 렌더링 범위를 넓히면 색인 freshness는 좋아질 수 있지만, host 부하·storage·CPU·security 경계가 함께 커집니다. 우선순위는 host delay를 앞지를 수 없습니다.
| 선택 | 장점 | 제약 | 적합한 경우 |
|---|---|---|---|
| 전역 FIFO 큐 | 구현이 단순 | hot host와 politeness를 격리하기 어려움 | 작은 단일-domain crawler |
| host-aware frontier | 요청 간격·backoff를 자연스럽게 적용 | host state와 scheduler가 필요 | 다수 origin을 다루는 crawler |
| URL dedupe | 발견 단계의 재방문을 빠르게 차단 | 동일 본문의 여러 URL은 남음 | frontier의 첫 번째 방어선 |
| content fingerprint | 저장·색인 중복을 줄임 | hash 비용, near-duplicate 한계 | 검색·아카이브 품질이 중요한 경우 |
| 별도 rendering fleet | 동적 페이지 대응 | CPU·sandbox·abuse 비용이 큼 | 허용된 범위의 선택적 rendering |
05 · FAILURE MODES
# 장애 6가지장애를 host·lease·콘텐츠 경계에서 복구한다
frontier shard 지연
준비된 URL이 쌓여 freshness가 떨어지고 오래된 lease가 증가합니다.
대응 · shard autoscale, lease 회수, low-priority 감속. 재분배 뒤 host 순서와 중복 fetch를 확인합니다.
robots cache 폭주
정책 TTL이 동시에 만료되어 같은 origin에 robots 요청이 몰립니다.
대응 · single-flight, TTL jitter, host별 상한. robots 요청률과 규칙 적용률을 대조합니다.
DNS·내부 IP 위험
redirect나 DNS 변조로 worker가 내부 네트워크로 향할 수 있습니다.
대응 · resolve 뒤 재검사, egress firewall, peer 검증. 차단 fixture를 재현합니다.
대형 응답·압축 폭탄
메모리와 CPU가 고갈되어 worker가 재시작하고 queue가 밀립니다.
대응 · streaming size cap, MIME별 limit, sandbox. 악성 fixture에서 제한 내 종료를 검증합니다.
host 429·5xx 증가
상대 origin의 부하 또는 일시 장애가 수집 실패와 신뢰 저하로 이어집니다.
대응 · retry-after 존중, exponential backoff, concurrency 하향. 요청 간격과 회복률을 함께 봅니다.
outbox·저장소 지연
fetch는 성공했지만 원문 또는 색인 이벤트가 누락될 수 있습니다.
대응 · durable outbox, backpressure, replay. content_id와 index event 수를 대조합니다.
06 · SAFETY & OPERATIONS
# 운영수집 worker를 외부 입력 실행기로 취급한다
DNS 후 IP 검사, redirect마다 network policy 재평가, private·metadata 주소 차단으로 SSRF 경계를 둡니다. URL query·본문의 토큰은 최소 보존합니다.
egress deny · size cap · raw retention
queue age, lease expiry, robots decision, politeness wait, host error budget, dedupe ratio, outbox lag를 분리해 정책과 처리량을 함께 봅니다.
frontier_queue_age_seconds
요청 수뿐 아니라 응답 byte, TLS·egress, raw object storage, parsing CPU, dedupe index, rendering fleet, index write가 비용을 만듭니다.
bytes × retention × replica
면접 모드 · 추가 질문06:00
“공개 웹을 수집하는 crawler를 설계해 보세요. URL을 어떤 단위로 scheduling하고, robots.txt·429·host 부하를 어떻게 반영하며, URL 중복과 콘텐츠 중복·SSRF·worker 손실을 어떤 데이터와 지표로 다루겠습니까?”
host-aware frontiernext_allowed_atrobots cachelease + idempotent writeURL / content dedupeegress boundary
SOURCES
공식·1차 출처
- IETF RFC 9309 — Robots Exclusion Protocol: robots.txt의 위치, 문법, crawler 접근 상태.
- Google Search Central — Google Crawler Overview: 공개 crawler 식별·검증 안내.
- Google Search Central — Robots.txt specifications: robots.txt 적용의 공식 안내.
- IETF RFC 9110 — HTTP Semantics: `Retry-After` 등 HTTP 응답 의미.
NEXT CASE STUDY실시간 채팅 시스템 설계
EDITORIAL NOTES
작성·검토·참고 자료
참고 자료
- IETF, **RFC 9309 — Robots Exclusion Protocol**, robots.txt 위치, 규칙 문법과 crawler 접근 상태: https://www.rfc-editor.org/rfc/rfc9309.html
- Google Search Central, **Google Crawler Overview**, Google crawler의 공개 식별 및 검증 안내: https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlers
- Google Search Central, **Robots.txt specifications**, robots.txt의 적용과 테스트 관련 공식 안내: https://developers.google.com/search/docs/crawling-indexing/robots/intro
- IETF, **RFC 9110 — HTTP Semantics**, `Retry-After`, redirect와 HTTP 응답 의미: https://www.rfc-editor.org/rfc/rfc9110.html
- 이 문서의 용량, host budget, TTL, retry, 저장 보존 정책은 학습용 설계 가정이다. 실제 출시 전에는 대상 웹의 약관, 법무 검토, egress 정책, 부하·복구 시험으로 검증한다.
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.