Skip to content

Instantly share code, notes, and snippets.

@cottonn cottonn/crawling.md

Last active Dec 6, 2017
Embed
What would you like to do?

クローラ作成の際に考慮したいポイントについて

本記事は Webスクレイピング Advent Calendar 2017 - Adventar の6日目の記事です。滑り込みギリギリアウトでした。

誤字脱字等はTwitterまでお願いします。

はじめに

最近、Pythonの入門書などでクローリングやスクレイピングが取り上げられることが増えてきました。実際スクレイピングは、文字列の取扱などを含むためプログラミングの教材としても適しておりますし、CSVに落とし込めばデータ分析できるなど、活用の幅も広いです。

クローラとは、Webサイトの巡回プログラムです。典型的には、検索エンジンがインターネット上にあるWebサイトを索引付けするために用いられます。もし、スクレイピングを定期的に実行するならば、それはたぶんクローラだといえるでしょう。筆者は、個人および業務として、クローラを作成した経験があります。

筆者はこれまで、クローリングにおけるポリシーが正面から問われた経験はありませんでした。業務における案件ではクロール対象のURL集合や取得頻度は与えられていたし、趣味では非営利的で、かつ小規模あるいは1度きりのプログラム実行に留まっていたのです。今にして思えば、そのような面倒な部分は会社が巻き取ってくれたのだろうと想像しています。

大企業にてサービスの提供者がクローラを設置する場合、それなりのノウハウ(コンプライアンスなど)が社内にあるのだと想像でき、クローラ作成においても適切に処理できると考えられます。一方で、個人や中小企業がクローラを作成するときは、不適切なクローラを作成してしまうリスクがあります。そこで本記事では、個人の考慮すべきポイントを考えることを試みます。

robots.txt がわからないとき

クローラに関わる者にとってrobots.txtの存在は広く知られており、かつ遵守すべきプロトコルとしてよく知られています。

robots.txtは、

  • サーバ及びネットワーク資源の消費から、Webサイト所有者を保護する
  • 半個人的な領域(たとえば、テスト用のWebページなど)に存在するコンテンツが、検索エンジンにindexされるのを防ぐ

という目的で1994年に策定されたプロトコルです。robots.txt はプロトコル(関係者間の合意)であり、法律ではありません。しかし「守られるべき基準」として20年の歴史をもつプロトコルであり、基本的には遵守するのがよいでしょう。

ところが、robots.txtを読み込むだけでは、クローラ作成方針の判断がつかないことがあります。

例えば cookpad の robots.txt に、ディレイ間隔は定義されていません。

$ curl https://cookpad.com/robots.txt
# See http://www.robotstxt.org/wc/norobots.html for documentation on how to use the robots.txt file
User-agent: *
Disallow: /recipe/introduce_for_keitai/
Disallow: /recipe/introduce/
Allow: /

実は、このケースはありふれていて、他にもいくつかのサイトのrobots.txtを見て回ったかぎり、ディレイ間隔が定義されていることのほうが珍しいようです。

Yahoo! のトップページにおいては robots.txt がそもそも存在していません。このようなケースは大手では珍しいことですが、小規模なWebサイトでは、robots.txtを用意していない場合も多々ありそうです。

$ curl -v https://www.yahoo.co.jp/robots.txt
*   Trying 183.79.250.251...
* TCP_NODELAY set
* Connected to www.yahoo.co.jp (183.79.250.251) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.yahoo.co.jp
* Server certificate: Cybertrust Japan Public CA G3
* Server certificate: Baltimore CyberTrust Root
> GET /robots.txt HTTP/1.1
> Host: www.yahoo.co.jp
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Wed, 06 Dec 2017 14:19:25 GMT

クローラ稼働による影響を考慮する

では、 robots.txt が頼れない場合、どうすればいいでしょうか。

まず、クローラは人間を超えるリクエスト間隔を伴うため、相手のサービスに負荷をかけないようにしたいです。クローラのリクエスト頻度によっては、Webサイトに負荷がかかることが懸念されます。日本では、岡崎市立中央図書館事件の文脈を受け、「1秒に1回」という目安が認知されています。

今日のWebサイトは、強靭なインフラのもと運営されていることもしばしばであるため、個人レベルのクローラにおいて、サービスの負荷に影響するというのは(岡崎図書館の当時と比べれば)少なくなってきていると思いますが、無視できるほど小さなレベルにリクエスト間隔を抑えることは良いアプローチであるといえるでしょう。

連絡先をUser-Agentに記述するという方法もあります。たとえば、メールアドレスをUser-Agentに記述することで、Webサービスの運営者とのコミュニケーションが図れるかもしれません。

また、ややメタな話として、クローラで収集したデータの利用方法によって、問題が発生することがあることも考慮したいです。 クロールデータを(元のウェブサービスと異なる場所に)公開することによって、プライバシーの問題が起こる可能性があります。

まとめ

勢いで Webスクレイピング Advent Calendar に登録したものの、「スクレイピングについてとくに書くことないぞ・・・?」となってしまいました。スクレイピングのエンジニアリングは既に語られ尽くしている感があり、良書がたくさん出ております。そこで、クローラ周りの節度について思うところを書いたり、調べてみたりしましたが、正直荷が重く、難しかったのは否めませんでした。

合意されている基準としては robots.txt ぐらいなようで、残りの部分については目的次第となっているようです。クローラ開発の動機は様々であるということがまずひとつです(研究目的であることもあれば、事業目的であることもある)。インフラ側もどんどん進化していますからモダンなサービスは簡単には落ちないですし、逆にリッチなコンテンツのために重い処理をしているなどもあります。それらはクライアント側から想像するのも限界があるため、「サーバに負荷をかけないような具体的な基準」というのもなさそうです。

他者のデータをお借りするという性質上、個人としてはクローラ作成に尻込みしてしまいがちな側面があります。「迷惑をかけない」というのは非常に文脈次第なところがあり、これを正面から言語化しきることはできませんでしたが、クローラの開発にあたり、本記事(ポエム)が良いクローラを考える一助になれば幸いです。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.