リクエスト単位のプロキシ料金

何に支払うのか

事業者が数えるリクエスト数に対して支払います。固定パッケージの場合も、利用量に応じた課金の場合もあります。価格は1,000件や1,000,000件単位で表示されることが多く、比較には便利ですが、購入時の支払額を示すとは限りません。最小パッケージには、それ以上の件数が含まれる場合があります。

同じ「リクエスト」という言葉でも、サービス内容は異なります。通常のプロキシはアプリの要求をサイトへ転送し、応答を返すだけで、ページ読み込みとデータ抽出はアプリが行います。データ収集APIでは、ブラウザーの実行、アクセス制限への対処、結果の整形も価格に含まれる場合があります。単価だけでなく、その価格で何を行うかを確認する必要があります。

日程に沿う作業では便利な方式です。確認ページ数と頻度が分かっているなら、次に1回の確認に必要なリクエスト数を調べます。月間の必要量と、ページを増やした際の利用量増加を見積もれます。

応答サイズは、必ずしも料金を左右しません。全リクエストが同一料金なら、1つの応答で多くのデータを取っても、小さな応答と同じ費用の場合があります。ただし、帯域幅、応答サイズ、実行時間の上限があるかもしれません。データの追加処理も別料金の場合があるため、含まれる内容を確認してください。

リクエストパッケージは、受け取るIP数を決めません。たとえばローテーションサービスは、共通エンドポイントからIPプールへアクセスできます。IP変更やセッション中の維持は設定によって決まり、IPが変わったことだけでは課金件数は分かりません。

何を1リクエストと数えるか

まず、リクエストと接続を分けます。HTTPリクエストは、ページを返す、データを提供するなどの動作をサイトに求め、サイトが応答を送ります。双方向にデータが流れることだけで2件差し引くことにはなりません。それには別の課金規則が必要です。

接続は、アプリケーションとサーバーの通信経路です。複数のリクエストが同じ接続を使えます。HTTP/1.1は再利用を、HTTP/2は同じ接続上の複数の同時通信を可能にします。そのため、リクエスト数、開いた接続数、同時に有効な接続数は異なる指標です。

HTTPSには、さらに注意点があります。HTTPプロキシを使うアプリは通常、CONNECTでサイトへのトンネルを作り、その中で暗号化した要求を送ります。通常の利用では、プロキシは転送しても個別のHTTPリクエストを読めません。SOCKSも接続先への接続を提供するため、アプリの操作ごとに新しい接続が必要とは限りません。

このため、一部のサービスは「リクエスト」を、接続やプロキシ側で数えられる別の出来事の意味で使います。個々のHTTPリクエストやAPI呼び出しを数えるサービスもあります。ブラウザーの開発者ツールと事業者のダッシュボードで件数が異なる場合があり、HTTP、HTTPS、SOCKS5への対応だけでは計数規則は分かりません。

大きなパッケージを買う前に、小規模でテストしてください。アプリの完了数と、差し引かれたリクエスト数を記録します。本番と同じアプリ、プロトコル、設定を使います。単純なHTTPクライアントのテストでは、スクリプトや追加リソースを読むブラウザーの利用量は分かりません。

1ページに複数のリクエストが必要な理由

ページを開くには、メイン文書以外も必要なことが多くあります。ブラウザーはスタイル、スクリプト、画像、データを別々に読み込み、開いたページが更新のため通信を続けることもあります。アプリの設定に応じてそれらもプロキシを通り、課金は料金表次第です。

リダイレクトに従うと要求が増えます。ページが別アドレスにあるとサイトが応答した場合、追従設定のアプリはそのアドレスへ追加のHTTPリクエストを送ります。単純なクライアントの文書取得とブラウザーの完全なページ表示では、件数が異なり得ます。URL一覧の長さだけでは、処理件数はまだ分かりません。

