Foundry
웹 크롤러 설계
심화
핵심

규칙 준수와 하지 않은 것

규칙을 못 받으면 가져오지 않는다

마지막으로 규칙 준수를 다룹니다. 요구사항에서 반드시 지킨다고 적었으므로 이것은 선택이 아닙니다.

규칙 확인이 예산을 먹는다

규칙 파일을 페이지마다 받으면 요청이 두 배가 되므로 호스트 단위로 캐시한다 페이지마다 규칙 파일을 받으면 규칙 페이지 규칙 페이지 요청이 두 배가 된다 예의 규칙이 초당 1회이므로 실제 수집은 절반이 된다 호스트 단위로 캐시하면 규칙 페이지 페이지 페이지 한 번 받아 재사용 규칙이 바뀔 수 있으므로 하루 정도로 다시 받는다 규칙을 못 받으면 가져오지 않는다. 모르면 멈춘다

규칙 파일을 페이지마다 받으면 요청이 두 배가 됩니다. 그리고 예의 규칙이 초당 한 번이므로 실제 수집량이 절반이 됩니다.

그래서 호스트 단위로 캐시합니다. 한 번 받아 그 호스트의 모든 주소에 적용합니다. 규칙이 바뀔 수 있으므로 하루 정도 지나면 다시 받습니다.

모르면 멈춘다

규칙 파일을 받지 못하면 어떻게 할지 정해야 합니다. 상대 서버가 응답하지 않을 때입니다.

선택결과
규칙이 없는 것으로 보고 가져온다금지된 곳을 긁을 수 있다
가져오지 않는다그 호스트를 잠시 놓친다

가져오지 않는 쪽을 고릅니다. 놓친 페이지는 나중에 가져올 수 있지만, 금지된 곳을 긁으면 차단되고 그 사이트를 영구히 잃습니다.

이 판단은 앞의 아키타입들에서 반복된 기준과 같습니다. 회복 가능한 실패를 고릅니다.

우리가 누구인지 밝힌다

요청에 크롤러 이름과 안내 주소를 담습니다. 그러면 사이트 운영자가 우리를 식별하고 규칙으로 조절할 수 있습니다.

이름을 밝히면 규칙 파일에서 우리만 따로 다룰 수 있다
안내 주소가 있으면 문제가 생겼을 때 연락이 온다

밝히지 않는 것이 더 위험합니다. 정체를 모르는 트래픽은 차단부터 당하고, 우리는 왜 차단됐는지도 모릅니다.

상대가 요청하면 멈춘다

사이트 운영자가 우리 크롤을 원하지 않는다고 알리면 그 시점에 멈춥니다. 대응이 느리면 신뢰를 잃고, 신뢰는 접근 가능한 사이트 목록이라는 자산과 같습니다.

그래서 신고에서 반영까지의 시간을 지표로 관리합니다. URL 단축기에서 도메인 평판을 관리한 것과 같은 구조입니다.

이 설계가 하지 않기로 한 것

후보결정과 근거
자바스크립트 실행하지 않는다. 페이지당 비용이 수십 배가 된다
전수 월 1회 재방문하지 않는다. 계산하면 예산의 세 배다
우선순위를 위해 예의 어기기하지 않는다. 차단되면 자산을 잃는다
함정 경로 완전 차단하지 않는다. 판정이 확실하지 않다. 뒤로 미룬다
규칙 파일을 못 받았을 때 진행하지 않는다. 회복 불가능한 실패다
중복 페이지 버리기하지 않는다. 링크는 여전히 쓸모가 있다

여섯 개가 모두 "하지 않는다" 입니다. 크롤러는 남의 서버를 쓰는 시스템이라, 할 수 있는 것보다 하지 않을 것을 정하는 일이 설계의 대부분입니다.

면접에서 이렇게 나옵니다

Q.규칙 파일을 어떻게 다루시겠습니까

호스트 단위로 캐시하고 하루 정도 지나면 다시 받습니다.

페이지마다 받으면 요청이 두 배가 되고, 예의 규칙이 초당 한 번이므로 실제 수집량이 절반이 됩니다.

한 번 받아 그 호스트의 모든 주소에 적용한다
규칙이 바뀔 수 있으므로 주기적으로 다시 받는다

캐시 기간은 규칙 변경 반영 속도와 예산의 균형점입니다.

흔한 실수: 규칙 확인을 비용이 없는 것으로 보는 것. 예의 규칙 때문에 규칙 파일 요청도 그 호스트의 초당 한 번을 씁니다. 크롤 예산과 같은 자원을 쓰는 요청입니다.

Q.규칙 파일을 받지 못하면 어떻게 하나요

가져오지 않습니다. 모르면 멈춥니다.

선택결과
규칙이 없는 것으로 보고 가져온다금지된 곳을 긁을 수 있다
가져오지 않는다그 호스트를 잠시 놓친다

놓친 페이지는 나중에 가져올 수 있지만, 금지된 곳을 긁으면 차단되고 그 사이트를 영구히 잃습니다.

앞의 아키타입들에서 반복된 기준과 같습니다. 회복 가능한 실패를 고릅니다.

흔한 실수: 응답이 없으면 제한이 없는 것으로 해석하는 것. 규칙 파일이 없는 사이트와 응답하지 않는 사이트는 다릅니다. 모른다는 상태를 허용으로 바꾸면 가장 위험한 방향으로 기웁니다.

Q.크롤러 신원을 밝히는 것이 왜 안전한가요

밝히지 않으면 차단부터 당하고 이유도 모릅니다.

요청에 크롤러 이름과 안내 주소를 담으면 사이트 운영자가 우리를 식별할 수 있습니다.

이름을 밝히면 규칙 파일에서 우리만 따로 다룰 수 있다
안내 주소가 있으면 문제가 생겼을 때 연락이 온다

연락이 오는 것이 큰 이득입니다. 차단당하기 전에 조절할 기회가 생깁니다.

흔한 실수: 차단을 피하려고 정체를 감추는 것. 단기적으로는 통하지만 패턴으로 감지되면 더 강하게 차단되고, 그때는 협의할 창구도 없습니다. 신뢰가 자산인 시스템에서 감추기는 자산을 버리는 선택입니다.

Q.이 설계에서 하지 않기로 한 것들을 말해 주세요

여섯 개가 모두 "하지 않는다" 입니다.

후보근거
자바스크립트 실행페이지당 비용이 수십 배
전수 월 1회 재방문계산하면 예산의 세 배
우선순위를 위해 예의 어기기차단되면 자산을 잃는다
함정 경로 완전 차단판정이 확실하지 않다
규칙 못 받았을 때 진행회복 불가능한 실패
중복 페이지 버리기링크는 여전히 쓸모가 있다

크롤러는 남의 서버를 쓰는 시스템이라, 할 수 있는 것보다 하지 않을 것을 정하는 일이 설계의 대부분입니다.

흔한 실수: 크롤러를 수집 성능 문제로 보는 것. 처리량은 계산해 보면 여유가 있고, 어려움은 남의 자원을 쓰면서 신뢰를 유지하는 것에 있습니다.

먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.

읽었으면 문제로 확인해보세요

웹 크롤러 설계 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.