[대규모 시스템 설계 스터디] 9장 정리

김연준·2026년 8월 8일

[대규모 시스템 설계 스터디]

목록 보기
9/13
post-thumbnail

웹 크롤러 설계

1. 웹 크롤러란

웹 크롤러는 웹에 새로 올라오거나 갱신된 콘텐츠를 찾아내고 수집하는 시스템임.

수집 대상은 다음과 같이 다양할 수 있음.

  • 웹 페이지
  • 이미지
  • 비디오
  • PDF
  • 기타 웹 문서

대표적인 활용 사례는 다음과 같음.

검색 엔진 인덱싱

  • 크롤러는 웹 페이지를 발견하고 수집하여 검색 엔진의 인덱싱 시스템에 전달함
  • 대표적인 예로 Google Search에서 사용하는 웹 크롤러인 Googlebot이 있음

웹 아카이빙

  • 웹에 존재하는 정보를 장기간 보관하기 위해 수집하는 작업

  • 많은 국립도서관과 기관에서 웹사이트를 주기적으로 수집하여 보존함

  • 예시

    • 미국 의회도서관
    • EU 웹 아카이브

웹 마이닝

  • 웹에서 대량의 데이터를 수집한 뒤 유용한 정보를 추출하는 작업
  • 예를 들어 금융 기업이 기업의 연차 보고서나 주주총회 자료를 수집해 기업의 사업 방향을 분석할 수 있음

웹 모니터링

  • 웹에서 특정 정보나 콘텐츠가 새롭게 등장하는지 지속적으로 감시하는 용도
  • 저작권 또는 상표권 침해 사례를 탐지하는 데 활용 가능
  • 예를 들어 웹에서 불법 복제 콘텐츠를 탐지하는 시스템에 crawler를 사용할 수 있음

2. 웹 크롤러 설계 시 고려 사항

웹 크롤러의 복잡도는 수집해야 하는 데이터의 규모에 따라 크게 달라짐.

따라서 설계를 시작하기 전에 다음 내용을 명확하게 해야 함.

  • 얼마나 많은 페이지를 수집해야 하는가
  • 어떤 종류의 콘텐츠를 수집해야 하는가
  • 얼마나 자주 다시 방문해야 하는가
  • 수집한 데이터를 얼마나 오래 저장해야 하는가
  • 특정 사이트에 얼마나 자주 요청할 수 있는가

대규모 웹 크롤러가 만족해야 할 주요 속성은 다음과 같음.

규모 확장성

  • 웹은 매우 크므로 한 서버만으로 모든 페이지를 수집하기 어려움
  • 여러 서버와 여러 작업 스레드를 사용하여 병렬로 처리할 필요가 있음

안정성

웹에는 다음과 같은 비정상적인 상황이 존재할 수 있음.

  • 잘못 작성된 웹 페이지
  • 응답하지 않는 서버
  • 매우 느린 서버
  • 악성 콘텐츠
  • 무한히 생성되는 URL

따라서 특정 페이지의 문제가 전체 크롤러 시스템 장애로 이어지지 않도록 해야 함.

예절

  • 특정 웹사이트에 짧은 시간 동안 지나치게 많은 요청을 보내서는 안 됨
  • 대상 사이트의 robots.txt 정책과 요청 속도 제한을 고려해야 함

확장성

  • 새로운 콘텐츠 형식을 쉽게 추가할 수 있어야 함
  • 이미지, PDF, 동영상 등 새로운 콘텐츠를 지원할 때 전체 시스템을 다시 설계하지 않아도 되는 구조가 바람직함

3. 기본 크롤링 알고리즘

웹 크롤러의 기본적인 동작 방식은 다음과 같음.

  1. 시작 URL 집합을 입력받음
  2. 해당 URL이 가리키는 웹 페이지를 다운로드
  3. 다운로드한 페이지에서 새로운 URL 추출
  4. 새롭게 발견한 URL을 다운로드할 URL 목록에 추가
  5. 위 과정을 반복

개념적으로는 다음과 같음.

시작 URL
→ 페이지 다운로드
→ URL 추출
→ 새로운 URL 저장
→ 다시 다운로드
→ 반복

