スクレイピング用のプロキシ選びは、実際にはプロキシではなくターゲットに関する問題である。防御のないサイトとDataDomeの背後にあるサイトでは、必要な構成がまったく異なる。前者にレジデンシャルの料金を支払うのは無駄な出費であり、後者にデータセンターIPを向けるのは時間の無駄である。
このガイドでは、どのプロキシタイプがどのスクレイピング作業に適しているか、ブロックされずに運用する方法、そして生のプロキシよりもスクレイピングAPIの方が適している場合について解説する。
The Four Types, for Scraping
| Type | IP source | Speed | Block rate | Cost | Best-fit scraping job |
|---|---|---|---|---|---|
| Datacenter | ホスティングプロバイダ | 最速 | 防御されたサイトでは高い | 最安 | 無防備なサイト、API、大量取得 |
| Residential | 一般ISP、実際の家庭 | 中程度 | 低い | 中程度、GB単位 | 小売、旅行、検索、防御のある対象全般 |
| ISP | 一般ISP、データセンターホスト | 高い | 低〜中程度 | IPごと月額 | ログイン済みセッション、長時間実行するジョブ |
| Mobile | 携帯キャリア | 中〜低 | 最も低い | 最高 | 最も難しいターゲット、アプリAPI |
訂正しておく価値がある点がある。これとは逆の説明が広く出回っており、本記事も以前はそれを踏襲していた。データセンターIPはISPを経由して配布されるものではない。これらはホスティングおよびクラウドプロバイダに登録されており、一般のインターネットプロバイダを一切経由しない。まさにそれゆえに識別可能である。IPレンジが公開されているため、サイトは一目でそれらを分類できる。
ISPプロキシとモバイルプロキシはどちらもスクレイピングにおいて重要であるが、この種の比較では通常除外されがちである。スクレイピング対象にログインが絡む場合、ISPプロキシが答えとなる。アドレスが固定されたままだからだ。モバイルプロキシは、他のあらゆる手段を打ち破ってしまうターゲットに対する最後の手段である。
Rotation and Session Handling
ブロックされずに済むかどうかは、プロキシの種類よりもローテーション戦略の方が重要である。
リクエストごとのローテーションは、リクエストのたびに新しいIPを割り当てる。商品一覧、検索結果、ディレクトリ項目など、独立したページを収集する際のデフォルトとして適切である。単一のアドレスに不審なパターンが蓄積することがない。
スティッキーセッションは、通常1分から30分程度の一定時間、1つのIPを保持する。カーソルを伴うページネーション、ログイン後の処理、複数ステップのチェックアウトフローなど、リクエスト同士が依存関係にある場合はこれを使用する。途中でIPが変わるセッションはアカウント乗っ取りのように見え、チャレンジを受けることになる。
実用的なルールとしては、フロー内で継続性が必要とされない限りリクエストごとにローテーションし、必要な場合はそれをカバーできる最短のスティッキーウィンドウを保持する。
Request Rate and Concurrency
ほとんどのブロックは、プロキシの種類ではなくレートが原因で発生する。1秒間に20回サイトにアクセスするレジデンシャルIPは、10秒に1回アクセスするデータセンターIPよりも明らかに自動化されているとわかる。
- Per-IP rate. 防御されたサイトでは、各アドレスにつき2〜5秒に1回程度のリクエストに抑える。無防備なサイトでは、はるかに積極的に行うことができる。
- Concurrency. 全体のスループットは、同時に使用するアドレス数とIPごとのレートの積である。1秒あたり10リクエストを安全に得るには、10個のアドレスを3倍速く動かすのではなく、30〜50個程度のアドレスを同時に稼働させる必要がある。
- Randomise. 固定間隔はそれ自体が特徴として検出される。間隔にばらつきを持たせるためにジッターを加える。
- Back off on failure. エラー率が上昇した場合は、より強くリトライするのではなく速度を落とす。ブロックに向けてリトライを続けることが、緩やかなレート制限を完全な禁止に変えてしまう原因となる。
Headers and Fingerprints
IPはドアの前まで連れて行ってくれるだけである。その先ではリクエスト自体が正しく見える必要がある。
- Send a complete, coherent header set. 実際のブラウザは
Accept、Accept-Language、Accept-Encoding、User-Agent、Sec-Ch-Uaを一貫した組み合わせで送信する。他のヘッダーがないリクエストにUser-Agentだけが単独で存在するのは、強力なボットのシグナルとなる。 - Keep the header story consistent with the IP. ドイツのIPが
Accept-Language: en-USを送信するのは不整合であり、地域ターゲティングを行う際には避けるべきである。 - Match TLS and HTTP behaviour to the client you claim to be. 高度なシステムはTLSハンドシェイクやHTTP/2のフレーム順序をフィンガープリントとして利用するため、Chromeを名乗るPythonクライアントはヘッダーの内容にかかわらず検出可能である。
- Use a real browser when the page needs one. JavaScriptでコンテンツをレンダリングするサイトにはヘッドレスブラウザが必要であり、ヘッドレスブラウザにも管理すべき独自のフィンガープリントが存在する。
Modern Anti-Bot Systems
Cloudflare、DataDome、PerimeterX、AkamaiはIPブロックリストではない。これらはアドレスの評判、リクエストのフィンガープリント、挙動、JavaScriptチャレンジの結果を組み合わせてスコアリングする。
これには2つの帰結がある。IPをローテーションするだけではこれらを打ち破ることはできない。フィンガープリントが変わらないままだからだ。また、レジデンシャルIPは必要ではあるが十分ではない。最も見分けやすいシグナルを取り除くだけで、より難しいシグナルは残ったままになる。
これらに直面した場合:
- Read the response properly. チャレンジページを伴う403は429のレート制限とは異なり、異なる対処が必要である。ステータスコードだけでなく本文も確認する。
- Slow down first. レートは変更のコストが最も低く、実際の原因であることが多い。
- Move up the trust ladder. データセンターからレジデンシャルへ、レジデンシャルからモバイルへ。
- Render the challenge. サイトがJavaScriptの実行を要求する場合、単純なHTTPクライアントはどのIPを使おうと通過できない。
- Reconsider the approach. リトライにかかるコストがデータの価値を上回るターゲットであれば、戦い続けるよりもマネージドAPIの方が安価である。
Cost, Volume and When to Use an API
プロジェクトの見積もりは、ページの重量から始まる。一般的なHTMLページは0.5から2 MBであるため、100,000ページであればおよそ50から200 GBとなる。JavaScriptをレンダリングすると、スクリプト、スタイル、画像も取得することになるため、この数値は数倍に膨らむ。
実際に請求額を左右する数値はブロック率である。リクエストの40%が失敗してリトライする構成では、その帯域分を二重に支払うことになる。失敗率の高い安価なプロキシは、成功したページ1件あたりのコストで見ると、高価なプロキシよりも高くつくことが多い。
生のプロキシが適しているのは、スクレイパーを自ら制御でき、ターゲットを把握しており、単位あたりのコストを最小限に抑えたい場合である。マネージドAPIが適しているのは、ターゲットの反撃が激しい場合、ブラウザのフィンガープリントやチャレンジソルバーの維持が必要になる場合、あるいは資金よりもエンジニアリングの時間が乏しい資源である場合である。
ShifterのWeb Scraping APIは、プロキシのローテーション、JavaScriptのレンダリング、チャレンジを単一のリクエストの背後でまとめて処理し、SERP APIは検索結果に特化して同様の機能を提供する。検索結果は他の方法では維持が特に困難なターゲットの一つである。生のプロキシについては、レジデンシャルプロキシとISPプロキシがセッションの問題の両端をカバーしており、現在の料金は料金ページに掲載されている。
A Short Decision Framework
- Target has no bot protection で、安価に大量処理が必要な場合: データセンタープロキシ。
- Target rate-limits or challenges you、ログインは関与しない場合: ローテーティングレジデンシャル。
- Scrape requires a logged-in session、または1つのアイデンティティを保持し続ける必要がある場合: ISPプロキシ。
- Target defeats residential、またはアプリレベルのアクセスが必要な場合: モバイルプロキシ。
- Target costs more in maintenance than the data is worth: スクレイピングAPI。
実際のほとんどのプロジェクトでは、これらを組み合わせて使用する。収集作業はローテーティングレジデンシャルで行い、少数の認証が必要なダッシュボードはISPで処理し、どうしても不可能な1つのターゲットのみAPIを経由する。
Conclusion
スクレイピングに唯一絶対のプロキシというものは存在しない。ターゲットの防御の強さにタイプを合わせ、リクエスト同士が依存しているかどうかにローテーションを合わせ、ブロックが発生した際に最初に調整すべきものとしてリクエストレートを扱うべきである。
より広範な分類についてはプロキシの種類を、ユースケースの詳細についてはWebスクレイピングの概要を参照のこと。