逆にAPIなら、1回で多数の記録を取れます。例では、ブラウザーは価格付きのヘッドホン商品ページに5件を使います。同じプロキシで小売業者のカタログAPIを呼ぶアプリは、1件で5商品の価格を取ります。これは商品データを返す小売業者自身のAPIです。カタログがページ分割されれば、各ページに別の要求が必要です。APIが対応し、必要データをすべて返すなら、1応答あたりの商品数を増やせる場合もあります。

この方法は、パッケージでこなせる有用な作業を増やします。完全なページの再読み込み、保存済みデータの再取得、過度な価格チェックは、枠を早く使います。1回で複数商品を取得し、結果を保存し、適切な頻度を選べば、同じ作業の必要件数を減らせます。同じ負荷なら有効期間内で枠が長持ちし、または追加の商品確認に使えます。

完了作業あたりの利用量を測ると便利です。1ページの確認、完全な一覧取得、スクリプト後に出る要素の確認などが作業単位になります。その結果までの全手順を測定してください。開始URLだけでは見落とす追加のページ読み込みも含みます。

この料金体系が役立つ場面

定期監視

利用量を定期チェックに結び付けられます。ページの可用性、公開リストの変化、指定地域の検索結果などでは、対象数と頻度を前もって決められます。テストで1回あたりの要求数を測り、月間消費を予測できます。

すべてのページを同じ頻度で調べる必要はありません。1日1回の変更なら、毎分のチェックは通常同じ情報を返します。頻繁な確認は、変化の早期発見が重要なページに絞れば、必要な観測のために枠を残せます。

APIや一覧からのデータ収集

利用量は、サイトの情報提供方法によります。一覧に必要な内容がすべてあれば、各詳細ページを開く理由はありません。追加要求は、欠損情報や前回以降に変わった記録へ使えます。1回で必要なデータを多く得るほど、収集全体の要求数を減らせます。

サービス自身の作業も考慮します。検索APIは解析済み結果を返すかもしれませんが、通常のプロキシではダウンロードや処理はアプリ側です。仕事量が異なるため、価格比較では応答内容と自分で行う残りの処理を確認してください。

サイト監査とブラウザーチェック

技術監査には、アドレスを開き、応答を調べ、必要ならリダイレクトに従い、結果を保存するなどの明確な流れがあります。大半が同じ処理なら、試験で利用量を予測しやすくなります。ブラウザーでは、スクリプト、画像、動くページ要素に依存するため件数が増える場合があります。

目的に合う確認方法を選びます。ページの応答可否だけなら、単純なクライアントで足りることが多くあります。決済フォームのテストには、その動作に必要な内容の読み込みが必要です。必須ファイルを止めれば件数は減っても、利用者の体験を確認できなくなります。

エラーと再試行の影響

要求を送っても必要なデータが返るとは限りません。エラー、アクセス確認、別ページが返る場合があります。HTTP 200も、アプリが欲しい内容を受け取った保証ではありません。HTTP上の成功とは別に、応答内容を検査する必要があります。

これらの課金規則は異なります。送信した要求をすべて数えるサービスも、定義する成功条件を満たす応答だけを課金するサービスもあります。マネージドAPIでは、複数の内部試行を1応答の価格に含める場合があります。追加モードや機能で規則が変わる場合もあるため、「リクエスト課金」は自動的に「取れたデータだけに支払う」という意味にはなりません。

アプリの再試行とサービス内部の再試行は別です。アプリが送り直せば新規リクエストになりますが、提出済みの仕事をサービスが再試行する分は料金込みの場合があります。どの試行がパッケージから差し引かれるか確認してください。

テストでは、開始作業数、課金件数、完了作業数を記録します。完了は目的次第です。収集では必要フィールドと十分新しい情報が必要で、可用性監視ではサイトが利用できないと正しく検知した場合も1回の完了です。

この数値が実際の費用を示します。何度もやり直したり応答を破棄したりするなら、単価が安くても割に合わない場合があります。高いサービスは一部の処理を代行するかもしれません。アプリに残る作業も含め、必要な結果を得る支出を比較します。

必要なパッケージの計算