하지만 실제 웹은 매우 크기 때문에 단순히 이 알고리즘만 반복하는 것으로는 대규모 크롤러를 구현하기 어려움.

4. 요구사항

다음 규모를 처리하는 웹 크롤러를 설계한다고 가정함.

페이지 다운로드 수

  • 매달 10억 개의 웹 페이지 다운로드

평균 QPS:

10억 ÷ 30일 ÷ 24시간 ÷ 3,600초
≈ 386페이지/초
≈ 약 400 QPS

Peak QPS를 평균의 2배로 가정:

400 × 2
= 약 800 QPS

저장 용량

웹 페이지 평균 크기를 500KB라고 가정함.

10억 페이지 × 500KB
≈ 500TB/월

5년 동안 데이터를 보관한다고 가정하면:

500TB × 12개월 × 5년
= 30PB

따라서 약 30PB 규모의 저장 공간이 필요함.

5. 개략적인 시스템 구성

대규모 웹 크롤러는 다음과 같은 주요 컴포넌트로 구성할 수 있음.

  • 시작 URL 집합
  • 미수집 URL 저장소
  • HTML 다운로더
  • DNS 변환기
  • 콘텐츠 파서
  • 중복 콘텐츠 탐지
  • 콘텐츠 저장소
  • URL 추출기
  • URL 필터
  • 방문 URL 관리
  • URL 저장소

6. 시작 URL 집합

시작 URL은 웹 크롤러가 크롤링을 시작하는 출발점임.

전체 웹을 크롤링하려면 가능한 많은 페이지로 연결될 수 있는 URL을 선택하는 것이 중요함.

예를 들어 다음과 같은 기준으로 시작 URL을 구성할 수 있음.

  • 국가별 주요 웹사이트
  • 카테고리별 주요 웹사이트
  • 인기 웹사이트
  • 기존에 알고 있는 도메인 목록

시작 URL을 선택하는 절대적인 정답은 없으며 크롤러의 목적에 따라 달라짐.

7. 미수집 URL 저장소

미수집 URL 저장소는 아직 다운로드하지 않은 URL을 관리하는 컴포넌트임.

이를 일반적으로 URL Frontier라고 부름.

기본적인 BFS 구조에서는 FIFO 큐처럼 볼 수 있음.

URL 발견
→ URL Frontier 저장
→ 순서대로 다운로드

하지만 실제 대규모 크롤러에서는 단순 FIFO 큐 하나만 사용하지 않음.

다음 기능이 추가로 필요하기 때문임.

  • URL 우선순위
  • 웹사이트별 요청 속도 제한
  • 재수집 시점 관리
  • 크롤러 예절 유지

따라서 실제 URL Frontier는 여러 개의 큐와 스케줄링 로직으로 구성됨.

8. HTML 다운로더

HTML 다운로더는 인터넷에서 실제 웹 페이지를 다운로드하는 컴포넌트임.

다운로드할 URL은 URL Frontier에서 전달받음.

URL Frontier
→ HTML Downloader
→ 웹 서버에 HTTP 요청
→ 웹 페이지 다운로드

9. 도메인 이름 변환기

웹 페이지를 다운로드하려면 URL의 도메인 이름을 IP 주소로 변환해야 함.

예:

www.example.com
→ DNS
→ 93.184.216.34

HTML 다운로더는 DNS 시스템을 사용하여 대상 서버의 IP 주소를 알아냄.

10. 콘텐츠 파서

웹 페이지를 다운로드한 후에는 페이지를 파싱하고 검증해야 함.

웹에는 다음과 같은 비정상적인 콘텐츠가 존재할 수 있음.

  • 잘못된 HTML
  • 지나치게 큰 문서
  • 악성 콘텐츠
  • 파싱할 수 없는 데이터

다운로드와 파싱은 작업 특성이 다르므로 별도 컴포넌트로 분리하면 다음 장점이 있음.

  • 다운로드와 파싱을 독립적으로 확장 가능
  • 파서 장애가 다운로더 전체에 영향을 주는 것을 줄일 수 있음
  • 네트워크 중심 작업과 CPU 중심 작업 분리 가능

