Chapter 9. Web Robots
(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
✏️ 원문 번역
Robot Etiquette
In 1993, Martijn Koster, a pioneer in the web robot community, wrote up a list of guidelines for authors of web robots. While some of the advice is dated, much of it still is quite useful. Martijn’s original treatise, “Guidelines for Robot Writers,” can be found at http://www.robotstxt.org/wc/guidelines.html.
-
1993년에 웹 로봇 커뮤니티의 선구자인 Martijn Koster가 웹 로봇 저작자에 대한 지침을 작성하였습니다.
-
일부 지침은 구식이지만 대부분 여전히 유용한 것들입니다.
-
Martijn의 원본 논문인 "Guidelines for Robot Writers"는 http://www.robotstxt.org/wc/guidelines.html 에서 확인할 수 있습니다.
Table 9-6 provides a modern update for robot designers and operators, based heavily on the spirit and content of the original list. Most of these guidelines are targeted at World Wide Web robots; however, they are applicable to smaller-scale crawlers too.
-
Table 9-6은 원본 지침의 정신과 내용을 계승하여 로봇 설계 및 연산을 현대적으로 업데이트한 버전입니다.
-
대부분의 가이드라인은 World Wide Web 로봇에 초점을 맞추고 있지만 해당 지침은 소규모 크롤러에도 적용할 수 있습니다.
Identification
로봇 식별
HTTP User-Agent 필드를 사용하여 웹 서버에게 로봇의 이름을 알립니다. 웹사이트 관리자가 해당 로봇이 어떤 로봇인지 이해하는 데 도움을 줍니다. 일부 로봇은 User-Agent 헤더에 크롤링의 목적과 로봇 정책을 설명하는 URL을 포함하기도 합니다.
기기 식별
로봇이 DNS 설정과 함께 동작하도록 하여 웹사이트가 IP 주소를 호스트명으로 변환할 수 있도록 합니다(rDNS). 웹사이트 관리자가 로봇에 대한 책임을 소지한 기관을 식별할 수 있게 합니다.
연락처 식별
HTTP From 필드를 사용하여 연락할 수 있는 이메일 주소를 제공합니다.
Operations
주의를 기울여라
로봇이 각종 의문과 불만사항을 남길 수 있습니다. 보통 오동작하는 로봇으로 인해 발생하는 문제입니다. 저작자는 로봇이 올바르게 동작하고 있는지 유심히 지켜보아야 합니다. 만약 로봇이 24시간 동작하고 있다면 더 각별히 신경써야 합니다. 로봇이 잘 동작할 때까지 불철주야 인간의 모니터링이 필요할 수 있습니다.
필요 자원에 대비하라
로봇이 여정을 시작할 때 사람들에게 자신의 소속을 알려야 합니다. 로봇이 속한 기관이 네트워크의 대역폭 소모를 알고 필요한 자원을 사전에 준비하고자 할 수 있습니다.
모니터링과 로깅을 수행하라
로봇은 진단과 로깅 작업을 풍부하게 수행해야 합니다. 진단과 로깅을 통해 로봇의 여정을 추적하고 로봇 트랩을 식별하며 모든 작업이 올바르게 이루어지고 있는지 확인할 수 있습니다. 문제점과 불만사항이 발생하면 크롤러의 행동에 대한 상세한 로그가 로봇의 행위를 역추적하는 데 도움을 줄 수 있습니다. 단순히 웹 크롤러를 디버깅하는 것을 넘어 정당하지 않은 컴플레인에 대비하기 위해 중요한 요소입니다.
학습하고 적응하라
로봇이 각각의 크롤링을 통해 새로운 것을 학습할 것입니다. 적응을 통해 개선하고 실수를 회피할 수 있도록 합니다.
Limit Yourself
URL 필터링
URL이 이해할 수 없는 데이터나 관심 밖의 데이터를 가리키고 있다면 스킵하기를 원할 것입니다. 예를 들어 ".Z", ".gz", ".tar", ".zip"으로 끝나는 URL은 압축된 파일이나 저장소일 것이며, ".exe"로 끝나는 URL은 프로그램일 것입니다. ".gif", ".tif", ".jpg"로 끝나는 URL은 이미지일 것입니다. 목표한 데이터만을 확실히 가져올 수 있도록 합니다.
동적 URL 필터링
대체로 로봇은 동적 게이트웨이를 통해 생성된 콘텐츠를 크롤링하기를 원하지 않습니다. 로봇은 게이트웨이가 요구하는 형태로 포맷팅하여 쿼리를 날리는 방법에 대해 잘 알지 못합니다. 그 결과는 예측할 수 없거나 일시적일 수 있습니다. URL이 cgi나 ?를 포함하고 있다면 URL을 크롤링하지 않기를 원할 것입니다.
Accept 헤더 필터링
로봇은 HTTP Accept 헤더를 사용하여 자신이 이해할 수 있는 콘텐츠의 타입이 무엇인지 서버에 알려야 합니다.
robots.txt 준수
로봇은 사이트의 robots.txt 규칙 집합을 준수해야 합니다.
스로틀링
로봇은 각각의 사이트에 대한 접근 횟수와 시점을 고려하여 한 사이트에 너무 자주 방문하지 않도록 해야 합니다. 관리자가 로봇이 한 사이트에 자주 방문하는 것을 수상하게 여길 수 있습니다. 로봇이 수초마다 사이트에 방문하고 있다면 관리자는 화가 날지도 모릅니다. 로봇이 다른 모든 트래픽을 차단하며 빠른 시일 내로 사이트를 다운시킨다면 관리자는 격노할지도 모릅니다.
일반적으로 로봇은 분당 최대 요청 횟수를 제한하고 각 요청 사이에도 몇 초간의 인터벌이 있도록 해야 합니다. 더불어 사이트에 대한 최대 접근 횟수를 제한함으로써 루프를 방지해야 합니다.
Tolereate Loops and Dups and Other Problems
응답 코드 핸들링
리디렉션과 에러를 포함한 모든 HTTP 상태 코드를 처리할 준비가 되어있어야 합니다. 따라서 상태 코드를 로깅하고 모니터링해야 합니다. 한 사이트에 대하여 수차례의 실패 응답이 발생하는 경우 원인을 조사할 필요가 있습니다. 대체로 URL이 유효하지 않거나 서버가 로봇에게 문서를 제공하는 것을 거부하였을 가능성이 높습니다.
URL Alias 제거
URL을 표준형으로 변환함으로써 Alias를 제거하고자 노력해야 합니다.
공격적인 사이클 회피
사이클을 감지하는 것은 매우 어렵습니다. 크롤링 운영 프로세스를 피드백 루프처럼 다루는 것이 좋습니다. 문제의 결과와 해답은 다음 크롤링에 반영되어 크롤러가 더 잘 반복할 수 있게 해야 합니다.
트랩 모니터링
사이클 중에서는 감지하게 어렵게 일부러 악의적으로 만드는 것도 있습니다. 수상한 URL에 대한 접근 횟수가 많아지고 있는지 반드시 모니터링해야 합니다. 트랩일 가능성이 있습니다.
블랙리스트 관리
트랩, 사이클 등 문제가 있거나 로봇이 방문하지 않기를 원하는 사이트를 발견하면 블랙리스트에 추가하여 다음에 다시 방문하지 않도록 해야 합니다.
Scalability
공간을 고려하라
해결하려는 문제의 규모를 사전에 계산해야 합니다. 응용 프로그램이 로봇 작업을 완료하는 데 소모하는 메모리의 크기를 알면 깜짝 놀랄 것입니다. 웹은 매우 거대하기 때문입니다.
대역폭을 고려하라
사용 가능한 대역폭의 크기와 로봇 작업을 완료하는 데 소요되는 시간을 고려해야 합니다. 네트워크 대역폭의 실사용량을 모니터링하는 것이 좋습니다. 요청에 의한 대역폭이 응답에 의한 대역폭보다 훨씬 작다는 사실을 알게 될 것입니다. TCP 연결을 더 잘 활용하여 잠재적으로 대역폭 사용을 최적화하는 방안도 떠올릴 수 있습니다.
시간을 고려하라
로봇이 작업을 완료하기까지 소요되는 시간을 파악한 후 작업이 예상대로 진행되고 있는지 확인해야 합니다. 로봇이 예측을 벗어났다면 분석이 필요한 문제일 가능성이 있습니다.
분할 정복하라
대규모 크롤링의 경우 작업을 수행하기 위해 더 많은 하드웨어를 사용해야 할 가능성이 있습니다. 여러 개의 네트워크 카드를 가진 거대한 멀티프로세서 서버를 사용하거나 여러 개의 작은 컴퓨터가 협동하여 작업하는 것을 고려할 수 있습니다.
Reliability
철저하게 테스트하라
로봇을 세상에 선보이기 전에 내부적으로 철저히 테스트해야 합니다. 원격 테스트가 준비되었다면 작은 여정부터 시작합니다. 결과를 수집하고 성능과 메모리 사용량을 분석하여 더 큰 문제로 어떻게 확장할지 예측해야 합니다.
체크포인트
로봇은 실패 후에도 재시작 할 수 있도록 작업의 스냅샷을 저장할 필요가 있습니다. 소프트웨어적인 버그와 하드웨어 결함이 존재할 수 있습니다. 대규모의 로봇은 버그가 발생할 때마다 처음부터 시작하기 어렵습니다. 처음부터 체크포인트와 재시작 기능을 설계해야 합니다.
오류 복구
실패가 발생하더라도 로봇이 작업을 수행할 수 있도록 설계해야 합니다.
Public Relations
신속하게 답변하라
로봇으로 인해 많은 사람들이 화가 날 수 있습니다. 그들의 문의에 신속하게 답할 수 있도록 항상 준비해야 합니다. 로봇을 설명하는 웹 페이지 정책을 생성하여 robots.txt 파일을 작성하는 방법에 관한 상세한 지침을 포함해야 합니다.
납득 가능하게 이야기하라
로봇과 관련하여 여러분과 연락하려는 사람들 중에는 정보를 잘 아는 사람도 있지만 그렇지 않은 사람도 있습니다. 일부는 비정상적으로 화가 나 있을지도 모르고, 일부는 정신이 나간 것처럼 보일 수도 있습니다. 이 사람들과 로봇의 중요성에 대해 언쟁하는 것은 그다지 생산적이지 않습니다. Robots Exclusion Standard에 대해 설명한 뒤에도 여전히 불만이 많아 보인다면 문제의 URL을 즉시 삭제하고 블랙리스트에 추가하기를 권장합니다.
책임감을 가져라
대체로 웹마스터가 불만을 가지는 이유는 로봇에 대해 잘 모르기 때문입니다. 여러분이 즉시 전문적인 응답을 보낸다면 90%의 컴플레인이 신속히 해결됩니다. 반면 응답을 뒤로 미루고 로봇이 계속해서 사이트에 방문할 경우 상대방이 언성을 높이고 화를 낼 수 있습니다.
✏️ 요약
Robot Etiquette
- User-Agent 필드를 통해 로봇에 관한 정보를 전송하라
- 로봇의 rDNS 설정을 활성화하라
- From 필드를 통해 문의 가능한 이메일을 함께 전송하라
- 로봇이 잘 동작하는지 모니터링하라
- 필요한 컴퓨팅 자원에 대비하라
- 로깅을 통해 로봇의 작업을 추적하라
- 크롤링을 통해 새로운 것을 학습하고 적응하라
- URL을 필터링하여 목표한 데이터만 확보하라
- Accept 헤더를 통해 로봇이 이해할 수 있는 타입을 알려라
- robots.txt 파일을 준수하라
- 분당 최대 요청 횟수, 사이트 최대 접근 횟수, 요청 인터벌을 제한하라
- 모든 HTTP 상태 코드를 처리할 수 있게 하라
- URL Alias를 미리 제거하라
- 피드백을 통해 사이클을 회피하라
- 수상한 URL에 대한 접근횟수를 모니터링하여 트랩을 감지하라
- URL 블랙리스트를 별도로 관리하라
- 해결하려는 문제의 규모, 소요하는 대역폭과 시간을 사전에 고려하라
- 멀티프로세서와 병렬처리를 적극 활용하라
- 로봇을 철저하게 테스트한 후 출시하라
- 실패 후 재시작 지점(체크포인트)을 설정하라
- 실패가 발생하더라도 로봇이 작업을 수행할 수 있도록 설계하라
- 로봇에 불만을 품은 사람들에게 신속하게 답변을 전달하라
- 계속 화가 나 있다면 문제의 URL을 즉시 삭제하고 블랙리스트에 추가하라
✏️ 감상
감상 생략... 해석하는 데 진빠짐
ㅎㅎ..
