[HTTP 완벽가이드] 9장 웹 로봇 > 9.1 크롤러와 크롤링 [1/2]

[HTTP 완벽 가이드] 9장 웹 로봇 > 9.1 크롤러와 크롤링

 

서론

웹 로봇 = 스스로 움직이는 사용자 에이전트. 사람과의 상호작용 없이 연속된 웹 트랜잭션들을 자동으로 수행하는 소프트웨어 프로그램

웹 사이트 to 웹 사이트 떠돌아다니며 콘텐츠 가져오고, 하이퍼링크 따라가고, 발견한 데이터 처리하는 주체.

'크롤러', '스파이더', '웜', '봇' 등의 이름으로 불림.

HTTP 완벽가이드, 인사이트, p.250. 순환 예시 (A,B,C 노드로 구성된 그래프 안에 갖히게 된다.)

 

9.1 크롤러와 크롤링

웹 크롤러는, 일단 웹 페이지 하나 가져오고, 그 페이지가 가리키는 모든 웹 페이지를 다시 가져오는 과정을 반복하면서 웹을 순회하는 로봇. 웹 링크를 재귀적으로 따라가는 로봇을 크롤러 혹은 스파이더라고 부르는데, 하이퍼링크들로 만들어진 웹을 따라 기어 다니기(crawl) 때문.

검색엔진은 웹에서 만나는 모든 문서를 끌어오기 위해 크롤러를 사용함. 나중에 처리되어 DB화 되는데, 이를 통해 사용자들이 특정 단어를 포함한 문서를 찾을 수 있게 됨.

 

9.1.1 어디에서 시작하는가: '루트 집합'

크롤러 풀어놓기 전에 우선 출발지점을 주어야 하는데, 방문을 시작하는 URL들의 초기 집합이 루트 집합(root set)

웹의 대부분을 커버하기 위해 루트 집합에 너무 많은 페이지가 있을 필요는 없음.

일반적으로 좋은 루트 집합은 크고 인기 있는 웹 사이트, 새로 생성된 페이지들의 목록, 그리고 자주 링크되지 않는 잘 알려져 있지 않은 페이지들의 목록으로 구성됨. 인터넷 검색엔진에서 쓰이는 대규모 크롤러는 사용자들이 루트 집합에 새 페이지나 잘 알려지지 않은 페이지들을 추가하는 기능을 제공한다. 그리고 이 루트 집합은 시간이 지남에 따라 성장하며 새로운 크롤링을 위한 시드 목록이 된다.

 

(블로그 링크들이 루트 집합에 포함되지는 않겠지만, 어쨌든 블로그 개설 이후 색인 요청하는 것도 이런 원리에서 기인한 것! 나 블로그 만들었으니 긁어가라~~라고 알려주기)

HTTP 완벽가이드, 인사이트, p.248. URL 루트 집합

9.1.2 링크 추출과 상대 링크 정상화

각 페이지 안에 들어있는 URL 링크들을 파싱 해서 크롤링할 페이지 목록에 추가. 크롤링 진행하며 탐색해야 할 새 링크를 발견함에 따라 목록이 급속히 확장됨. 그래서, 크롤러들은 간단한 HTML 파싱을 통해 링크들을 추출하고 상대 링크를 절대 링크로 변환할 필요가 있음.

 

9.1.3 순환 피하기

루프나 순환에 빠지면 (cyclic), 계속 같은 웹 페이지들만 크롤링하게 되기 때문에, 피해야 함.

순환을 피하기 위해 반드시 어디를 방문했는지 알아야 함. 

HTTP 완벽가이드, 인사이트, p.250. 순환 예시 (A,B,C 노드로 구성된 그래프 안에 갖히게 된다.)

9.1.4 루프와 중복

순환이 크롤러에게 악영향을 끼치는 대표적 이유 세 가지 (그냥 단순하게 생각해봐도 cyclic 하게 갇혀있으면 전파가 안 되니까 안 좋지...!)