11. 중복 콘텐츠 탐지

웹에는 동일하거나 매우 유사한 콘텐츠가 여러 URL에 존재하는 경우가 많음.

연구에 따라 상당한 비율의 웹 페이지가 중복 콘텐츠일 수 있음.

동일한 콘텐츠를 반복해서 저장하면 다음 문제가 발생함.

  • 저장 공간 낭비
  • 네트워크 사용량 증가
  • 인덱싱 비용 증가

이를 방지하기 위해 페이지 콘텐츠의 해시값이나 체크섬을 사용할 수 있음.

웹 페이지 콘텐츠
→ Hash
→ 콘텐츠 해시값

이미 같은 해시값이 존재한다면 중복 콘텐츠로 판단할 수 있음.

12. 콘텐츠 저장소

다운로드한 HTML 문서를 장기간 보관하는 저장소임.

저장소 기술을 선택할 때는 다음 요소를 고려해야 함.

  • 데이터 크기
  • 데이터 형식
  • 접근 빈도
  • 데이터 보관 기간

대규모 시스템에서는 디스크와 메모리를 함께 활용할 수 있음.

  • 자주 접근하는 데이터 → 메모리 또는 캐시
  • 대량의 원본 데이터 → 디스크 또는 객체 저장소

13. URL 추출기

다운로드한 HTML 페이지를 분석하여 새로운 링크를 추출하는 역할을 함.

예를 들어 다음 HTML이 있다고 가정함.

<a href="/news/1">뉴스</a>

현재 페이지가 다음과 같다면:

https://example.com

상대 경로 /news/1을 절대 경로로 변환함.

https://example.com/news/1

14. URL 필터

URL 필터는 크롤링할 필요가 없는 URL을 제거하는 역할을 함.

예를 들어 다음 URL을 제외할 수 있음.

  • 특정 콘텐츠 타입
  • 특정 파일 확장자
  • 접속 시 오류가 발생하는 URL
  • 접근 제외 목록에 포함된 URL
  • 크롤러 목적과 관계없는 URL

특정 콘텐츠 타입이나 파일 확장자를 제외하는 이유는 크롤러의 목적과 관계없는 파일에 시간, 네트워크, 저장 공간을 낭비하지 않기 위해서임.

예를 들어 일반적인 HTML 중심 크롤러라면 다음 파일은 제외할 수 있음.

.jpg
.mp4
.zip
.exe

이미지나 동영상은 파일 크기가 크고 HTML 링크 분석 대상이 아닐 수 있음.

또한 HTML 파서는 이미지나 실행 파일을 직접 분석할 수 없음.

다만 크롤러의 목적이 이미지 검색이나 동영상 검색이라면 이러한 콘텐츠도 수집 대상으로 포함할 수 있음.

15. 이미 방문한 URL 관리

새 URL을 발견할 때마다 이미 발견하거나 방문한 URL인지 확인해야 함.

새로운 URL 발견
→ 이미 본 URL인지 확인
→ 처음 보는 URL이면 URL Frontier에 추가
→ 이미 처리한 URL이면 제외

중복 URL을 제거하지 않으면 다음 문제가 발생할 수 있음.

  • 동일 페이지 반복 다운로드
  • 대상 서버 부하 증가
  • 네트워크 자원 낭비
  • 크롤러가 순환 링크에 의해 무한 반복할 가능성

방문 여부를 추적하기 위한 자료구조로 다음을 사용할 수 있음.

  • 해시 테이블
  • 블룸 필터

16. URL 저장소

이미 방문하거나 발견한 URL을 저장하는 시스템임.

대규모 검색 엔진 크롤러에서는 URL 수가 수억~수십억 개 이상이 될 수 있으므로 모든 URL을 메모리에만 저장하기 어려움.

따라서 지속적인 저장소와 메모리를 함께 사용하는 방식을 고려할 수 있음.

17. DFS와 BFS

웹은 그래프로 표현할 수 있음.

웹 페이지 = 노드
하이퍼링크 = 간선

따라서 웹 크롤링은 웹 그래프의 간선을 따라 이동하면서 노드를 방문하는 과정으로 볼 수 있음.

