レジデンシャルプロキシ使用時のレイテンシー削減

レジデンシャルプロキシにはレイテンシーの下限がありますが、開発者が不満を訴える遅さの大半は回避可能です。プロキシのレイテンシーを削減する8つの手法を、効果の大きい順に紹介します。

レジデンシャルプロキシは直接接続よりも遅く、それはバグではありません。トラフィックは実在の家庭内ネットワーク上にある実在の消費者向けデバイスを経由してルーティングされ、これこそが実ユーザーとしての信頼を得るための仕組みであり、そのためにミリ秒単位のコストがかかります。そこには下限が存在し、どれだけチューニングしてもそれを下回ることはできません。

しかし、パフォーマンスに関する不満の多くが見落としているのはここです。人々が争っているレイテンシの大部分は下限ではなく、自分自身が付け加えたオーバーヘッドです。 リクエストのたびにハンドシェイクをやり直すこと、過度に制約されたジオフィルタ、肥大化したペイロード、リトライの嵐は、通常レジデンシャルのホップそのものよりもはるかに大きなコストとなります。このガイドでは削減不可能なものとそうでないものを切り分け、実際に数値を動かすテクニックを、おおよそ影響度の順に解説します。

まず、時間がどこに費やされているかを知る

プロキシ経由のリクエストは連鎖です。クライアント → ゲートウェイ → 出口デバイス → ターゲット、そして戻り。この時間は4つのバケツに分かれます。

接続確立 — ゲートウェイへのTCPハンドシェイク、CONNECTトンネル、そしてターゲットへのTLSハンドシェイク。これは通常、回避可能なコストの中で最大のものであり、新しい接続を張るたびに再度支払うことになります。
レジデンシャルのホップ — 実在の消費者向けデバイスとその家庭内ネットワーク。これが下限です。デバイスとネットワークの品質によって変動し、チューニングで取り除くことはできません。
ターゲットの応答時間 — サイト自体がどれだけ時間をかけるか。プロキシの責任ではなく、他を責める前に切り分ける価値があります。
リトライ — ブロックされたり、タイムアウトしたりしたリクエストを再試行しなければならない場合、それ自体のレイテンシがかかるだけでなく、実効的なレイテンシを何倍にもします。

固定されているのは2番目のバケツだけです。他の3つは最適化の対象です。

1. 接続を再利用する(単一で最大の勝ち筋)

まったく新しい接続はそれぞれ、プロキシを通じたハンドシェイクの全連鎖のコストを支払い、これは実際のリクエストそのものをはるかに上回ることも珍しくありません。コードがリクエストごとに新しい接続を作成しているなら、その税金を何度も支払っていることになります。

一回限りの呼び出しの代わりに、コネクションプーリングを備えたセッションやクライアントを使いましょう。

import os, requests

USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]
# Sticky session so the pooled connection stays on one exit IP
proxy_url = f"http://{USER}-country-us-sid-job1-ttl-600:{PASS}@p.shifter.io:443"
proxies = {"http": proxy_url, "https": proxy_url}

with requests.Session() as s:                 # pools + reuses connections
    s.proxies.update(proxies)
    for url in urls:
        r = s.get(url, timeout=30)            # handshake paid once, not per request

理解しておく価値がある落とし穴は、ローテーションと接続の再利用は互いに引っ張り合うということです。 リクエストごとに新しいIPへローテーションすれば、リクエストごとに新しい接続と新しいハンドシェイクが発生します。リクエストごとのローテーションが必要な場合は問題ありませんが、ローテーションをレイテンシと引き換えに買っていることを認識してください。

2. ワークロードが許す限りスティッキーセッションを使う

上記からの流れで、スティッキーセッション(sid + ttl)は1つの出口IPに固定し、これがプールされた接続を実際に再利用可能にします。すべてのリクエストごとではなく、ジョブごと、ターゲットごと、アイデンティティごとといった論理的な作業単位の間でローテーションしてください。

いずれにせよ1人のユーザーに見せるべき、複数のリクエストにまたがるフロー(結果のページネーション、複数ステップのページなど)であれば、スティッキーは正しい振る舞いでありかつより速い方法でもあります。適切なモードの選び方についてはスティッキーとローテーティングのレジデンシャルプロキシの比較を参照してください。

3. より速いリクエストを追い求めるのではなく、並行性でスケールする

リクエストごとのレジデンシャルのレイテンシには下限があるため、スループットを動かす方法は並列化であり、単一の呼び出しからミリ秒を削ることではありません。非同期処理はマイクロ最適化よりもはるかに大きな効果をもたらします。

import asyncio, httpx

async def fetch(client, url):
    r = await client.get(url, timeout=30)
    return r.status_code

async def main(urls):
    async with httpx.AsyncClient(proxy=proxy_url) as client:   # reused connections
        return await asyncio.gather(*(fetch(client, u) for u in urls))

ただし、並行性を無闇に上げてはいけません。1つのターゲットへの並列リクエストが多すぎると、レート制限や振る舞い検出に引っかかり、ブロックは(リトライという形で)節約できた並行性以上のレイテンシを消費します。ターゲットが許容するレベルを見つけ、それを下回るようにしましょう。

4. ジオフィルタを過度に制約しない

各ターゲティングフラグは、適格な出口IPのプールを狭めます。country + city + asn を積み重ねると、小さな集合から選択することになり、デバイスの数が減り、遅くなる可能性があり、失敗が増え、リトライも増えます。データが実際には必要としていないフィルタは緩めましょう。