• 순환은 크롤러를 루프에 빠뜨려서 꼼짝 못 하게 만듦. 같은 페이지 계속 가져오는 멍청한 크롤러가 네트워크 대역폭을 다 차지하는데, 결국 아무 페이지도 가져오지 못하는 상황 발생 가능.
• 같은 페이지 반복해서 가져오면 결국 부담은 웹 서버로 온다! 크롤러 속도가 빠르면, 웹 사이트의 실제 사용자가 접근 못하게 막아버릴 수도 있음. 의도치 않은 디도스 공격 ㄷㄷ
• 일단 같은 페이지 계속 가져오면 그거 자체로 중복 콘텐츠로 넘쳐나게 된다. > 검색창에 검색어 입력했는데 똑같은 페이지들만 계속 나오면, 쓸모없는 검색 엔진이 되는 거지.

 

9.1.5 빵 부스러기의 흔적

근데, 방문한 곳을 지속적으로 추적하는 것은 쉽지 않음.

전 세계 웹 콘텐츠 상당 부분을 크롤링하려고 한다면, 진짜 어마어마한 수백억 개의 URL을 방문해야 할 것임. 근데 그걸 추적한다고?? 오우... 단순한 방법으로 힘들지. 그래서, 어떤 URL을 방문했는지 빠르게 판단하기 위해서는 복잡한 자료 구조 사용이 필요함. 시간 & 공간 복잡도 두 가지 측면에서 최대한 효율적인!

빠르게 결정하기 위해서는 적어도 검색 트리 or 해시 테이블 필요.

URL이 평균 40바이트 길이라고 가정하고, 5억 개의 URL을 크롤링했다면, 방문한 URL들을 유지하기 위해 20GB 메모리가 필요함.

(요새 20GB 정도면 괜찮다고 느껴지지만 책이 쓰일 시점을 생각하면... 크흠)

 

트리와 해시 테이블

방문한 URL 빨리 찾아보게 하는데 유용한 자료구조 맞지 ㅇㅇ

 

느슨한 존재 비트맵

공간 사용을 최소화하기 위해, 몇몇 대규모 크롤러에서는 존재 비트 배열(presence bit array)과 같은 느슨한 자료 구조 사용.

각 URL은 해시 함수에 의해 고정된 크기의 숫자로 변환되고 배열 안에 대응하는 '존재 비트(presence bit)'를 갖게 됨.

URL이 크롤링될 때, 해당하는 존재 비트가 만들어지는데, 만약 존재 비트가 이미 존재하면 크롤러는 그 URL을 이미 크롤링됐다고 간주.

 

체크포인트

크롤러가 갑자기 중단될 경우를 대비하여, 방문한 URL 목록이 디스크에 저장되었는지 확인.

메모리에만 들고 있다가 갑자기 프로세스 중단되면 다 날아가니까, 중간에 한 번씩 저장한다는 의미인 듯.

 

파티셔닝

웹 공간이 너무 방대해지다 보니, 한 대의 컴퓨터에서 하나의 로봇이 크롤링 다 하는 것은 사실상 불가능. 대규모 웹 로봇은 여러 봇이 동시에 일하는 농장(farm) 형태로 운영됨. 각 로봇에게 크롤링해야 할 URL들의 특정 '한 부분'이 할당되어 그에 대한 책임을 지는 형태. 로봇끼리 서로 도와서 웹 크롤링 진행. 각 로봇들끼리 URL 넘겨주고, 오동작하는 로봇 있으면 도와주고, 어쨌든 각자 진행상황 체크를 위한 커뮤니케이션을 진행하며 병렬적으로 작업이 진행됨.

 

9.1.6 별칭(alias)과 로봇 순환

URL이 별칭을 가질 수 있는 이상, 어떤 페이지를 이전에 방문했는지 판단이 어려울 수 있음. 그리고 한 URL이 다른 URL에 대한 별칭이라면?? 그 둘이 달라 보여도 결국 같은 리소스를 가리키고 있는 것.

 

예시

HTTP 완벽가이드, 인사이트, p.253. 같은 문서를 가리키는 다른 URL들의 예시.