seed, sitemap, HTML 링크에서 URL을 찾고 안전한 범위만 정규화합니다.
대규모 웹 크롤러
설계
많이 요청하는 크롤러가 좋은 크롤러는 아닙니다. robots 정책과 host별 허용 속도를 지키면서 어떤 URL을 멈추고 다시 방문할지 설명할 수 있어야 합니다.
● 문제·규모FrontierPoliteness장애·운영진도 저장
30초 핵심 요약
발견된 URL은 robots 정책, host 예약, fetch, URL·본문 중복 검사를 차례로 통과합니다. 429 Retry-After는 즉시 재시도 신호가 아니라 그 host의 다음 허용 시각으로 저장합니다.
스케줄 단위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 신호에 맞춰 별도로 조정합니다.
발견된 URL을 robots·429·중복 판정까지 어떻게 추적할 것인가?
예시 발견 URL
5억/day
설계 가정
예시 허용 fetch
8,000/s
설계 가정
예시 HTML 대역폭
약 1.44GB/s
계산 결과
host-aware frontier + next_allowed_at + 이중 dedupe
URL을 host별 frontier에 넣고 robots 정책과 next_allowed_at을 확인한 뒤 fetch합니다. 429는 Retry-After로 재예약하고 URL fingerprint와 본문 fingerprint를 별도로 판정합니다.
선택 이유
- 한 host의 오류와 속도 제한이 전체 크롤러를 막지 않습니다.
- 429를 즉시 재시도하지 않아 상대 사이트와 자체 worker를 함께 보호합니다.
- 다른 URL에서 같은 본문을 발견해도 중복 색인을 줄이면서 발견 경로는 보존합니다.
전역 FIFO에서 실패 URL 즉시 재시도
hot host와 429가 worker를 독점하고 robots·예의성 간격을 깨뜨리며 다른 도메인의 freshness까지 악화시킵니다.
감수한 단점
- host별 상태와 예약 큐 메타데이터가 필요합니다.
- 정규화 규칙이 과하면 서로 다른 URL을 잘못 합칠 수 있습니다.
- JavaScript rendering과 재방문 정책은 별도 비용·신선도 예산을 가집니다.
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를 건너뛰지 않는다
coverage와 freshness를 올리면 비용뿐 아니라 상대 host의 부담과 공격 표면도 커집니다. worker 수가 politeness를 앞지르지 않도록 host 예약을 절대 경계로 둡니다.
| 선택 | 장점 | 제약 | 적합한 경우 |
|---|---|---|---|
| 전역 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
답변 구조 보기 6단계
- 어떤 웹을 수집할지, robots·계약·재방문 freshness 목표, JavaScript rendering 범위를 먼저 확인한다.
- URL discovery → 정규화·dedupe → host-aware frontier → policy check → fetch → parse·저장·색인 흐름을 한 장의 그림으로 설명한다.
- host 단위 queue와
next_allowed_at을 선택해 politeness·429 backoff·hot host 격리를 보장한다고 말한다. - URL dedupe와 content fingerprint의 차이, canonical signal을 무조건 믿지 않는 이유를 설명한다.
- SSRF, redirect, DNS rebinding, 대형 응답과 압축 폭탄에 대한 네트워크·자원 경계를 제시한다.
- 마지막으로 queue age, robots decision, host error budget, dedupe ratio, index outbox lag와 비용을 운영 지표로 연결한다. 이번 선택: URL마다 정책·host 예약·fetch·콘텐츠 판정을 분리 기록한다. 깨지는 신호: 429 뒤 즉시 재시도하거나 URL dedupe와 본문 dedupe가 같은 키로 처리된다. 다음 검증: robots 변경과 429를 연속 반환한 뒤 정확히 120초 후 재예약되는지 확인한다.
한 URL의 robots 허용부터 429 재예약·본문 중복까지 추적하기
discovery 이후의 정책 사건을 순서대로 설명합니다.
- URL 정규화와 host queue 배치를 답합니다.
- robots와 429 Retry-After를 next_allowed_at에 반영합니다.
- URL dedupe와 content fingerprint를 분리합니다.
robots 변경과 429를 연속 반환해 예약 상태를 검증합니다.
- 120초 전에 같은 host를 다시 호출하지 않습니다.
- 200 응답 뒤 canonical을 힌트로만 사용합니다.
- 중복 본문은 색인하지 않고 발견 경로만 합칩니다.
TECHNICAL DOCUMENTS
기술 규격·공식 문서
- 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 응답 의미.
이 문제와 이어지는 문서검색 자동완성
수집한 문서를 검색 후보로 만듭니다.
REAL PROJECT CASE
실제 구현 해설 보기 →
AI Systems Atlas에서 이 개념 보기
수집 대상을 제한하고 중복·변경·실패를 관리하는 인덱싱 파이프라인을 비교할 수 있습니다.
TECHNICAL DOCUMENTS & CONTACT
문의·정정
사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.