初めてプロキシを購入する人の多くは、「どのプランにするか」という単一の問いとしてこれを捉え、価格だけで決めてしまいがちです。その結果は大抵、二つのうちどちらかになります。作業の途中で容量不足に気づく小さすぎるプラン、あるいは容量を見込んで購入したのに結局使われないプランです。どちらも本当は価格設定の失敗ではありません。これらは、価格を見る前に済ませておくべき二つの決定を飛ばしたことから生じています。
適切な選択とは、順序立てた三つの決定です。プロジェクトにどの種類のプロキシが必要か、そのプロジェクトが実際にどれだけ帯域を消費するか、そして単に列挙されているだけでなく本当に必要な機能はどれか。これらを正しく押さえれば、プランは自ずと決まります。
決定その一：プロジェクトにどの製品が必要か
製品タイプは、同じものの階層ではありません。それぞれ振る舞いが異なり、選択を誤ってもそれを多く買うことでは解決できません。
ローテーティングレジデンシャルは、データ収集のデフォルトです。実際の家庭用アドレスの大きなプールから引き出し、デフォルトでは各リクエストが異なるアドレスを経由するため、ボリュームが分散され、単一のアドレスが注目を集めることはありません。作業がスクレイピング、価格や在庫の監視、SERPやランキング収集、広告検証、あるいは多数のターゲットや市場にまたがる多数のリクエストという形のものであれば、これを選んでください。
静的レジデンシャル、あるいはISPプロキシは、コンシューマー向けインターネットプロバイダーに登録されたホスト型アドレスであり、レジデンシャル相当の信頼性を保ちながら時間が経っても変わりません。ボリュームではなく持続性が要件である場合、これを選んでください。常に同じアドレスから見られるべきアカウントの管理、長期間続くセッション、あるいはアドレスが足元で変わってしまうことが解決策ではなく問題そのものであるような場合です。このトレードオフについてはISPとレジデンシャルの比較と静的レジデンシャルプロキシとは何かで扱っています。
データセンターは最も安価で最速であり、ターゲット側が気にしないのであれば、それが正しい答えです。オープンなAPI、自分のインフラ、あるいは意味のある防御を持たないサイトを対象にしているなら、レジデンシャルの価格を払うのは無駄です。正直な比較はレジデンシャルとデータセンターの比較にあります。
実用的なルールは、実際のターゲットを確実に突破できる最も安価なタイプを使うことであり、それは推測ではなくテストによって確立することです。多くのプロジェクトは結局混在型になります。簡単なソースにはデータセンター、防御されているものにはレジデンシャルです。
決定その二：帯域はどれだけ必要か
レジデンシャルプロキシは、触れるアドレスの数ではなく転送されたデータ量で課金されるため、帯域がプランを決める数値になります。このモデルの背景にある理由はポート単位課金の時代が終わった理由にあり、サイジングの方法は単純です。
ターゲットからのレスポンスの平均サイズを見積もり、月間に見込むリクエスト数を掛け、再試行や失敗の分の余裕を加えます。プレーンなHTMLページやJSON APIのレスポンスは通常数十キロバイトですが、画像、フォント、スクリプトを含めてブラウザでレンダリングされたフルページは数メガバイトになることがあり、これが計算全体の中で最大の変動要因です。1日1万件のJSON呼び出しと、1日1万件の完全にレンダリングされたページとでは、まったく異なるプランになり、その差はおよそ2桁に及びます。詳しい算出方法は月間帯域の見積もり方にあります。
購入前にこの数値を減らせる要素が二つあります。ページ全体をレンダリングするのではなく、根底にあるデータエンドポイントを取得することが最大のてこであり、本当にレンダリングが必要な場合には画像、メディア、フォントをブロックすることが二番目の手段です。どちらもプロキシの帯域コストを削減する方法で扱っています。この最適化はプランをサイジングする前に行う価値があります。それによってティアを一段階下げられることがあるからです。
このリストに含まれていないものに注目してください。取得するIPの数です。プールされたネットワークでは、それは購入する量ではありません。その理由は実際に必要なプロキシIPの数にあります。唯一の例外は同時実行スティッキーセッションであり、作業が保持されたアイデンティティを必要とする場合には明示すべき本当の要件です。
決定その三：実際に必要な機能はどれか
機能一覧のせいで、プランは複雑に見え始めます。しかしその大半は五つの問いに集約されます。
地理的な粒度。 国レベルのターゲティングでほとんどのプロジェクトはカバーできます。作業がローカルな検索結果、地域別価格、店舗レベルのデータに依存する場合は市区町村レベルのターゲティングが必要であり、キャリア固有の挙動を扱う場合はASNターゲティングが必要です。単に大きなグローバル数値が宣伝されているだけでなく、重視する国が十分にカバーされているかを確認してください。
セッション制御。 リクエストごとにローテーションできることと、複数ステップのフローが必要とする場合にスティッキーセッションを保持できることの両方を確認してください。実際のほとんどのプロジェクトでは、異なる場面で両方が必要になります。
同時実行数。 同時接続に適用される上限を確認してください。同時実行数を個別に計測するプランは、帯域のみで計測するプランなら快適に動く作業をスロットルしてしまう可能性があります。無制限の同時接続を参照してください。
プロトコルと統合。 HTTPとSOCKS5でほとんどのケースをカバーできます。より重要なのは、ターゲティングがリクエストごとにあなたのスタックから駆動できる形で表現されていることであり、ゲートウェイ方式ではダッシュボードの切り替えではなくユーザー名に認証情報を含める形になります。
それ以外のすべては、規模を拡大して運用するようになるまでは通常は二次的なものであり、その段階に達すると、サポートの応答性や請求の柔軟性が、どの機能項目よりも重要になり始めます。
一般的なプロジェクト形態とプランの対応
最初の購入の大半は、いくつかのパターンでカバーできます。
小規模なリサーチや監視プロジェクト、毎日数百ページを追跡する程度であれば、通常は国別ターゲティング付きのローテーティングレジデンシャルで月間数ギガバイトです。見積もりに余裕を持って対応できる最小のティアから始めてください。後から上げるのは簡単ですが、まだ検証していないプロジェクトのために大きなティアを購入するのはそうではありません。
多数のターゲットにわたる本番運用のスクレイピングパイプラインでは、帯域見積もりがその真価を発揮し、最適化作業が直接元を取ります。推測ではなくトライアルでの実測使用量に基づいてサイジングし、実際の数値が見積もりと両方向にずれることを想定してください。
アカウントやセッションベースの作業は、大きなローテーティングプールではなく、静的なISPアドレスと明示された同時セッション数を指し示します。
混在型のワークロードはよくあることで、問題ありません。防御されていないソースにはデータセンター、それ以外にはレジデンシャルです。それぞれを個別にサイジングする方が、すべてを高価な経路に通すよりも安く済みます。
導入前に検証する
どのような結論に至ったとしても、それを仮説として扱い、規模を拡大する前にトライアルまたは小規模な最初の購入でテストしてください。汎用的なテストURLではなく実際のターゲットで実行し、ステータスコードだけでなくレスポンスの検証を伴って成功率を測定してください。そうしなければ、200で返されたチャレンジページが成功のように見えてしまいます。支払った地理条件が実際に得られる地理条件と一致することを確認してください。リクエストあたりの実際のバイト数を測定し、帯域の見積もりを実測値に変えてください。この方法は速度、成功率、位置精度のテスト方法にあり、プロバイダーレベルの基準はプロキシネットワークの選び方にあります。
1週間の実際の使用は、どんな仕様書よりも多くを教えてくれ、上記の三つの決定すべてを見積もりから事実へと変えてくれます。
結論
製品タイプは価格ではなくターゲットの要求によって選んでください。ボリュームと地理にはローテーティングレジデンシャル、持続性には静的ISP、ターゲット側が気にしない場合はデータセンターです。プランは帯域でサイジングしてください。つまりレスポンスサイズにリクエスト量を掛けて見積もり、購入前に取得内容を最適化することです。それだけでティアを一段階動かせることがあります。プロジェクトが実際に使う機能だけを要件とし、地理的な粒度とセッション制御という、最も頻繁に問題になる二つを重視してください。そして規模を拡大する前に実際のターゲットで検証してください。実測された使用量は、どんな見積もりにも勝ります。
もしそれがローテーティングレジデンシャルを指し示すなら、レジデンシャルプロキシは国と市区町村のターゲティング、デフォルトのローテーション、フローが必要とする場合のスティッキーセッションを提供し、GB単位の価格設定により、座席数やポート割り当てではなく実際に移動させるデータに応じてプランが決まります。