대표적인 그래프 탐색 방법은 다음과 같음.

  • DFS
  • BFS

DFS

DFS는 특정 경로를 계속 깊게 탐색함.

웹은 사실상 깊이를 예측하기 어려울 정도로 거대한 그래프이므로 특정 사이트나 경로만 지나치게 깊게 탐색할 수 있음.

따라서 일반적인 웹 크롤러에는 적합하지 않음.

BFS

BFS는 가까운 페이지부터 넓게 탐색함.

FIFO 큐를 사용하여 구현할 수 있으므로 웹 크롤러에서 기본적인 접근 방식으로 많이 사용됨.

하지만 단순 BFS에도 문제가 있음.

18. 단순 BFS의 문제점

문제 1. 특정 서버에 요청 집중

한 페이지에서 추출한 많은 URL이 같은 호스트를 가리킬 수 있음.

예:

example.com
 ├─ /news/1
 ├─ /news/2
 ├─ /news/3
 ├─ /news/4
 └─ /news/5

이 URL들을 병렬로 동시에 다운로드하면:

example.com
← 다수의 HTTP 요청

특정 웹 서버에 요청이 집중되어 과부하를 발생시킬 수 있음.

이런 크롤러는 예의 없는 크롤러로 간주될 수 있음.

문제 2. URL 우선순위가 없음

일반적인 BFS는 모든 URL을 동일한 우선순위로 처리함.

하지만 실제 웹 페이지의 중요도는 서로 다름.

예를 들어 다음 요소를 고려할 수 있음.

  • PageRank
  • 사용자 트래픽
  • 페이지 갱신 빈도
  • 사이트 신뢰도
  • 콘텐츠 중요도

따라서 중요한 페이지를 우선적으로 크롤링할 수 있는 시스템이 필요함.

19. 예의 바른 크롤러

예의 바른 크롤러는 동일 웹사이트에 대해서 한 번에 한 페이지만 요청하는 원칙을 지켜야 함.

같은 웹사이트의 페이지를 다운로드하는 작업은 시간차를 두고 수행하도록 구성할 수 있음.

이를 위해 웹사이트의 호스트명과 다운로드 작업을 수행하는 작업 스레드 사이의 관계를 유지함.

각 작업 스레드는 별도의 FIFO 큐에서 URL을 가져와 처리함.

주요 컴포넌트는 다음과 같음.

큐 라우터

  • 동일한 호스트에 속하는 URL이 항상 같은 큐로 전달되도록 함

예:

example.com/a ─┐
example.com/b ─┼→ Queue 1
example.com/c ─┘

매핑 테이블

호스트 이름과 큐의 관계를 저장함.

example.com → Queue 1
google.com  → Queue 2

FIFO 큐

  • 같은 호스트의 URL을 저장
  • 큐 내부에서는 순차적으로 URL 처리

큐 선택기

  • 여러 큐를 순회
  • 처리할 URL을 선택
  • 해당 URL을 담당 작업 스레드에 전달

작업 스레드

  • 전달받은 URL 다운로드
  • 동일 호스트에 대한 요청은 순차적으로 처리
  • 요청 사이에 일정한 시간 간격을 둘 수 있음

20. URL 우선순위

웹에 존재하는 모든 페이지가 동일한 중요도를 가지는 것은 아님.

크롤러는 가치가 높은 페이지를 먼저 수집하는 것이 효율적임.

URL의 우선순위를 결정할 때 다음 요소를 사용할 수 있음.

  • PageRank
  • 사용자 트래픽
  • 페이지 갱신 빈도
  • 사이트 신뢰도

우선순위 처리는 다음 컴포넌트로 구성할 수 있음.

순위 결정 장치

  • URL을 입력받음
  • URL의 우선순위를 계산

우선순위 큐

우선순위별로 URL을 별도의 큐에 저장함.

높은 우선순위 Queue
중간 우선순위 Queue
낮은 우선순위 Queue

큐 선택기

  • 높은 우선순위 큐에서 URL을 더 자주 선택
  • 낮은 우선순위 URL도 완전히 굶지 않도록 확률적으로 선택 가능

