9. 웹 로봇

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

1. 크롤러와 크롤링

웹 크롤러 : 웹페이지를 한 개 가져오고, 그 다음 그 페이지가 가리키는 모든 웹페이지를 가져오고, 다시 그 페이지들이 가리키는 모든 웹페이지들을 가져오는 일을 재귀적으로 반복하는 방식으로 웹을 순회하는 로봇

 

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

• 크롤러가 방문을 시작하는 URL들의 초기 집합을 루트 집합(root set) 이라고 부른다.
• 일반적으로 좋은 루트 집합은 크고 인기 있는 웹 사이트, 새로 생성된 페이지들의 목록, 그리고 자주 링크되지 않는 잘 알려져 있지 않은 페이지들의 목록으로구성되어 있다.
• 이 루트 집합은 시간이 지남에 따 라 성장하며 새로운 크롤링을 위한 시드 목록이 된다.

 

2. 링크 추출과 상대 링크 정상화

• 크롤러는 웹을 돌아다니면서 꾸준히 HTML 문서를 검색한다.
• 크롤러는 검색한 각 페이지 안에 들어있는 URL 링크들을 파싱해서 크롤링할 페이지들의 목록에 추가 해야 한다.
• 크롤러들은 간단한 HTML 파싱을 해서 이들 링 크들을 추출하고 상대 링크를 절대 링크로 변환할 필요가 있다.

 

3. 순환 피하기

• 로봇이 웹을 크롤링 할 때, 루프나 순환에 빠지지 않도록 매우 조심해야 한다.
• 로봇들은 순환을 피하기 위해 반드시 그들이 어디를 방문했는지 알아야 한다.

 

4. 루프와 중복

순환이 크롤러에게 해로운 이유

1. 순환은 크롤러를 루프에 빠뜨려서 꼼짝 못하게 만들 수 었다.
2. 크롤러가 같은 페이지를 반복해서 가져오면 고스란히 웹 서버의 부담이 된다.
3. 많은 수의 중복된 페이지를 가지고 있어서 크롤러 자신을 쓸모 없게 만들 수 있다.

 

5. 빵 부스러기의 흔적

• 어떤 URL을 방문했는지 빠르게 판단하기 위해서는 복잡한 자료 구조를 사용할 필요가 있고, 이 자료구조는 메모리 사용 면에서 효과적이어야 한다.

 

트리와 해시 테이블

• URl을 훨씬 빨라 찾아볼 수 있게 해주는 소프트웨어 자료 구조

 

느슨한 존재 비트맵

• URL은 해시 함수에 의해 고정된 크기의 숫자로 변환되고 배열 안에 대응하는 ‘존재 비트(presence bit)’를 갖는다.
• URL이 크롤링 되었을 때, 해당하는 존재 비트가 만들어진다.
• 존재 비트가 이미 존재한다면, 크롤러는 그 URL을 이미 크롤링 되었다고 간주한다.

 

체크 포인트

• 로봇 프로그램이 갑작스럽게 중단될 경우를 대비해, 방문한 URL 목록이 디스크에 저장되었는지 확인

 

파티셔닝

• 몇몇 대규모 웹 로봇은, 각각이 분리된 한 대의 컴퓨터인 로봇들이 동시에 일하고 있는 ‘농장(farm)’을 이용
• 각 로봇엔 URl들의 특정 ‘한부분’이 할당되어 그에 대한 책임을 진다.

 

6. 별칭(alias)과 로봇 순환

• 올바른 자료 구조를 갖추었더라도 URL이 별칭을 가질 수 있는 이상 어떤 페이지를 이전에 방문 했었는지 말해주는 게 쉽지 않을 때도 있다.
• 한 URL이 또 다른 URL에 대한 별칭이라면, 그 둘이 서로 달라보이더라도 사실은 같은 리소스를 가리키고 있다.

 

7. URL 정규화하기

• 대부분의 웹 로봇은 URL들을 표준 형식으로 ‘정규화’ 함으로써 다른 URL과 같은 리소스를 가리키고 있음이 확실한 것들을 미리 제거하려 시도
  1. 포트 번호가 명시되지 않았다면, 호스트 명에 :80’을 추가한다.
  2. 모든 %xx 이스케이핑된 문자들을 대응되는 문자로 변환한다.
  3. # 태그들을 제거한다.
• URL 정규화는 기본적인 문법의 별칭을 제거할 수 있지만, 로봇들은 URL을 표준 형식으로 변환하는 것만으로는 제거할 수 없는 다른 URL 별칭도 있다.

 

8. 파일 시스템 링크 순환

• 파일시스렘의 심벌릭 링크는 아무것도 존재하지 않으면서도 끝없이 깊어지는 디렉터리 계층을 만들 수 있기 때문에, 교묘한 종류의 순환을 유발할 수 있다.

 

