プロキシのIPは実際どれだけ必要なのか

プロキシを買う前に最もよく聞かれる質問は、同時に間違った質問でもあります。重要なのはIPをいくつ持っているかではなく、リクエストがどう分散されているかです。

ほぼすべてのプロキシ購入の前に出てくる質問があります。IPはいくつ必要ですか、というものです。数字で答えが返ってくるべき類の問いに聞こえますし、その数字こそが仕事の成否を決めるように感じられます。しかし実際には、たいていの場合これは間違った質問であり、この問いから入るチームは往々にして間違ったものを買ってしまいます。スクレイピングがきれいに回るかどうかを本当に決めるのは、いくつのアドレスを保有しているかではなく、使っているアドレスのあいだでリクエストがどう分散されるか、そして個々のターゲットが一つのアドレスから気に留めるほどのトラフィックを見ることがあるかどうかです。

ここでは、この問題の正しい考え方を説明します。IPを数えることが本当に正しいアプローチになる唯一のケースも含めてです。

なぜこの問いの立て方が間違っているのか

IPを数えたくなる本能は、古い課金モデルの名残です。プロキシがポート単位や静的アドレス単位で売られていた頃は、決まった数のIPを買い、その数がそのまま容量でしたから、数えることに意味がありました。現代のレジデンシャルネットワークはそのようには機能しません。大きな共有プールから引き出し、触れたアドレスの数ではなく動かした帯域に対して課金され、結果として使う個別IPの数は、ローテーションをどう設定したかの帰結であって、事前に購入する数量ではありません。この転換はポート単位の時代が終わった理由でより詳しく扱っていますが、これこそが「IPはいくつ」という問いが、実際に購入する何かに対応しなくなった理由です。

この枠組みが誤解を招く理由はもう一つあります。ターゲットサイトはあなたのプールを見ていません。見ているのは自分の玄関口に届くリクエストであり、そのリクエストの振る舞いに基づいてアドレスごとに評価を形成します。一万個のIPがあっても、全体のトラフィックをそのうちのごく少数から送るような仕事は救われませんし、適度な数でもうまく分散されたアドレスなら、素朴な構成では回らない仕事を余裕でこなします。変数は分散であって、在庫ではありません。

必要量を実際に決めるもの

仕事に必要なものを決めるのは四つの要素です。順に見ていけば、答えは自ずと出てきます。

一つ目はターゲットあたりのリクエストレートです。すべてを合計した総リクエスト量ではなく、ある時間枠のなかで一つのサイトに何件送るかです。レート制限はIPごと、ターゲットごとに適用されるからです。二つ目は並行性、つまり同時に飛んでいるリクエストの数で、これが同時に使用されるアドレスの数を決めます。三つ目はセッション要件です。複数ステップのフローのためにIPを保持する必要があるかどうかで、これが実際の数え上げになる唯一のケースです。四つ目は地理的な広がりです。多くの市場をカバーする仕事は、どこか別の場所に集中した大きなプールではなく、それぞれの市場に量を分散させる必要があり、市区レベルのターゲティングが関わる場合、問うべきはその都市での可用性であって、ネットワーク全体の規模ではありません。

ローテーション作業のおおまかな計算

通常のローテーション収集では、有用な計算は「IPがいくつ存在するか」ではなく「各ターゲットで礼儀正しくあり続けるために、自分の量はいくつの個別アドレスに分散される必要があるか」です。

一つのサイトへのリクエストレートを取り、一つのアドレスから送ってよいレートで割ります。ある仕事が一つのターゲットへ毎時60,000件送っており、どのアドレスもそのターゲットへは20秒に1件程度、つまり毎時180件を超えないようにしたいなら、その量は任意の時点でおよそ330個の個別アドレスに分散される必要があります。入力のどちらかを変えれば答えも動きます。量を半分にすれば必要数も半分、各アドレスを遅くすればより多くが必要になります。ここでの数字は例示であり、ターゲットごとに許容されるレートは異なるので、具体的なサイトが実際に受け入れる水準に合わせて調整すべきですが、重要なのは計算の形です。あなたが解いているのは分散であり、プールは単に、対象市場において十分に大きく十分によく分散していて、それを供給できればよいのです。

まさにこれをロードバランシングが肩代わりしてくれますし、無制限の同時接続が見出しのIP数より重要なのもそのためです。効いてくる制約は、一つのアドレスが一つのサイトへ何件送るかであって、全体でいくつのアドレスが存在するかではありません。多数の異なるターゲットを叩いているなら、この計算はターゲットごとに適用され、五十のサイトに分散した量は、同じ量を一つに向けた場合よりはるかに負担が軽くなります。

本当に数えるべきケース: スティッキーセッション

数字が本当に正しい答えになる状況が一つだけあり、そこは正確に述べる価値があります。保持されたアイデンティティが必要な仕事、つまり複数ステップの検索、ログインフロー、チェックアウト的なシーケンス、あるいはサイトがリクエストをまたいで状態を追跡するプロセスでは、それら同時進行のフロー一つひとつが、フローが続くあいだ自分専用のIP上に自分専用のスティッキーセッションを必要とします。ここでの数え方は直接的です。同時に五十セッションなら、その瞬間に保持されるアドレスは五十、五百なら五百です。

