Post
EN

크롤링3

크롤러에게 의사 표시를 하기 위한 파일은 Robots.txt 파일이다.

robots.txt

항목

설명

User-agent

대상 크롤러를 나타냅니다.

Crawl-delay

접근 빈도를 나타냅니다.

Disallow

접근하지 않았으면 하는 경로를 나타 냅니다.

Allow

접근해도 상관없는 경로를 나타냅니다.

Sitemap

사이트맵 또는 사이트맵 인덱스 파일의 URL을 나타 냅니다.

크롤러를 만들 때 확인해야 하는 설정

User-agent에 작성된 수집 제외 대상 이름이 적혀 있는지 확인.

나의 크롤러 이름 : SampleCrawler.

업체 Robots.txt 의 User-agent : SampleCrawler <– 금지

그 밖의 내부 링크 수집 제한이나 페이지 링크 순회 허가 등 더 많은 설정 조건이 들어있다.

새 아이템 찾기

웹 사이트에 새로 공개된 콘텐츠에 “new” 또는 “신규” 등의 태그가 붙어 있는 경우가 있습니다. 이런 태그가 있거나 신규 콘텐츠 순서로 목록을 정렬할 수 있습니다.

무한루프

페이지 링크를 순회하면서 크롤링할 때 크롤링이 끝나지 않는 경우가 있습니다. 크롤러가 동일한 페이지에 계속 접근하며 무한 루프에 빠졌을 가능성을 생각해 볼 수 있습니다.

RSS

해당 사이트의 도메인 뒤에 /sitemap 을 입력하였을 때 나타나는 페이지들이 있다면 이것을 활용 할 수 있다.

크롤링 데이터 역시 변경된 값만 추출해서 저장하는 역할을 할 수 있다.

hash를 이용하여 비교 등.

콘텐츠를 캐시해서 통신 줄이기

크롤링으로 접근할 때에도 콘텐츠를 캐시하면 변경이 따로 발생하지 않은 콘텐츠를 한 번만 추출하게 만들 수 있습니다.

  1. 응답을 캐시해둡니다.

  2. 캐시한 정보의 유효 기간을 기록해둡니다.

이런 사전 준비를 해두면 어떤 콘텐츠의 캐시가 저장돼 있을 때 해당 캐시가 유효 기간 내에 있다면 다시 접근하지 말고 캐시를 사용하면 됩니다.

주목해야될 응답 항목에는 Expires 와 Cache-Control 헤더 이다.

Expires 헤더는 캐시 유효 기간을 나타냅니다. 이 시점 까지는 서버에 접근하지 않고 캐시한 콘텐츠를 사용하라는 의미입니다.

Cache-Control

디렉티브

설명

max-age

캐시 기간을 나타냅니다. 초 단위로 지정합니다.

no-cache

캐시한 콘텐츠가 지금도 유효한지 접근해서 확인한 후에 사용해야 됩니다.

no-store

캐시하면 안됩니다.

Expires 헤더와 Cache-Control 헤더에 max-age 디렉티브가 모두 지정돼 있다면 Cache-Control 헤더의 max-age 디렉티브가 우선됩니다.

유효 기간이 지났으면 서버에 이런 조건을 붙여 접근해야 합니다.

ETag 헤더와 Last-Modified 헤더에서 추출 할 수 있으므로 캐시할 때 함께 기록해야 합니다.

ETag 헤더는 URL이 나타내는 리소스가 같은지 확인할 때 사용합니다.

Last-Modified 헤더는 리소스의 최종 변경일을 나타냅니다.

이런 것을 검증자(validator)라고 부르며, 캐시의 유효 기간이 끝났는지 서버에 문의할 때 사용합니다.

유효성을 서버에 문의할 때 사용하는 요청헤더

응답 헤더

캐시의 유효성을 확인할 때 사용하는 요청 헤더

ETag

if-None-Match

Last-Modified

if-Modified-Since

Response res = Jsoup.connect(url) .header("If-None-Match", eTag) .header('If-Modified-Since", lastModified) .execute(); int statusCode = res.statusCode();

제거된 콘텐츠 판정하기

콘텐츠에 명시적으로 적혀 있는 기간 사용하기.

말 그대로 해당 크롤링 대상 웹 페이지에 나타나 있는 판매 기간을 가지고 판정하는 것.

대상 사이트를 정기적으로 크롤링하기

가장 간단한 방법은 대상 웹 사이트 전체를 정기적으로 크롤링하는 것 입니다.

대규모 웹 사이트는 모든 컨텐츠를 정기적으로 클롤링하는 것만으로도 시간이 꽤 걸립니다. 그래서 신규 데이터만 크롤링 하는 경우가 많이 있고, 크롤링한 데이터가 제거 된지는 알 수 없습니다. 따라서 삭제된 데이터를 판변할 수 있는 별도의 방법이 필요합니다.

인덱스한 URL을 정기적으로 확인하기

콘텐츠 접근시 404 Not Found나 401 Gone 같은 상태 코드를 응답합니다.

이런 상태 코드를 활용해 인덱스한 URL에 해당 코드가 리턴된다면 콘텐츠가 제거 된 것으로 판단하고 인덱스에서 제거 합니다.

목록 페이지에 URL이 존재하지 않은 경우 삭제된 것으로 판정하기

인덱스 처리한 URL을 정기적으로 확인하는 경우에도 확인할 페이지 수가 많다면 시간이 꽤 걸립니다.

각각의 콘텐츠에 접근하는 시간이 오래 걸린다면 생각을 바꿔 콘텐츠에 직접 접근하지 않고 확인 하는 방법을 고민해보는 것도 있다.

목록 페이지에서 인덱스된 페이지 링크가 존재하는지 판단하여 없다면 인덱스에서 제거하는 방법으로 사용할 수 있다.

웹 사이트의 변경 시점 및 변경 학습 빈도 학습하기

매주 무슨 요일에 관리하는 것 같다.

0시 ~ 00시에 접근하는 오류가 자주 발생한다.

특정 날짜에는 콘텐츠가 아예 올라오지 않는다.

** 명시된 변경일 찾기**

변경하는 요일 또는 시간을 명시하기도 한다.

오류

변경 빈도에 따라 크롤링 빈도 조정하기

크롤링 소요 시간을 기반으로 크롤러의 리소스 사용량 조절하기

// 2019.04.11

Jsoup을 이용하여 웹 페이지를 가져올 때 가끔 원하는 페이지를 스크래핑 하지 못하는 경우가 있는데,

이때 확인해보니 Jsoup Connection에 maxBodySize 필드가 있었다.

원하는 결과로 스크래핑이 되지 않는 경우 maxBodySize가 default size로 1mb 이기 때문에, 늘려주면 정상적으로 파싱이 진행 된다.

document = Jsoup.connect(URL) .userAgent(userAgent) .maxBodySize(5 * 1024 * 1024) .get();

This article is licensed under CC BY 4.0 by the author.