9. 동적 가상 웹 공간

• 가상의 URL로 요청을 받으면 새로운 가상 URL을 갖고 있는 새 HTML 페이지를 날조하여 만들어 낸다.

 

10. 루프와 중복 피하기

• 잘 설계된 로봇은 순환을 피하기 위해 휴리스틱의 집합을 필요로 한다.
• 웹에서 로봇이 더 올바르게 동작하기 위해 사용하는 기법들은 다음과 같다.

URL 정규화

• URL을 표준 형태로 변환함으로써, 같은 리소스를 가리키는 중복된 URL이 생기는 것을 일부 회피

너비 우선 크롤링

• 방문할 URL들을 웹 사이트들 전체에 걸쳐 너비 우선으로 스케줄링하면, 순환의 영향을 최 소화할 수 있다.
• 그 순환에서 페이지를 받아오기 전에 다른 웹 사이트들에서 수십만 개의 페이지들을 받아올 수 있다.

스로틀링

• 로봇이 웹 사이트에서 일정 시간 동안 가져올 수 있는 페이지의 숫자를 제한
• 스로틀링을 이용해 서버에 대한 접근 횟수와 중복의 총 횟수를 제한 할 수 있다.

URL 크기 제한

• 로봇은 일정 길이(보통 1KB)를 넘는 URL의 크롤링은 거부할 수 있다.
• 이 기법을 적용하면 가져오지 못하는 콘텐츠들도 틀림없이 있을 것
• 요청 URL이 특정 크기에 도달할 때마다 에러 로그를 남김으로써, 특정 사이트에서 어떤 일이 벌어지는지 감시하는 사용자에게는 흘륭한 신호를 제공할 수있다.

URL/사이트 블랙리스트

• 함정인 것으로 알려진 사이트와 URL의 목록을 만들어 관리하고 그들을 전염병 피하듯 피한다.
• 블랙리스트는 크롤링 되는 것을 싫어하는 특정 사이트를 피하기 위해 사용될 수 있다.

패턴 발견

• 파일 시스템의 심벌릭 링크를 통한 순환과 그와 비슷한 오설정들은 일정 패턴을 따르는 경향이 있다.
• 몇몇 로봇은 반복되는 구성요소를 가진 URL을 잠재적인 순환으로 보고, 둘 혹은 셋 이상의 반복된 구성요소를 갖고 있는 URL을 크롤링하는 것을 거절

콘텐츠 지문(fingerprint)

• 콘텐츠 지문을 사용하는 로봇들은 페이지의 콘텐츠에서 몇바이트를 얻어내어 체크섬(checksum)을 계산
• 만약 로봇이 이전에 보았던 체크섬을 가진 페이지를 가져온다면, 그 페이지의 링크는 크롤링하지 않는다.
• 페이지 콘텐츠를 임의로 커스터마이정하는 것을 포함한 서버 측의 동적인 동작은 중복 감지를 방해 할 수 있다.

사람 모니터링

• 뭔가 특이한 일이 일어나면 즉각 인지할 수 있게끔 반드시 진단과 로깅을 포함하도록 설계되어야 한다.
• 문제를 예방 하기 위해 사람의 모니터렁에 더욱 의존

 

 

2. 로봇의 HTTP

• 로봇들은다른 HTTP 클라이언트 프로그램과 다르지 않으므로 HTTP 명세의 규칙을 지켜야 한다.
• 많은 로봇이 HTTP/1.0이 요구사항이 적기 때문에 HTTP/1.0 요청을 보낸다.

 

1. 요청 헤더 식별하기

• 로봇들이 HTTP를 최소한도로만 지원하려고 함에도 불구하고, 그들 대부분은 약간의 신원 식별 헤더(특히 User-Agent HTTP 헤더)를 구현하고 전송한다.
• 로봇 구현자들은 로봇의 능력, 신원, 출신을 알려주는 기본적인 헤더를 사이트에게 보내주는 것이 좋다.
  => 잘못된 크롤러의 소유자를 찾아낼 때와 서버에게 로봇이 어떤 종류의 콘텐츠를 다룰 수 있는지에 대한 약간의 정보를 주려 할 때 유용한 정보

 

2. 가상 호스팅

• 로봇 구현자들은 Host 헤더를 지원할 필요가 있다.
• 요청에 Host 헤더를 포함하지 않으면 로봇이 어떤 URL에 대해 잘못된 콘텐츠를 찾게 만든다.
  => HTTP/1.1은 Host 헤더를 사용할 것을 요구

 

3. 조건부 요청