21. 전면 큐와 후면 큐

URL Frontier는 크게 다음 두 역할로 나눌 수 있음.

전면 큐

  • URL의 우선순위 관리
  • 어떤 페이지를 먼저 크롤링할 것인지 결정

후면 큐

  • 크롤링 예절 관리
  • 동일 호스트에 대한 요청 속도 제한
  • 호스트별 URL 큐 관리

정리하면:

새로운 URL
→ 전면 큐
→ 우선순위 결정
→ 후면 큐
→ 호스트별 속도 제어
→ Downloader

22. 신선도

웹 페이지는 지속적으로 변경됨.

  • 새로운 페이지 생성
  • 기존 페이지 수정
  • 페이지 삭제

따라서 한 번 다운로드한 페이지도 일정 시간이 지나면 다시 수집할 필요가 있음.

하지만 모든 URL을 동일한 주기로 다시 크롤링하면 막대한 자원이 필요함.

따라서 다음 정보를 이용하여 재수집 주기를 결정할 수 있음.

  • 과거 페이지 변경 빈도
  • 페이지 중요도
  • 마지막 변경 시각
  • 사이트 특성

자주 변경되는 중요한 페이지는 자주 방문하고, 거의 변경되지 않는 페이지는 더 긴 주기로 방문하도록 최적화할 수 있음.

23. URL Frontier 저장 구조

검색 엔진 수준의 크롤러는 처리해야 하는 URL 수가 매우 많음.

모든 URL을 메모리에 저장하면:

  • 메모리 비용 증가
  • 장애 발생 시 상태 손실 가능
  • 규모 확장 어려움

반대로 모든 데이터를 디스크에서 직접 처리하면 디스크 I/O가 병목이 될 수 있음.

따라서 메모리와 디스크를 함께 사용하는 하이브리드 방식이 적절함.

대부분의 URL
→ 디스크

곧 처리할 URL
→ 메모리 버퍼

메모리 버퍼의 데이터는 주기적으로 지속 저장장치에 기록함.

24. robots.txt

robots.txt는 로봇 제외 프로토콜이라고도 하며, 웹사이트 운영자가 crawler와 소통하기 위한 표준적인 방법임.

사이트 운영자는 crawler별로 특정 URL 경로에 대한 접근 허용 또는 제외 규칙을 정의할 수 있음.

예:

User-agent: *
Disallow: /admin/
Allow: /

크롤러는 사이트를 수집하기 전에 해당 사이트의 robots.txt를 확인하고 자신의 User-Agent에 적용되는 규칙을 확인해야 함.

다만 robots.txt는 보안 시스템이 아님.

즉 사이트에 대한 실제 접근 자체를 기술적으로 막는 것이 아니라 crawler에게 정책을 전달하는 규칙임.

25. Amazon robots.txt에서 본 crawler별 정책 차이

2026년 8월 amazon.com/robots.txt를 확인했을 때 crawler의 User-Agent에 따라 서로 다른 접근 정책이 적용되어 있는 것을 확인할 수 있었음.

일반적인 검색 crawler에는 특정 경로만 제외하는 방식으로 설정되어 있는 반면, 일부 AI 서비스 관련 crawler는 더 강한 제한이 적용되어 있을 수 있음.

이 차이가 왜 발생하는지 궁금하여 일반 crawler와 AI 서비스 crawler의 차이를 조사해 봄.

26. 일반 crawler와 AI crawler

crawler는 기술적으로 모두 웹 페이지를 자동으로 요청하고 수집하는 프로그램이라는 점에서는 비슷함.

차이는 주로 수집 목적과 운영 주체에서 발생함.

일반적인 crawler

목적에 따라 다음 용도로 사용될 수 있음.

  • 검색 엔진 색인
  • 데이터 수집
  • 사이트 분석
  • 웹 아카이빙
  • 가격 비교

대표적으로 Googlebot은 검색 엔진 색인을 위해 Google이 운영하는 crawler임.

AI 서비스 관련 crawler

AI 서비스 사업자가 운영하는 crawler 역시 목적에 따라 여러 종류로 구분될 수 있음.

