2013-12-01

とあるインフラエンジニアの独り言

SlideShareのスライドをダウンロードできるサイトを作りました。」の件を肴に、ちょっと独り言。

端的に言えば、ある人が「SlideShare がスライドダウンロードさせてくれないからダウンローダー作ったよ」とおっしゃってますが、それどうなのよ、から派生してスクレーパーとかマジやめてというお話。

規約の内容

まずは SlideShare の規約がどうなってるかですが、Terms of Service
You agree not to use or launch any automated system, including without limitation, "robots," "spiders," "offline readers," etc., that accesses the Site in a manner that sends more request messages to the SlideShare servers in a given period of time than a human can reasonably produce in the same period by using a convention on-line web browser. 
と書いてあります。てきとーに意訳すると、
人間が一般的なブラウザを使った場合に送るリクエストよりも早いペースでリクエストを送る「ロボット」や「スパイダー」、「オフラインリーダー」といったような自動化されたシステムを使用しない、または立ち上げないことに同意します。
ってところでしょうか。後続の文では検索エンジンのロボットに対する条件が書いてありますが、このダウンローダーは該当しないので割愛します。

ダウンローダーは規約違反?

世の中には次に読むであろうページのプリフェッチ、さらにはプリレンダリングまでするブラウザが存在するらしい、というかそんな自社製品があるような気がするので、"human can reasonably produce" すなわち普通の人間がブラウザを操作することによって要求しうる QPS は一般人が思ってるよりは大きいのですが、当該サイトがその妥当性を考慮してダウンロードリクエストのペースを調整しているか分かりません。

ということで規約違反がどうか外からは判断できませんが、ある程度の可能性はあると思っています。

実際、何が悪いの?

実際上は、SlideShare に送っている QPS はそんなに大したことないでしょうし、ちょっと行儀が悪いだけのオフラインリーダーぐらいのものでしょう。なので、多分 SlideShare が規約をたてに何かアクションを取る (e.g. アクセスブロックする) ようなことはないとおもいます。

ただ、この手の proxy とか scraper といった「一つのリクエストを受けて複数のリクエストを他サイトに投げる」サービスは、悪い人に使われると DoS の片棒を担がされたりする危険があるし、前述したような規約違反の可能性、そのほか著作権 (特に DMCA) 違反の可能性など色々面倒ごとがあるので、おおっぴらにやるのは避けたほうがいいよというだけの話です。

本当に言いたいこと

ここからは SlideShare の一件から離れて一般論。

そんでもって何故こんなこと書いてるかっていうと「ユーザーが見られるのをそのままダウンロードできるようにして何が悪い」的な意見が散見されるからです。

確かに、ある個人が wget や curl やらで一回だけプレゼンまるごとコピーするだけのレベルならそうですが、最初に参照した SlideShare の規約にあるように、そうしたものを自動化してサービスとして提供するのはちょっと待ってくださいな、とサービスを提供する側の人間は思ってるわけです。どのくらいの QPS なら妥当・常識的・礼儀正しくて、どのくらいの QPS だと悪用・非常識・お行儀悪いとみなされるかは様々ですが、少なくとも「ユーザーができることなら何やったっていい」という訳ではないということです。

それでもスクレーパーを書く人へ

せめて無駄な 404 Not Found とか起こさないようにしてください。たとえ 404 を返すだけでもコンピューターリソースを消費するんです。スクレーパーも誰かの役に立つのならいいんですが、404 を返すためにこちらがコンピューターリソースを浪費するなんてやってられません。

それでもスクレーパーを書く人へ (その2)

お行儀よい実装を心がけてください。4xx とか 5xx が返ってきたり、そもそも TCP レベルでコネクションが確立できない場合には、すぐにリトライするのはやめてください。特にこっちがちゃんと 429 (RFC6585)「お前リクエスト送りすぎだからペース落とせや」 って返してるのを無視されると、中の人が激おこぷんぷん丸になってしまうかもしれません。

またリトライするにしても、リクエスト queue コントロールをちゃんとして「元々予定していた QPS + リトライ分の QPS」を送りつけるなんてことをしないようにしてください。

それでもスクレーパーを書く人へ (その3)

リクエストに勝手なパラメーターを追加しないでください。多くの場合、リクエスト内の無関係なパラメーターは無視されるだけですが、CDN とか透過なキャッシュレイヤーがあった場合に、キャッシュの邪魔をする場合があります。

逆に、キャッシュを回避するためにわざとタイムスタンプっぽいパラメーターをつけてるのを見つけた日には、中の人が激おこスティックファイナリアリティぷんぷんドリームになっちゃうかも。

本当の本当に書きたかったこと

実は一度「激おこスティックファイナリアリティぷんぷんドリーム」ってブログに書いてみたかったんです。ただそれだけでここまで書きました。多分、数年後に読み返して恥ずかしい思いをするのは自分自身です。

0 件のコメント:

prometheusのrate()関数の罠

 久しぶりのAdventカレンダー挑戦、うまくいく気がしません。 閑話休題。実のところ、rate()関数というよりは、サーバー側のmetric初期化問題です。 さて、何らかのサーバーAがあったとして、それが更に他のサーバーBにRPCを送っているとします。サーバーBの方でホワイトボ...