これは、最初のレジデンシャルプロキシプロジェクトのための事前チェックリストであり、確認すべき事項を、修正コストが安く済む順に並べたものです。プロキシとは何かをおおよそ理解していることを前提としているので、そうでない場合はまず初心者のためのレジデンシャルプロキシを読んでから戻ってきてください。
これを順に確認していけば、最初のプロジェクトで数週間分のコストを浪費しがちな失敗、すなわち想定と異なるワークロード向けに規模を誤ったプラン、動いているように見えて実は何も収集していないジョブ、誰も予想していなかった請求額を避けられます。
コードを書く前に
1. レジデンシャルが本当に必要かを確認する。 ターゲットがトラフィックを精査しない場合、より安価なインフラで同じ仕事ができます。まず普通の接続とデータセンターアドレスの両方でターゲットを1つテストしてみてください。両方で動作するなら、プレミアム分のコストを節約できたことになります。比較についてはレジデンシャル対データセンターを参照してください。
2. ローテーティングか静的かを決める。 大量収集にはローテーティング、アカウントや長時間セッションなど何かを維持する必要がある場合には静的ISPアドレスを使います。ここで判断を誤ると、間違った方をさらに買い足しても解決しません。詳細は共有対専用を参照してください。
3. 対象となる市場を書き出す。 どの国が対象か、また市区町村レベルの精度が必要な作業があるかどうかです。これによってターゲティングの内容だけでなく、その市場でのプール規模を確認すべきかどうかも決まります。詳細は国別の利用可能性を参照してください。
4. プランを選ぶ前に帯域幅を見積もる。 レスポンスサイズ×リクエスト数に、リトライ分の余裕を加えます。最大の要因は、データエンドポイントを取得するのか、フルページをレンダリングするのかであり、これは100倍も違うことがあるため、まずそこを決めてください。詳細は月間帯域幅の見積もり方を参照してください。
最初の接続
5. 素のリクエストを動かす。 ターゲティングフラグなし、セッションなし、工夫も何もない状態で:
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonこれが失敗するなら、それ以外はまだ問題になりません。407は認証情報の誤りか不正な形式のユーザー名を意味します。すべてを取り除いて、一つずつ戻しながら確認してください。詳細は407エラーの修正を参照してください。
6. ローテーションを確認する。 上記のコマンドを何度か実行し、アドレスが変わることを確認します。変わらない場合、特にコマンドラインでは変わるのにコードでは変わらない場合、原因はほぼ確実にHTTPクライアントでのコネクション再利用であり、プロキシ側の問題ではありません。詳細はIPがローテーションしないを参照してください。
7. 地理的位置を確認する。 ある国を指定してリクエストし、2点を検証します。出口アドレスがその国を報告すること、そしてより重要な点として、地域判定に敏感なターゲットが、実際にそこにいるかのように現地通貨・現地言語で振る舞うことです。データベースとターゲット側の判断は必ずしも一致せず、重要なのはターゲット側の判断です。
8. HTTPとHTTPS両方のプロキシ設定を行い、特殊文字を処理する。 コード内では、HTTPとHTTPSの両方のエントリを設定してください。片方だけではいけません。また、URLで意味を持つ文字を含むパスワードはパーセントエンコードしてください。フォーマットの詳細は接続方法を参照してください。
規模を拡大する前に
9. リクエストを出口に合わせる。 素のUser-Agentだけでなく、完全なブラウザ形式のヘッダー一式を送り、Accept-Languageを出口国に紐づけて、両者が矛盾しないようにします。ブラウザを操作する場合は、ロケールとタイムゾーンも同様に合わせてください。詳細は適切なヘッダーの設定を参照してください。
10. ステータスコードではなくレスポンス本文を検証する。 これが、正常に動作するパイプラインと、静かに何も収集していないパイプラインを分けるチェックです。ターゲットごとに、本当に正常なページにしか現れないマーカーを定義し、それを通過した場合にのみレスポンスを成功としてカウントしてください。200を返すチャレンジページは、この作業において最もコストのかかる失敗です。詳細はブロックまたは偽コンテンツの検出を参照してください。
11. 規模拡大の前に、ペース調整と適切なリトライを追加する。 ターゲットごとのレート制限にジッターを加え、同時実行数の上限を設定し、失敗を分類してからループさせずに処理するリトライロジックを組みます。具体的には、同じペースを保つためにアドレスをローテーションするのではなくレート信号を待ち、終端的なエラーは絶対にリトライしないことです。詳細はレート制限とスロットリングとリトライロジックを参照してください。
12. コストのガードレールを設ける。 リクエストごとのバイト数を追跡し、プランの割り当てに達するかなり前にアラートを設定してください。最初のプロジェクトでよくある予想外の事態は、レンダリングジョブが3日で1か月分の帯域幅を消費してしまうことです。対策は帯域幅コストの削減を参照してください。
5分間の検証
何かを無人で動かしたままにする前に、以下をすべて短時間の実行で確認してください。
- 出口アドレスが自分自身のものではないこと
- セッションを要求していないときに、リクエストごとにアドレスが変わること
- 国が指定通りであり、ターゲット側もそれに同意していること
- 意図的に不正なリクエストが、成功としてカウントされずに失敗として分類されること
- リクエストごとのバイト数が、見積もりとおおよそ一致していること
- レート制限のレスポンスが即座のリトライではなく待機を引き起こすこと
これらのいずれかに問題があれば、今すぐ修正してください。1か月分のデータがその上に積み上がった後では、修正コストがかなり高くなります。
最初のプロジェクトでよくある間違い
トラブルの大半を占める4つです。
最初から全速力で動かす。 新しいパイプラインは通常、コードが許す限りの速さで動くように書かれがちですが、これはブロックされる最短経路です。ゆっくり始めて、意図的に速度を上げていってください。
ステータスコードを信頼する。 上で述べた通りですが、繰り返す価値があります。これは人々が見落としがちで、データセットを静かに損なう原因になるものだからです。
レンダリングが不要なページをレンダリングする。 ブラウザを自動化する前に、データが基盤となるエンドポイントから取得できないかを確認してください。詳細はヘッドレスブラウザが必要な場合を参照してください。
スティッキーセッションを保証されたものとして扱う。 セッションは実際の家庭用回線上ではベストエフォートであるため、フローはシーケンスの途中でアドレスが変わることに耐えられなければなりません。詳細はスティッキー対ローテーティングを参照してください。
まとめ
まずレジデンシャルが本当に必要かどうかを確認し、ローテーティングか静的かを意図的に選び、対象市場を書き出し、プランを選ぶ前に帯域幅の規模を見積もってください。次に、何かを追加する前に素のリクエストを動作させ、ローテーションと地理的位置を確認し、コード内でHTTPとHTTPS両方のプロキシ設定を行います。規模を拡大する前に、ヘッダーを出口と一致させ、ステータスコードではなくレスポンス本文を検証し、ペース調整と分類されたリトライを追加し、コストアラートを設定してください。無人で動かす前に5分間の検証を実行してください。コストのかかる最初のプロジェクトの失敗のほとんどは、これらのステップのいずれかを飛ばしたことに起因しており、それぞれ後から手を加えるより、今行うほうが安上がりです。
これらのステップが設定する対象となる製品がレジデンシャルプロキシです。国および都市単位のターゲティングとスティッキーセッションを必要に応じて備えた単一のゲートウェイで、GB単位で課金されるため、小規模な最初のプロジェクトは小規模な最初の請求額のままで済みます。