예:

  • 모델 학습 또는 개선용 데이터 수집
  • AI 검색을 위한 웹 페이지 수집
  • 최신 정보 기반 답변 생성을 위한 콘텐츠 접근

따라서 모든 AI crawler가 반드시 모델 학습만을 목적으로 하는 것은 아님.

검색 엔진 crawler와 AI crawler의 가장 큰 차이는 crawler의 기본 동작 구조보다는 수집된 데이터를 어디에 사용하는지에 있음.

27. robots.txt는 실제 접근 차단 기능인가

robots.txt는 강제적인 접근 통제 시스템이 아님.

robots.txt
→ "이 경로는 크롤링하지 말아 달라"는 정책 전달

정상적인 crawler는 이러한 규칙을 준수함.

하지만 악의적인 crawler가 robots.txt를 무시하는 것도 기술적으로 가능함.

실제로 접근을 막으려면 별도의 보안 기술을 사용해야 함.

예:

  • WAF
  • IP 차단
  • 인증
  • Rate Limiting
  • CAPTCHA

즉:

robots.txt
= crawler 행동 규칙

WAF / 인증 / IP 차단
= 실제 접근 제어

28. 일반 사용자가 AI crawler를 사용할 수 있는가

GPTBot이나 Googlebot처럼 특정 서비스 사업자가 공식적으로 운영하는 crawler는 일반 사용자가 직접 실행하거나 제어할 수 있는 서비스가 아님.

해당 crawler는 서비스 사업자가 자체 인프라에서 운영함.

예를 들어:

Googlebot
→ Google이 직접 운영

GPTBot
→ OpenAI가 직접 운영

따라서 사용자가 명령을 내려 Googlebot이나 GPTBot 자체를 직접 실행시키는 것은 불가능함.

다만 일반 사용자가 직접 웹 crawler를 개발하는 것은 가능함.

예:

직접 만든 crawler
→ 웹 페이지 수집
→ AI 모델에 전달
→ 분석 또는 요약

즉 AI와 crawler를 결합한 시스템 자체는 직접 만들 수 있지만, 특정 기업이 운영하는 공식 crawler를 사용하는 것은 별개의 문제임.

29. HTML 다운로더 성능 최적화

분산 크롤링

크롤링 성능을 높이기 위해 다운로드 작업을 여러 서버에 분산할 수 있음.

Crawler Server 1
Crawler Server 2
Crawler Server 3
...

각 서버는 여러 작업 스레드를 사용하여 동시에 페이지를 다운로드할 수 있음.

DNS 조회 결과 캐싱

DNS 조회는 네트워크 통신이 필요한 작업이므로 반복적으로 수행하면 오버헤드가 발생함.

따라서 다음 정보를 캐시에 저장할 수 있음.

도메인 이름 → IP 주소

예:

example.com → 93.184.216.34

동일한 도메인을 다시 방문할 때 DNS 서버에 매번 요청하지 않고 캐시된 결과를 사용할 수 있음.

캐시된 DNS 정보는 TTL이나 별도의 갱신 정책에 따라 주기적으로 갱신해야 함.

지역성

크롤링 서버를 대상 웹 서버와 지리적으로 가까운 지역에 배치하면 네트워크 지연 시간을 줄일 수 있음.

지역성은 다음 컴포넌트에 활용 가능함.

  • 크롤링 서버
  • 캐시
  • 메시지 큐
  • 저장소

짧은 타임아웃

일부 웹 서버는 다음과 같은 문제가 있을 수 있음.

  • 응답이 매우 느림
  • 연결은 되었지만 데이터를 보내지 않음
  • 아예 응답하지 않음

이러한 서버를 무한정 기다리면 작업 스레드가 계속 점유됨.

따라서 최대 대기 시간을 설정해야 함.

응답 시간 > Timeout
→ 요청 중단
→ 실패 처리

30. 안정성

성능뿐 아니라 장애 상황에서도 시스템이 계속 동작하도록 설계해야 함.

안정 해시

다운로더 서버에 URL을 분산할 때 안정 해시를 사용할 수 있음.

