【Scrapyクローラログ】クローリングにおけるログ出力の考え方【前編】

※本記事は「Scrapyにおけるログ出力設計のベストプラクティス【ログはMiddlewareに書こう】」という記事を書こうとしたらログ出力に関する思想だけの部分だけで1記事分ほどになってしまったので、そこだけ抽出したものです。「クローリングで扱うべきエラーログ」「Scrapyによる実装」についてはそれぞれ中編後編で記述しようと思います。

目次

1. 初めまして
2. Qiita Engineer Festaでマラソンを完走したい
3. クローリングにおけるログの重要性
   1. クローラにとってクライアントの仕様変更は辛い
   2. ビジネスにおけるクローリングデータの利点「鮮度」
   3. クローリングエラー=機会損失
   4. ∴ ちゃんとクローリングはモニタリングできる環境を整えようね！

初めまして

株式会社 Panta Rhei CEOのかずです。Pandasistaというハンネでツイッターをやっています。pandas大好きです。データも好き。

Qiita Engineer Festaでマラソンを完走したい

Qiita Engineer Festaという素敵なイベントがあります。

その中で投稿マラソンという素敵なコースが！！！
なんと「38記事書けば素敵な景品がもらえる！！」らしいです。

1日1記事でギリギリ達成みたいです。
本日は3報目！！！
みなさんの参考になるような弊ナレッジを少しでもお裾分けできたら幸いです！

クローリングにおけるログの重要性

クローリングとは「インターネット上に公開されているデータをコンピュータで自動的に収集する(小生解釈)」ことです。

クローリングシステムにおいて、ログは重要です。理由は、
クローラシステムの実装やアーキテクチャがどんなに完璧でも、クロール先の仕様変更ですぐに使い物ならなくなってしまうから。

クローラにとってクライアントの仕様変更は辛い

仕様変更はいろいろあります。

• URLディレクトリ構成の変更
• クラス設計の変更
• 実装技術の変更

そうなると、途端に今まで収集できていたデータが収集できなくなります。

もちろんクローラ実装側も、その手の仕様変更に対してロバストになる(≒ちょっとやそっとの変更をされてもデータを収集し続けられる)ように設計します。
具体例を挙げると、要素のパースをxpathによる相対的な記述方法にしたり、ページ遷移を「ボタンを押す」のではなく「URL直打ち」で行ったり等です。
ここら辺はある程度それなりの技術的対応があります。ここら辺のTips集も後日書きたくなったらまとめたいと思います。

一方で、それでも対応できない場合はクローラの修正が必要になってきます。

ビジネスにおけるクローリングデータの利点

ビジネスにおいてクローリングデータの利点は「データの鮮度が非常に良い」という点になります。
自社にデータのアセットが無い時、データの取得方法は概ね

• 他社(他者)から購入する
• 自社で作る
• クローリング

の3通りになります。
他社から仕入れる場合や自社で作る場合、実地調査などを行うためデータの充実度は高いですが、データの鮮度は良くないと言えます。
一方、自社のクローラを作成する場合、公開情報しか取得できないという制約から充実度という面では前者に劣りますがデータの鮮度は非常に高いです。場合によっては当日公開されたデータをその日のうちにビジネスで活用することができます。

まとめると以下のようになります。

データ取得方法	データの鮮度	データの充実度
他社から仕入れる	×	○
自社で作る	△	○
クローリング	◎	△

クローリングエラー=機会損失

データの鮮度が重要になるシーンは多々あります。

【例: ECサイトで商品を仕入れるような商流を持っている商社】
クローラによってECサイトのタイムセールや大幅値下げを検知し、仕入れ価格を大幅に抑えられるタイミングを伺う。

【例: 他社の求人媒体出稿を見て求人ソリューションを提案する人材会社】
クローラによって自社媒体ではないところからの求人出稿を検知し、その出稿主の求人ニーズをリアルタイムで把握する。

ゆえに、データの鮮度は本当に大切です。

ここで、クローリングエラーが起こってしまうと、すなわち新鮮なデータを取れない状態が続いてしまうと、

• 仕入れ価格を抑えられない
• 人材不足の企業にアプローチできない

ことを意味します。

すなわち機会損失です。

∴ ちゃんとクローリングはモニタリングできる環境を整えようね！

ここまで話した内容から、

「クローリングエラーは機会損失を意味するよ！」
「とはいえどんな完璧なクローラでもエラーは発生しうるよ！」

という帰結を得ます。

そんなとき、我々ができることは何でしょうか。

そうです。

「エラーロギング」
「エラーモニタリング」
「エラー通知実装」

です。何というか、SREっぽい思想です。

これらがしっかりできると、全レスポンス400からの仕様変更検知からのSlack通知からのクローラ改修といった手立てが打てるわけです。

まとめ

クローリングエラーは発生しちゃうしでもそれを放置するとビジネス的に機会損失になってしまうから、ログを出力してモニタリングしようね！！！！！！

追記

本記事では小生初めて文字にカラーリングをしてみました。読者の方々のQiitaUXを下げてるのか上げてるのかとても心配になっています。