• 로봇 중의 몇몇은 시간이나 엔터티 태그를 비교함으로써 그들이 받아간 마지막 버전 이후에 업데이트 된 것이 있는지 알아보는 조건부 HTTP 요청을 구현
  => HTTP 캐시가 전에 받아온 리소스의 로컬 사본이 유효성을 검사하는 방법과 매우 비슷

 

4. 응답 다루기

• HTTP의 특정 몇몇 기능(조건부 요청과 같은)을 사용하는 로봇들이나, 웹 탐색이나 서버와의 상호작용을 더 잘해보려고 하는 로봇들은 여러 종류의 HTTP 응답을 다룰줄 알 필요가 있다.
  => 대부분의 로봇은 GET 메서드만 사용한다.

상태 코드

• 일반적으로 로봇들은 최소한 일반적인 상태 코드나 예상할 수 있는 상태 코드를 다룰 수 있어야 한다.
• 모든 로봇은 200 OK나 404 Not Found와 같은 HTTP 상태 코드를 이해해야 한다.
• 그들이 명시적으로 이해할 수 없는 상태 코드는, 그 상태 코드가 속한 분류에 근거하여 다루어야 한다

엔터티

• HTTP 헤더에 임베딩된 정보를 따라 로봇들은 엔터티 자체의 정보를 찾을 수 있다.

 

5. User-Agent 타기팅

• 웹 관리자들은 많은 로봇이 그들의 사이트를 방문하게 될 것임을 명심하고, 그 로봇들로 부터의 요청을 예상해야한다.
• 사이트 관리자들은 로봇의 요청을 다루기 위한 전략을 세워야 한다.
• 로봇이 그들의 사이트에 방문했다가 콘텐츠를 얻을 수 없어 당황하는 일이 없도록 대비해야 한다.

 

 

3. 부적절한게 동작하는 로봇들

폭주하는 로봇

• 로봇은 웹 서핑을 하는 사람보다 훨씬 빠르게 HTTP 요청을 만들 수 있다.
• 로봇이 논리적인 에러를 갖고 있거나 순환에 빠졌다면 웹 서버에 극심한 부하를 안겨줄 수 있으며, 이것이 서버에 과부하를 유발하여 다른 누구에게도 서비스를 못하게 만드는 일도 있을 수 있다.
• 로봇 저자들은 폭주 방지를 위한 보호 장치를 신경 써서 설계해야 한다.

오래된 URL

• 웹 사이트가 그들의 콘텐츠를 많이 바꾸었다면, 로봇들은 존재하지 않는 URL에 대한 요청을 많이 보낼 수 있다.
• 존재하지 않는 문서에 대한 접근 요청으로 에러 로그가 채워지거나, 에러 페이지를 제공하는 부하로 인해 웹 서버의 요청에 대한 수용 능력이 감소할 수 있다.

길고 잘못된 URL

• URL이 충분히 길다면, 이는 웹 서버의 처리 능력에 영향을 주고,  웹 서버의 접근 로그를 어지럽게 채우고, 심지어 허술한 웹 서버라면 고장을 일으킬 수도 있다.

호기심이 지나친 로봇

• 어떤 로봇들은 사적인 데이터에 대한 URL을 얻어 그 데이터를 인터넷 검색엔진이나 기타 애플리케이션을 통해 쉽게 접근할 수 있도록 만들 수도 있다.
• 로봇의 구현자들은 사이트 구현자들이 인터넷을 통해 접근 가능하리라고 결코 의도하지 않았을 몇몇 특정 지점의 민감한 데이터를 그들의 로봇이 검색할 수 있다는 것에 주의해야 한다.

동적 게이트웨이 접근

• 로봇은 게이트웨이 애플리케이션의 콘텐츠에 대한 URL로 요청을 할 수도 있다.

 

 

4. 로봇 차단하기

• 로봇이 그들에게 맞지 않는 장소에 들어오지 않도록 하고 웹 마스터 에게 로봇의 동작을 더 잘 제어할 수 있는 메커니즘을 제공하는 단순하고 자발적인 기법이 제안되었다.(Robots Exclusion Standard)
• 웹 서버는 서버의 문서 루트에 robots.txt라고 이름 붙은 선택적인 파일을 제공하여 어떤 로봇이 서버의 어떤 부분에 접근할 수 있는지에 대한 정보를 기술한다.

 

1. 로봇 차단 표준

• 로봇 차단 표준은 임시방편으로 마련된 표준이다.
• 웹 사이트에 대한 로봇의 접근을 제어하는 능력은 불완전한 데가 있지만 없는 것보다는 훨씬 낫고 대부분의 주류 업체들과 검색 엔진 크롤러들은 이 차단 표준을 지원한다.

 

2. 웹 사이트와 robots.txt 파일들