つまり、この問いの正直な形は「IPはいくつ必要か」ではなく「同時に必要なスティッキーセッションはいくつか」であり、これはネットワークについての問いではなく、あなたのワークロードの形についての問いです。保持されたアイデンティティを必要としないものはすべてローテーションさせるべきです。ローテーションは負荷を自動的に分散しますし、ローテーションの仕組みはそのように使われるよう設計されているからです。

素のプールサイズが比較指標として弱い理由

プロバイダはプールサイズを宣伝しますが、その数字は大きすぎて意味のある比較が難しくなっています。見出しの数字より重要なものが三つあります。

まず、あなたの市場における分散です。本当に必要な国や都市で手薄な超大規模プールは、そこで密度の高い小さめのネットワークよりあなたの仕事にとって劣ります。つまり意味のあるプールサイズとは、収集している場所で利用可能な分だけです。次に品質です。フラグの付いたアドレスや使い過ぎのアドレスは、数がいくつあろうとチャレンジや歪んだレスポンスを招きます。だからこそIPレピュテーションは量よりも直接的に成功率に効きますし、レジデンシャルIPとは実際に何なのかを理解しておくと役に立ちます。三つ目は同時可用性です。重要なのはトラフィックを送るその瞬間に使えるものであって、ネットワークがこれまでに見たすべてのアドレスの累計ではありません。

実務上の帰結として、プロバイダをプールサイズで選ぶべきではありません。小さく購入して自分のワークロードを流し、測定してください。それが速度・成功率・位置精度のテストのガイドの目的です。

代わりに見積もるもの: 帯域

使ったアドレスではなく動かしたデータに課金されるのですから、予測する価値のある数字は帯域です。ターゲットのページサイズやレスポンスサイズを見積もり、収集予定の量を掛ければ、実際に支払う額に対応する数字が得られます。これが月間帯域の見積もりで示したアプローチです。同時に、最大のコストレバーが何かも明らかになります。それはIPの数ではありません。レンダリング済みのページ全体ではなく必要なものだけを取得することにこそ節約があり、それはプロキシ帯域コストの削減で扱っています。

設定の仕方

どちらのモードも同じgatewayから来ており、違いはユーザー名の一つのフィールドだけです。セッション識別子を省けばリクエストごとにローテーションします。ほとんどの収集はこれで行うべきです。

import requests

# Rotating: every request exits through a different address
ROTATING = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
r = requests.get("https://example.com/page",
                 proxies={"http": ROTATING, "https": ROTATING}, timeout=15)

# Sticky: one held IP per concurrent flow, counted per session
def sticky(session_id):
    url = (f"http://customer-USERNAME-country-us-sid-{session_id}:"
           f"PASSWORD@p.shifter.io:443")
    return {"http": url, "https": url}

# 50 concurrent flows means 50 distinct session identifiers
for i in range(50):
    proxies = sticky(f"flow{i}")
    # run one multi-step sequence on this held address

既定ではローテーションし、フローが本当に必要とする場合にのみセッションを保持し、固定のアドレス一覧を自分で管理しようとするのではなく、分散はプールに任せてください。

答えを検証する

どんな数字にたどり着いたとしても、それは出発点の仮説であり、信頼できる確認は測定だけです。ターゲットごと、地域ごとの成功率を見てください。低下は、アドレスあたりのレートがそのサイトに対して強すぎるという合図であり、データの欠落になるずっと前に現れます。それを与えてくれるのがパイプラインの監視です。経路が劣化したときはフェイルオーバーが、調整のあいだも仕事を止めずに走らせ続けます。そしてブロックが出ているなら、直し方はアドレスを増やすことより、ペース配分とリクエストの衛生であることのほうが多く、それがブロックの回避の中身です。

短いチェックリスト

最も負荷の高い単一ターゲットへ毎時何件送りますか。それをそのターゲットが許容するアドレスあたりのレートで割った値が、必要な分散のおおよその目安です。
保持されたアイデンティティを必要とする同時フローはいくつですか。それがスティッキーセッション数であり、口にする価値のある唯一の数字です。
どの国と都市が必要で、プールは全体として大きいだけでなく、その場所で密ですか。
どれだけのデータを動かしますか。それがコストを決める数字です。
見出しの数字を信じるのではなく、自分のワークロードで成功率を測りましたか。

まとめ

「IPはいくつ必要か」は、もはや当てはまらない課金モデルから受け継がれた問いです。現代の帯域課金のレジデンシャルネットワークでは、アドレスの個数を買うのではなく、プールへのアクセスを買い、そこを通して動かしたデータに対して支払います。ですから設計すべき対象は分散です。どの単一ターゲットも、どの一つのアドレスからも通常以上のトラフィックを見ることがない程度に広げること。量にはローテーションを使い、数えるのは同時スティッキーセッションだけにし、ネットワークは実際に収集する市場での密度と、自分のワークロードで出る成功率で判断し、予算はアドレスではなく帯域で見積もる。分散さえ正しくできれば、IPの数は考える必要のあるものではなくなります。

それこそがレジデンシャルプロキシが提供するために作られているものです。国別・都市別ターゲティング、既定のローテーション、そして必要なフローのためのスティッキーセッションを備えた、実在する家庭品質のIPの大規模なプールです。計画の軸にする価値がある数字はGB単位の料金です。足りることを願うアドレスの数量にではなく、実際に取得したデータに対して支払うことになるからです。