시스템 디자인 사례 연구 / 대규모 웹 크롤러 학습 로드맵
CASE · ADVANCED읽기 24분검토일 2026-08-29

대규모 웹 크롤러
설계

많이 요청하는 크롤러가 좋은 크롤러는 아닙니다. robots 정책과 host별 허용 속도를 지키면서 어떤 URL을 멈추고 다시 방문할지 설명할 수 있어야 합니다.

09운영자 직접 작성·기술 검토·최종 검토 2026.08.29
● 문제·규모FrontierPoliteness장애·운영진도 저장
⌁30초 핵심 요약

발견된 URL은 robots 정책, host 예약, fetch, URL·본문 중복 검사를 차례로 통과합니다. 429 Retry-After는 즉시 재시도 신호가 아니라 그 host의 다음 허용 시각으로 저장합니다.

스케줄 단위host + next_allowed_at
중복 제어URL ID + content hash
복구 단위lease + durable outbox
DESIGN DECISION · 설계 판단

발견된 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과 재방문 정책은 별도 비용·신선도 예산을 가집니다.
01 · REQUIREMENTS

수집량과 예의성을 같은 요구사항으로 둔다

# 요구사항

이 crawler는 공개 HTTP(S) 문서를 검색·아카이브 파이프라인에 전달합니다. 로그인 우회나 access control 우회는 범위 밖이며, robots 규칙·계약·network policy를 수집 결정에 반영합니다.

R1발견·정규화

seed, sitemap, HTML 링크에서 URL을 찾고 안전한 범위만 정규화합니다.

R2host별 예의성

동시성, 요청 간격, 429와 5xx backoff를 host state에서 관리합니다.

R3중복과 freshness

URL 재방문과 동일 콘텐츠 저장을 각각 판단하고 재수집 이유를 남깁니다.

R4안전한 전달

fetch 성공과 색인 전달을 분리해 후단 장애가 정책·fetch를 왜곡하지 않게 합니다.

02 · HIGH-LEVEL DESIGN

URL frontier가 host의 리듬을 보존한다

# 아키텍처

발견기는 빨리 URL을 만들 수 있지만 worker가 그것을 즉시 가져가면 한 origin을 과부하할 수 있습니다. frontier는 host queue, robots 정책 cache, 다음 허용 시각을 결합해 준비된 작업만 내보냅니다.

정책 인식형 크롤러의 수집 경로 SVG DIAGRAM · DISCOVER / FRONTIER / FETCH / INDEX
대규모 웹 크롤러의 URL 발견, host-aware frontier, fetch, parse 및 색인 전달 흐름 seed와 sitemap에서 발견된 URL은 정규화와 중복 제거를 거쳐 host-aware frontier에 들어간다. robots 정책과 host backoff를 통과한 fetch worker가 응답을 parse하여 원문 저장소와 색인 파이프라인으로 보낸다. 발견·정책·스케줄 경로fetch 결과와 피드백 경로 Seed · Sitemap이전 crawl · links 정규화 · URL dedupescheme · canonical 후보 Host-aware Frontierqueue · next_allowed_at · leaserobots cache · error budget Fetch Workersize cap · redirect guard Parse · fingerprintlinks · MIME · content hash 원문·메타 저장content object · result 색인 Outboxdurable replay Host backoff · metrics429 / 5xx · retry-after 성공 결과·새 URL오류·정책 피드백
사실과 판단: 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가 안전하게 재시도할 수 있습니다.

1발견·허용 범위

seed, sitemap, HTML에서 찾은 URL을 scheme·host 정책과 길이 제한으로 거릅니다.

2URL dedupe

동일 normalized URL의 방문 중·최근 성공 상태를 확인하고 재방문 이유를 남깁니다.

3host queue 삽입

URL은 host shard에 넣고 next_allowed_at과 priority를 함께 기록합니다.

4robots·lease

정책을 확인한 scheduler가 준비된 host에서 하나를 lease해 worker에 전달합니다.

5bounded fetch

redirect, resolved IP, MIME, 응답 크기, 압축 비율을 제한해 stream으로 읽습니다.

6parse·outbox

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

장애를 host·lease·콘텐츠 경계에서 복구한다

# 장애 6가지
≋frontier shard 지연

준비된 URL이 쌓여 freshness가 떨어지고 오래된 lease가 증가합니다.

대응 · shard autoscale, lease 회수, low-priority 감속. 재분배 뒤 host 순서와 중복 fetch를 확인합니다.
Rrobots 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단계
  1. 어떤 웹을 수집할지, robots·계약·재방문 freshness 목표, JavaScript rendering 범위를 먼저 확인한다.
  2. URL discovery → 정규화·dedupe → host-aware frontier → policy check → fetch → parse·저장·색인 흐름을 한 장의 그림으로 설명한다.
  3. host 단위 queue와 next_allowed_at을 선택해 politeness·429 backoff·hot host 격리를 보장한다고 말한다.
  4. URL dedupe와 content fingerprint의 차이, canonical signal을 무조건 믿지 않는 이유를 설명한다.
  5. SSRF, redirect, DNS rebinding, 대형 응답과 압축 폭탄에 대한 네트워크·자원 경계를 제시한다.
  6. 마지막으로 queue age, robots decision, host error budget, dedupe ratio, index outbox lag와 비용을 운영 지표로 연결한다. 이번 선택: URL마다 정책·host 예약·fetch·콘텐츠 판정을 분리 기록한다. 깨지는 신호: 429 뒤 즉시 재시도하거나 URL dedupe와 본문 dedupe가 같은 키로 처리된다. 다음 검증: robots 변경과 429를 연속 반환한 뒤 정확히 120초 후 재예약되는지 확인한다.
INTERVIEW ↔ PRACTICE · 면접과 실무의 차이

한 URL의 robots 허용부터 429 재예약·본문 중복까지 추적하기

INTERVIEW · 면접

discovery 이후의 정책 사건을 순서대로 설명합니다.

  • URL 정규화와 host queue 배치를 답합니다.
  • robots와 429 Retry-After를 next_allowed_at에 반영합니다.
  • URL dedupe와 content fingerprint를 분리합니다.
PRACTICE · 실무

robots 변경과 429를 연속 반환해 예약 상태를 검증합니다.

  • 120초 전에 같은 host를 다시 호출하지 않습니다.
  • 200 응답 뒤 canonical을 힌트로만 사용합니다.
  • 중복 본문은 색인하지 않고 발견 경로만 합칩니다.
SOURCES

공식·1차 출처

NEXT CASE STUDY실시간 채팅 시스템 설계
→
REAL PROJECT CASE

AI Systems Atlas에서 이 개념 보기

수집 대상을 제한하고 중복·변경·실패를 관리하는 인덱싱 파이프라인을 비교할 수 있습니다.

실제 구현 해설 보기 →
EDITORIAL NOTES

작성·검토·참고 자료

콘텐츠 원칙
이 문서는 독립적으로 재작성한 한국어 학습 자료입니다. 사실과 학습용 설계 가정을 구분합니다.
작성·기술 검수
프로젝트 운영자가 직접 작성·기술 검토했습니다. 주제별 공식·1차 자료와 명시적인 설계 가정을 확인하며, 독립적인 제3자 검수가 아닙니다. 경력 범위와 검수 원칙 보기
최종 검토
예상 학습 시간
24분

사실 오류·출처 정정은 문의·정정 페이지로 알려 주세요.