[가상 면접 사례로 배우는 대규모 시스템 설계 기초]9. 웹 크롤러 설계

https://product.kyobobook.co.kr/detail/S000001033116

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬 - 교보문고

1장 사용자 수에 따른 규모 확장성 : https://inhyeok-blog.tistory.com/40
2장 개략적인규모추정 : https://inhyeok-blog.tistory.com/41
3장 시스템 설계 면접 공략법 : https://inhyeok-blog.tistory.com/42
4장 처리율제한장치의설계 : https://inhyeok-blog.tistory.com/43
5장 안정해시설계 : https://inhyeok-blog.tistory.com/44
6장 키-값저장소설계 : https://inhyeok-blog.tistory.com/45
7장 분산시스템을위한유일 ID 생성기설계 : https://inhyeok-blog.tistory.com/46
8장 URL 단축기설계 : https://inhyeok-blog.tistory.com/47
9장 웹크롤러설계 : https://inhyeok-blog.tistory.com/48
10장알림시스템설계 : https://inhyeok-blog.tistory.com/49
11장뉴스피드시스템설계 : https://inhyeok-blog.tistory.com/50
12장채팅시스템설계 : https://inhyeok-blog.tistory.com/51
13장검색어자동완성시스템 : https://inhyeok-blog.tistory.com/52
14장유튜브설계 : https://inhyeok-blog.tistory.com/53
15장구글드라이브설계 : https://inhyeok-blog.tistory.com/54

 

이번 장에서는 웹 크롤러를 설계해본다. 웹 크롤러는 다음과 같은 목표로 사용되곤 한다.

- 검색 엔진 인덱싱

- 웹 아카이빙

- 웹 마이닝

- 웹 모니터링

 

요구사항

- 검색 엔진 인덱싱 용으로 사용

- 1달에 10억 개의 웹 페이지 수집

- 수집한 웹 페이지는 5년간 저장

- 중복 컨텐츠 무시

- 규모의 확장성, 안정성, 예절, 확장성을 확보한다.

 

개략적 규모 추정

- QPS = 10억 * 30일 * 24시간 * 3600초 = 400페이지/초

- Peak QPS = 2* QPS = 800

- 1달간 필요한 저장공간 = 10억 페이지 * 500k(웹 페이지의 평균 크기) = 500TB/월

- 5년간 데이터를 보관한다는 가정 하에 최종적으로 필요한 저장 공간 = 500TB * 12Month * 5년 = 30PB

 

기본적인 구조

우선 기본적인 설계를 살펴본다. 이미 직관적으로 이해가 되는 그림이지만, 각 파트에의 세부적인 부분에 대해서만 조금 이야기해보자.

-미수집 URL 저장소

아직 다운로드 하지 않은 URL을 저장 관리하는 컴포넌트다. FIFO Queue로 구현된다.

 

-콘텐츠 파서

웹 페이지를 다운로드하고 파싱과 검증을 통해 필요없는(또는 이상한) 페이지를 제외한다.

 

-중복 콘텐츠인가?

중복 컨텐츠는 해시 값을 비교하는 것을 통해서 중복을 제거한다.

 

-URL 추출기

HTML페이지를 파싱하여 링크들을 모두 골라낸다.

 

-URL 필터

접근 제외 목록, 오류 발생URL, 특정 콘텐츠 타입이나 파일확장자를 갖는 URL 등을 걸러준다.

 

-이미 방문한 URL?

부하를 줄이고 무한 루프를 방지하기 위해 이미 방문한 URL을 제외한다. 이는 블룸필터나 해시 테이블이 널리 사용된다.

 

상세 설계

DFS vs BFS

DFS를 사용해서 URL을 수집하면 어디까지 깊게 들어갈지 몰라서 선호하지 않는다. 따라서 크롤러는 주로 BFS를 사용하는데, 이도 2가지 문제가 있다. 

첫째로 하이퍼링크로 찾는 URL들은 기존 서버에게로 가는 요청일 확률이 아주 높아서, BFS의 FIFO Queue에 들어가는 URL들이 모두 기존서버일 확률이 높다. 이 수집하려는 사이트에 부하를 줄 수 있어서, 예의 없는 크롤러로 간주된다.

둘째로 BFS 알고리즘은 URL간에 우선순위가 없다. 하지만 페이지 중에서도 중요도를 판단해서 우선순위를 구별하는 것이 좋다.

 

미수집 URL 저장소

예의 있게  URL을 수집하기 위해 같은 호스트에 속하는 모든 URL은 같은 큐에 넣어두자. 그리고 각 큐를 순회하면서 크롤링을 하는 작업 스레드에게 URL 다운로드 작업을 요청한다. 이때 같은 호스트에 속하는 URL끼리는 시간을 두고 수집하기도 한다.

URL간의 우선순위를 두기 위해서 트래픽 양, 갱신 빈도, 페이지 랭크 등의 척도를 사용한다. 우선순위에 의해서 분리된 URL은 각각의 우선순위마다 정의되어있는 큐에 넣는다. 그 뒤로 각 큐에서부터 URL을 꺼내서 앞서 설면한 호스트별 큐에 넣게 된다. 

한번 수집된 페이지가 변경되는 경우도 있다. 이런 경우에는 우선순위에 따라 자주 재수집하거나, 웹 페이지의 변경 이력을 활용할 수 있을 것이다.

 

HTML 다운로더

HTML다운로더에 사용한 수 있는 성능 최적화 방법은 분산 크롤링, 도메인 이름 변환 결과 캐시, 지역성(크롤링 서버를 분산해서 물리적으로 가까운 서버에서 HTML을 다운받는 것), 짧은 타임아웃이 있다. 

 

안정성 확보 전략

안정 해시를 통한 분산 크롤러 서버를 관리하는 것과 크롤링 상태 및 수집 데이터를 저장해서 쉽게 해결하는 전략, 그리고 예외 처리와 데이터검증을 통해 안정성을 확보할 수 있다. 

 

확장성 확보 전략

앞서 보여준 설계에서 URL 추출기를 새로운 모듈로 갈아끼울 수 있도록 설계해서 새로운 형태의 콘텐츠를 지원하는 모듈을 확장할 수있다. 

 

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

1. 중복콘텐츠

해시나 체크섬을 통해 중복 콘텐츠를 탐지하자.

 

2. 거미 덫

예건케 다음과 같이 무한히 깊은 디렉터리 구조를 포함할 수 있다.

spidertrapexample.com/foo/bar/foo/bar/foo/bar/foo ...

이런 종류는 URL의 최대 길이를 제한하면 된다. 하지만 모든 종류의 덫을 피할 수 있는 해결책은 없다. 이런 덫이 설치된 사이트는 수작업으로 찾은 후 덫이 있는 사이트를 필터로 제안하는 방식이 주로 사용된다.

 

3. 데이터 노이즈

광고나, 스크립트 코드, 스팸 등의 가치없는 데이터는 최대한 제외해야한다.