요구사항과 예산 계산

예산을 초로 바꾸고 예의 규칙과 곱해 봅니다.

월 10억 페이지 은 초당 약 386페이지입니다. 노드 100대 이면 노드당 초당 4페이지라 처리량은 부담이 아닙니다.

그런데 한 호스트에서는 초당 한 번만 가져올 수 있으므로 최소 386개 호스트를 동시에 다뤄야 합니다.

빠르게 가져오는 문제가 아니다
다룰 호스트를 늘 충분히 확보하는 문제다

흔한 실수: 처리량과 대역폭을 병목으로 잡는 것. 계산해 보면 둘 다 여유가 큽니다. 무엇이 병목이 아닌지 말하지 않으면 뒤에서 그쪽을 최적화하게 됩니다.

페이지 하나당 비용이 수십 배가 되어 예산을 감당할 수 없습니다.

브라우저를 띄워 실행하면 메모리와 시간이 크게 늘어납니다. 월 10억 페이지 규모에서는 그 비용을 낼 수 없습니다.

대가는 자바스크립트로만 만들어지는 내용을 못 보는 것입니다. 요구사항에 적어 두면 그 한계를 알고 쓰게 됩니다.

흔한 실수: 중요한 사이트만 실행하겠다고 덧붙이는 것. 좋은 방향이지만 중요도를 어떻게 정하는지가 새 문제입니다. 요구사항 단계에서는 범위 밖으로 두고, 필요해지면 별도 설계로 다룹니다.

지키지 않으면 차단되고, 차단되면 그 사이트를 영구히 못 봅니다.

크롤러의 자산은 접근 가능한 사이트 목록입니다. 예의가 그 자산을 지킵니다.

그리고 이 규칙이 설계를 정합니다. 호스트당 초당 한 번이라는 제약이 곧 동시에 다뤄야 하는 호스트 수를 정하기 때문입니다.

흔한 실수: 예의를 나중에 붙이는 옵션으로 보는 것. 이 규칙은 처리량 구조를 결정하는 제약이라 설계의 처음부터 들어가야 합니다. 나중에 붙이면 큐 구조를 다시 만들게 됩니다.

다룰 호스트 수, 주소 목록의 크기, 저장 비용입니다.

처리량: 노드당 초당 4페이지. 부담 없다
대역폭: 초당 386페이지 x 500KB. 감당 가능하다
호스트 수: 초당 386개를 동시에 다뤄야 한다

주소 목록은 크롤한 페이지보다 훨씬 크게 자랍니다. 페이지 하나에서 여러 주소가 나오기 때문입니다.

저장은 월 500TB이고 중복을 걸러내지 못하면 몇 배가 됩니다.

흔한 실수: 크롤러를 대역폭 문제로 보는 것. 계산해 보면 여유가 있습니다. 이 설계의 어려움은 조율과 관리이고, 그것을 먼저 말하면 뒤의 개념들이 자연스럽게 이어집니다.