ただし注意点があります。ユースケースがデータの正確性のために特定のロケーションを本当に必要とするなら、それは維持してください。正確性はスピードに勝ります。速くても市場を間違えた回答には価値がありません(都市レベルのターゲティングが重要になる場合)。使っていない精度のために税金を払わないようにするだけです。

5. 小さいペイロードは速いペイロード

ここではレイテンシとバンド幅の最適化は同じ作業です。回線を通過するバイト数が少なければ、転送時間も短くなります。HTMLやJSONエンドポイントにデータがある場合はブラウザレンダリングをスキップし、レンダリングが必須な場合は画像/メディア/フォントをブロックし、圧縮は有効にしておきましょう。完全なリストはプロキシの帯域幅コストを削減する方法にあり、そこにある項目はすべてリクエストを短縮すると同時に請求額も抑えます。

6. タイムアウトを設定し、素早く失敗する

停滞したリクエストはワーカーを固定し、テールレイテンシを引き延ばします。明示的な接続タイムアウトと読み取りタイムアウトを設定し、何かがハングした場合は60秒のデフォルトを待つのではなく、それを放棄して新しいIPで再試行してください。悪い出口で素早く失敗する方が、それが回復することを期待するよりもほぼ常に速いです。

7. ブロックされないことでリトライを減らす

これは見落とされがちなポイントです。ブロックされてリトライされたリクエストは、1回ではなく2〜3回分の往復のコストがかかるため、実効的なレイテンシは測定上のリクエストごとのレイテンシよりもはるかに悪くなります。ブロック率を下げることはレイテンシの最適化そのものです。質の高いIPを使い、現実的なヘッダーと一致するフィンガープリントを送信し、適切なペースを保ちましょう。スクレイパーがブロックされる理由とブロックを回避する方法を参照してください。

8. パーセンタイルを測定し、ターゲットを切り分ける

見えるものを最適化しましょう。平均ではなくp50とp95を追跡してください。テールこそが並行ワーカーを停滞させる要因であり、速い中立的なエンドポイントを実際のターゲットと並行して計測することで、プロキシのオーバーヘッドとターゲットの遅さを切り分けましょう。その方法はレジデンシャルプロキシの速度、成功率、ロケーション精度をテストする方法にあります。この切り分けなしでは、実はターゲットが遅かっただけなのに、プロキシのチューニングに1週間を費やすことになりかねません。

修正できないものと、それにどう対処するか

レジデンシャルのホップは下限です。完璧にチューニングしても、レジデンシャルはデータセンターのp50には及びません。なぜなら、設計上、実在の消費者向けデバイスが経路上に存在するからです。それがトレードオフです。防御されたターゲット上で本物のページを取得できる信頼と引き換えのレイテンシです(レジデンシャル対データセンター)。

もしワークロードが本当により低く一貫したレイテンシと安定したIPを必要とし、ローテーティングのレジデンシャルプールを必要としないのであれば、それはより速いレジデンシャル構成ではなく、別の製品を検討すべきというサインです。ISPプロキシはその中間に位置します。データセンター並みの速度とレジデンシャル登録のアドレスを兼ね備えています(中間的な選択肢)。正しいツールを選ぶことは、間違ったツールを過剰にチューニングすることに勝ります。

FAQ

レジデンシャルプロキシはなぜデータセンタープロキシより遅いのですか? トラフィックが家庭内ネットワーク上の実在の消費者向けデバイスを経由してルーティングされるため、設計上ホップが追加されるからです。このホップこそが、データセンターIPをブロックするサイト上で本物のユーザーとして見せる要因です。これは欠陥ではなく意図的なトレードオフです。

レジデンシャルプロキシのレイテンシを減らす最速の方法は何ですか? 接続を再利用することです。スティッキーIPを持つプールされたセッションは、リクエストごとではなく一度だけTCP/TLSハンドシェイクを支払います。これは通常、単純な構成における最大の回避可能なレイテンシの塊です。

IPをローテーションするとリクエストは遅くなりますか? はい、ある程度は。新しいIPは新しい接続と新しいハンドシェイクを意味するため、リクエストごとのローテーションは接続の再利用を放棄することになります。ユースケースが許すなら、リクエストごとではなく論理的な作業単位の間でローテーションしましょう。

厳しいジオフィルタは遅くなる原因になりますか? なり得ます。すべてのフィルタは適格なプールを狭めるため、country + city + ASNを組み合わせると出口が少数になり、遅いデバイスや失敗の増加につながります。データが実際に必要とする精度だけを保ち、それ以外は取り除きましょう。

プロキシとターゲットのどちらが遅いのかはどう見分けますか? 同じテストを、速く中立的なエンドポイントと、同じプロキシを通した実際のターゲットの両方に対して計測してください。その差がおおよそターゲット自体の応答時間です。平均ではなくp50とp95を測定してください。

まとめ

レジデンシャルプロキシには、チューニングで取り除けないレイテンシの下限がありますが、その上にあるものはほぼすべて自分でコントロールできます。接続を再利用し、作業が許す限りスティッキーセッションを使い、単一リクエストの速度を追い求めるのではなく並行性でスケールし、ジオを過度に制約せず、ペイロードを縮小し、停滞には素早く失敗し、そして何よりもブロックされないようにしましょう。なぜならリトライこそが実効的なレイテンシを支配するからです。そのうえでパーセンタイルを測定し、実際に痛手となるテールを最適化しましょう。

それを実践すれば、レジデンシャルプロキシの構成は現実的な上限に近いパフォーマンスを発揮します。それでも静的なIPでより低いレイテンシが必要な場合は、物理法則と戦うのではなくISPプロキシを検討してください。価格ページにはGB単位のプランがあり、自分のワークロードに対してどちらもテストできます。