• 웹 사이트에 robots.txt 파일이 존재한다면 로봇은 반드시 그 파일을 가져와서 처리해야 한다.
• 어떤 웹 사이트가 있을 때, 그 사이트 전체에 대한 robots.txt 파일은 단 하나만이 존재
• 웹 사이트가 가상 호스팅된다면, 다른 모든 파일이 그러하듯이 각각의 가상 docroot에 서로 다른 robots.txt가 있을 수 있다.

 

robots.txt가져오기

• HTTP GET 메서드를 이용해 robots.txt 리소스를 가져온다.
• robots.txt가 존재한다면 서버는 그 파일을 text/plain 본 문으로 반환
• 로봇은 사이트 관리자가 로봇의 접근을 추적할 수 있도록 From이나 User-Agent 헤더를 통해 신원 정보를 넘기고, 사이트 관리자가 로봇에 대해 문의나 불만사항 이 있을 경우를 위해 연락처를 제공해야 한다.

응답 코드

• 서버가 성공(HTTP 상태 코드 2XX)으로 응답하면 로봇은 반드시 그 응답의 콘텐츠를 파싱하여 차단 규칙을 얻고 그 사이트에서 무언가를 가져오려 할 때 그 규칙에 따라야 한다.
• 만리소스가 존재하지 않는다고 서버가 응답하면(HTTP 상태 코드 404) 로봇은 활성화된 차단 규칙이 존재하지 않는다고 가정하고 robots.txt의 제약 없이 그 사이트에 접근할 수 있다.
• 서버가 접근 제한(HTTP 상태 코드 401 혹은 403)으로 응답한다면 로봇은 그 사이트로의 접근은 완전히 제한되어 있다고 가정해야 한다.
• 요청 시도가 일시적으로 실패했다면(HTTP 상태 코드 503) 로봇은 그 사이트의 리소스를 검색하는 것은 뒤로 미루어야한다.
• 서버 응답이 리다이렉션을 의미한다면(HTIP 상태 코드 3XX) 로봇은 리소스가 발견될 때까지 리다이렉트를 따라가야 한다.

 

 

5. 로봇 에티켓

1993년, 웹 로봇 커뮤니티의 개척자인 마틴 코스터(Martijn Koster)는 웹 로봇을 만드는 사람들을 위한 가이드라인 목록을 작성했다.

 

 

6. 검색엔진

• 웹 로봇을 가장 광범위하게 사용하는 것은 인터넷 검색엔진이다.
• 오늘날 가장 유명한 웹 사이트들의 상당수가 검색 엔진이다.
• 웹 시용자들의 시작점인 동시에 사용자들이 관심 있는정보를 찾을 수 있도록 도와주는 매우 유용한 서비스를 제공

 

1. 넓게 생각하라

• 웹 전체를 크롤링하는 것은 쉽지 않은 도전

 

2. 현대적인 검색엔진의 아키텍처

• ‘풀 텍스트 색인(full-text indexes)’이라고 하는 복잡한 로컬 데이터베이스를 생성
  => 웹의 모든 문서에 대한 일종의 카드 카탈로그처럼 동작
• 풀 텍스트 색인은 기껏 해봐야 웹의 특정 순간에 대한 스냅샷에 불과하다.

 

3. 풀 텍스트 색인

단어 하나를 입력받아 그 단어를 포함하고 있는 문서를 즉각 알려줄 수 있는 데이터베이스

• 풀 텍스트 색인은 각 단어를 포함한 문서들을 열거

 

4. 질의 보내기

• 사용자가 질의를 웹 검색엔진 게이트웨이로 보내는 방법은, HTML 폼을 사용자가 채워 넣고 브라우저가 그 폼을 HTTP GET이나 POST 요청을 이용해서 게이트웨이로 보내는 식
• 게이트웨이 프로그램은 검색 질의를 추출하고 웹 UI 질의를 풀 텍스트 색인을 검색할 때 사용되는 표현식으로 변환

 

5. 검색 결과를 정렬하고 보여주기

• 검색엔진이 색인을 한번 사용했다면, 게이트웨이 애플리케이션은 그 결과를 이용해 최종 사용자를 위한 결과 페이지를 즉석에서 만들어낸다.
• 많은 웹페이지가 주어진 단어를 포함할수 있기 때문에, 검색엔진은 결과에 순위를 매기기 위해 똑똑한 알고리즘을 사용한다.
• 관련도 랭킹(relevancy ra dng) : 검색 결과의 목록에 점수를 매기고 정렬하는 과정
  => 이 과정을 더 잘 지원하기 위해, 많은 검색엔진이 웹을 크롤링하는 과정에서 수집된 통계 데이터를 실제로 사용한다.