最初に対象数と処理頻度を数えます。次に、テストで見られた再試行など、通常取得以外の要求を加えます。挙動が違うページ群は別々に計算します。増加用の予備枠も別にし、同じ追加要求を二重に足さないようにします。

例として、150件のURLを30分ごとに30日間確認するアプリを考えます。選んだ料金では通常1回に1件を使い、追加試行で利用量が5%増えると仮定します。数値と価格はすべて仮定であり、事業者の試験結果やProxyCompassの料金ではありません。

選んだパッケージには23,200リクエストの予備が残り、有効期間中の作業増加を補えます。予想再試行は追加の10,800件に含まれており、予備を同じ再試行の利用量として再加算してはいけません。

価格を$10とします。250千件のリクエストを含むので、表示上の1,000件単価は$0.04です。購入時には全体に$10払います。予想226,800リクエストに単価を掛けると$9.072ですが、これは使用部分の価値であって購入額ではありません。固定パッケージの支払いは$10です。

追加試行後に、予定した216,000回をすべて完了したとします。完了1,000回の費用は約$0.0463、計算は$10 ÷ 216,000 × 1,000です。追加要求と購入済み予備の両方を含みます。完了が少なければ、その実数で支出を割ってください。

ほかの作業も同じです。従量課金なら、単価が何件分かを考慮して課金件数に掛けます。パッケージなら全購入額を使い、完了作業数で割ります。複数のプロジェクトが共有するなら、費用の配分方法を決めます。

期限内に終えられるかも確認します。例では1日7,200回のチェック、平均毎分5回の開始が必要です。30分ごとに150回を一斉に始めても、時間内に分散しても、仮定どおりの試行数なら枠の消費は同じですが、起動負荷は異なります。接続数や頻度の上限で、一斉起動は予定どおり動かない場合があります。

不要なリクエストを減らす

重複アドレスを除き、進行に合わせて結果を保存します。失敗後は停止地点から続けます。毎回全一覧をやり直すと、処理済みページにも再び枠を使います。完了済みと未処理を記録してください。

データ取得に必要な読み込み方を使います。サーバー応答に必要テキストがあれば、ブラウザーは不要かもしれません。スクリプト後だけに出るデータなら、単純な取得では不十分です。データ収集サービスのブラウザーモードや追加機能は、より多くのクレジットや別単価を使う場合があり、1クレジットが常に1要求とは限りません。

応答を小さくしても、要求数を節約できるとは限りません。HTTP呼び出しを数えるなら、短い応答と長い応答は同じ件数を消費します。変わらないデータの確認頻度を下げ、保存結果を再利用し、APIで複数記録をまとめて取ると件数を減らせます。ただし、情報は作業に十分新しい必要があります。

再試行を制限し、失敗理由を考えます。サイトの一時停止や減速要求では、即時再試行しても同じ応答で枠を消費し得ます。待機や頻度低下が有用な場合があります。データを作成・変更する操作では、再送前に最初の結果を確認してください。応答が失われても、サーバーが何もしなかったとは限りません。

変更後は利用量だけでなく結果も確かめます。一部の処理を止めたために件数が減ることもあります。同じ完全性と新しさで必要データを得ながら、件数を減らせた場合に役立ちます。

料金プランを選ぶ際の確認点

まず、必要なサイトとアプリで動くか確認します。種類、国、セッション動作、提供IPでの必要ページへのアクセスが重要です。次に、誰がページを読み、ブラウザーを動かし、抽出し、失敗を再試行するか比較します。これにより、2サービスの単価差を理解できます。

有効期間、追加購入、未使用枠の扱いを確認します。単価の安い大パッケージが有利なのは、必要な作業で期限内に使える場合です。未使用分があれば、小パッケージより完了あたり費用が高くなる場合があります。

代表ページと、普段難しいページを選んで比較します。時間、要求数、取得結果、設定を記録すると、必要なパッケージの規模、作業の概算費用、期限内に完了できるかが分かります。