9. 웹 크롤러 설계

1. 문제 이해 및 설계 범위 확정

  • URL 집합이 입력으로 주어지면, 해당 URL들이 가리키는 모든 웹 페이지를 다운로드 한다.

  • 다운받은 웹 페이지에서 URL들을 추출한다.

  • 추출된 URL들을 다운로드할 URL 목록에 추가하고 위 과정을 처음부터 반복한다.

  • 웹 크롤러는 단순하지 않음. 그러므로 설계 범위를 좁히는 것이 중요

    • 크롤러의 주된 용도는?

    • 얼마나 많은 웹 페이지를 수입해야함?

    • 새로 만들어진 웹페이지나, 수정된 웹페이지도 고려?

    • 수집한 웹페이지는 저장?

    • 중복된 콘텐츠는?

  • 좋은 웹 크롤러가 만족해야할 속성

    • 병행성

    • 비정상적인 입력, 환경에 잘 대응

    • 짦은 시간 너무 많은 요청을 보내서는 안됨

    • 확장성

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

  • QPS= 10억

    • 대략 400페이지 / 초

  • 최대 QPS = 2 * QPS = 800

  • 웹페이지 크기 , 500k

  • 10억 페이지 x 500k = 500TB/월

    • 5년간 보관 30PB

2. 개략적 설계안 제시 및 동의 구하기

![[Pasted image 20250928160739.png]]

시작 URL 집합

  • 웹 크롤러가 크롤링을 시작하는 출발점 미수집 URL 저장소

  • 다운로드할 URL을 저장하는 컴포넌트

  • URL Frontier

  • FIFO (First in First Out)

HTML 다운로더

  • 인터넷에서 웹 페이즈를 다운로드 하는 컴포넌트

도메인 이름 변환기

  • 웹 페이지를 다운받으려면 URL을 IP주소로 변환하는 절차가 필요

콘텐츠 파서

  • 웹 페에지를 다운로드 하면 파싱 - 검증 절차를 거쳐야함.

중복된 콘텐츠?

  • 효과적인 방법은 웹페이지의 해시 값을 비교하는 것

콘텐츠 저장소

  • HTML 문서를 보관하는 시스템

  • 데이터양이 너무 많다 -> 디스크에 저장

  • 인기 있는 콘텐츠는 메모리에 두어 접근 지연 시간을 줄임

URL 추출기

  • HTML 페이지를 파싱하여 링크를 골라내는 역할

URL 필터

  • 특정한 콘텐츠 타입이나 파일 확장자를 갖는 URL,

  • 접속시 오류가 발생하는 URL ,

  • 접근 제어 목록에 포함된 URL,

  • 크롤링 대상에서 배제하는 역할

이미 방문한 URL

  • 블룸 필터 or 해시 테이블 을 통해서 이미 방문한 URL을 판단

URL 저장소

  • 이미 방문한 URL을 보관하는 저장소

3. 상세 설계

DFS vs BFS

  • Depth First Search, Breath First Search

  • DFS는 좋은 선택이 아닐 가능성이 높다.

    • 왜?

    • 어느 정도로 깊숙이 가게 될지 가늠하기 어려워서

  • 그러므로 BFS 대부분 사용

    • BFS는 FIFO 큐를 사용하는 알고리즘

    • 이 큐 한쪽으로는 탐색할 URL을 집어넣고, 한쪽은 꺼내기만 하면 됨.

  • 표준적인 BFS는 URL간에 우선순위를 두지 않암.

    • 처리 순서에 있어서 모든 페이지를 공평하게 대우

    • 하지만 모든 웹 페이지가 같은 품질, 같은 수준의 중요성은 아님.

    • 그러므로 우선순위를 두는 것이 타당 (사용자 트래팩의 양, 업데이트 빈도 등)

미수집 URL 저장소 ![[Pasted image 20250928162248.png]]

  • 잘 이해 안됨.

HTML 다운로더

  • Robots.txt

  • 성능 최적화

    • 분산 크롤링

    • 도메인 이름 변환 결과 캐시

      • DNS Resolver는 보통 병목 중 하나 (10ms ~ 200ms)

    • 지역성

      • 크롤링 작업을 수행하는 서버를 지역별로 분산

    • 짦은 타임아웃

      • 서버가 응답하지 않으면 크롤러는 해당 페이지를 다운로드 중단하고 다음 페이지로 넘어가도록

  • 안정성

    • 안정해시

    • 크롤링 상태 및 수집 데이터 저장

    • 예외 처리

    • 데이터 검증

  • 확장성

문제 있는 콘텐츠 감지 및 회피

  • 중복 콘텐츠

    • 해시, check-sum 사용

  • 거미 덫

    • 크롤러를 무한 루프에 빠뜨리도록 설계한 웹 페이지

    • 이를 자동으로 피해가는 알고리즘을 만들어내는 것은 까다로움

  • 데이터 노이즈

    • 가치 없는 콘텐츠는 제외한다.

4. 마무리

  • server-side rendering

    • 많은 웹사이트가 자바스크립트 기술을 사용해서 링크를 즉석에서 만들어냄.

    • 그러므로 있는 그대로 웹페이지를 다운 받는 다면 동적으로 생성되는 링크를 발견 못함.

  • 원치 않는 페이지 필터링

    • 스팽 방지 컴포넌트 두는게 좋음

  • 데이터베이스 다중화 및 샤딩

    • 가용성, 규모 확장성, 안정성이 향상됨.

  • 수평적 규모 확장성

    • 다운로드를 실행 할 서버가 수백 혹은 수천대 필요하게 될 수도 있음.

    • Stateless 서버로 만들어서, 규모 확장성이 가능하도록 한다.

참고

  • https://gngsn.tistory.com/201

  • https://redis.io/docs/latest/develop/data-types/probabilistic/bloom-filter/

Previous8. URL 단축기Next나는-AI와-공부한다

Last updated

Was this helpful?