장점:

  • 서버 추가 시 일부 URL만 재배치
  • 서버 제거 시 일부 URL만 다른 서버로 이동
  • 서버 변경에 따른 전체 데이터 재배치 감소

크롤링 상태 저장

장애 발생 후 처음부터 모든 작업을 다시 시작하지 않도록 다음 정보를 지속 저장장치에 기록함.

  • 이미 방문한 URL
  • URL Frontier 상태
  • 수집 완료 여부
  • 수집된 콘텐츠

이를 통해 장애 발생 이후 이전 상태에서 작업을 재개할 수 있음.

예외 처리

대규모 시스템에서는 오류를 완전히 없애기 어려움.

따라서 일부 요청 실패가 전체 시스템 중단으로 이어지지 않도록 해야 함.

예:

  • 재시도
  • 실패 큐
  • 오류 로그
  • 특정 URL 격리

데이터 검증

다운로드한 데이터가 정상적인지 확인해야 함.

예:

  • 문서 크기 제한
  • 콘텐츠 타입 확인
  • HTML 유효성 확인
  • 악성 파일 여부 검사

31. 확장성

웹에는 HTML 외에도 다양한 콘텐츠가 존재함.

  • 이미지
  • PDF
  • 동영상
  • 문서 파일

새로운 콘텐츠 형식을 지원할 때마다 전체 크롤러를 수정하는 구조는 유지보수가 어려움.

따라서 콘텐츠 유형별 처리기를 독립적인 모듈로 구현하는 것이 좋음.

Downloader
   ↓
Content Type
   ├─ HTML Parser
   ├─ Image Processor
   ├─ PDF Parser
   └─ Video Processor

32. 유해하거나 불필요한 콘텐츠 처리

중복 콘텐츠

웹 페이지의 해시값이나 체크섬을 이용하여 중복 콘텐츠 탐지 가능.

Content
→ Hash
→ 기존 Hash와 비교

Spider Trap

Spider Trap은 크롤러가 끝없이 URL을 따라가도록 만드는 웹 구조임.

예:

/page?id=1
/page?id=2
/page?id=3
...

또는 URL이 계속 길어지는 구조:

/a
/a/a
/a/a/a
/a/a/a/a
...

대응 방법:

  • URL 최대 길이 제한
  • 페이지 깊이 제한
  • 비정상적으로 많은 URL을 생성하는 사이트 탐지
  • 반복 패턴 탐지
  • 문제가 지속되는 사이트를 차단 목록에 추가

URL 길이 제한만으로 모든 Spider Trap을 막을 수 있는 것은 아님.

데이터 노이즈

웹 페이지에는 실제 콘텐츠 분석에 도움이 되지 않는 정보도 많음.

예:

  • 광고
  • JavaScript 코드
  • 추적 코드
  • 스팸 URL
  • 반복 메뉴
  • 불필요한 UI 요소

이러한 데이터를 제거하면 저장 공간과 후속 처리 비용을 줄일 수 있음.

33. 전체 크롤링 흐름 정리

시작 URL
    ↓
URL Frontier
    ↓
우선순위 및 호스트별 스케줄링
    ↓
DNS 조회
    ↓
HTML Downloader
    ↓
Content Parser
    ↓
중복 콘텐츠 확인
    ↓
Content Storage
    ↓
URL Extractor
    ↓
URL Filter
    ↓
이미 방문한 URL인지 확인
    ↓
새 URL이면 URL Frontier에 추가
    ↓
반복

URL Frontier 내부에서는 다음 두 가지가 핵심임.

전면 큐
→ 어떤 URL을 먼저 크롤링할 것인지 결정

후면 큐
→ 특정 웹사이트에 요청이 몰리지 않도록 제어

대규모 웹 크롤러에서는 단순히 많은 페이지를 빠르게 다운로드하는 것뿐 아니라 우선순위, 신선도, 중복 제거, 크롤링 예절, 장애 복구를 함께 고려하는 것이 중요함.

profile
김연준
Live a life you will remember
이전 포스트

[대규모 시스템 설계 스터디] 8장 정리

다음 포스트

[대규모 시스템 설계 스터디] 10장 정리

0개의 댓글