GB単位のプロキシ料金

何に支払うのか

ギガバイトは、プロキシ製品での消費単位です。製品は出口IP経由のインターネットへの経路を提供し、料金表はその経路の利用をどう課金するか定めます。通信量残高の前払い、定期的な枠の受け取り、契約に基づく実測利用量の支払いなどがあり、支払時期や契約上の約束は異なっても、いずれもGB単価を設定できます。

多くの場合、アプリケーションは事業者が指定するゲートウェイへ接続し、サービスがプール内の利用可能な出口を選びます。出口が変わっても、同じアカウントの枠を使い続ける場合があります。したがって、宣伝される大きなプールはアクセス候補の規模であり、自分専用に確保されたリストではありません。特定IPへのアクセスに通信量料金を組み合わせる製品もあります。

課金単位は、ネットワークの種類やセッション動作を決めません。データセンター、ISP、住宅用、モバイルのいずれも通信量で販売できます。ローテーション、セッション中のIP維持、アドレスの専有は別の製品特性です。GBを買い足しても、独自の期限があるセッションは延長せず、利用できない出口も復旧しません。

単価を比較する前に、必要なアクセスを選びます。地域別の決済テストなら、指定地域で受け入れられるIPを提供し、決済完了までセッションを維持できる必要があります。安くてもそれができなければ要件を満たしません。逆に、単純なネットワークで安定して動くなら、高いネットワークを買っても自動的な利点はありません。

枠から転送速度は分かりません。量は通せるデータの総量、スループットは通る速さ、同時実行容量は並行して動かせる処理量を決めます。時間制約のある作業を終えられないほど経路が遅ければ、残高が大きくても補えません。

作業全体が課金対象通信量になるまで

処理全体から考えます。プログラムは文書一覧を取得し、リンクをたどってファイルを取り、いくつかを再取得する場合があります。最終アーカイブに各文書が1部しかなくても、すべての段階で有料接続を使う可能性があります。

例として、300件の文書を保存できた作業を考えます。次の仮の通信量は、同じ実行内の重複しない別々の部分です。計上の例であり、特定サイトや事業者の測定結果ではありません。

十進単位では、この実行の消費は0.308 GBです。仮に$4.50/GBなら通信料は$1.386、その他の料金を除いて約$1.39です。重要なのは、保存文書に対応する240 MBと、処理が使った308 MBの違いです。重複取得を省けば、アーカイブを減らさず48 MBを節約できますが、文書の探索を省くと作業自体が動かなくなる場合があります。

事業者がどこまで測るかが重要です。公開されているプロキシの規則では、HTTPヘッダーや本文を含め、サイトへ送るデータと受け取るデータの両方を数えることが一般的です。そのため、応答が短くても、アップロードが多ければ枠を消費します。接続通信、暗号化のオーバーヘッド、サービス自身が生成するエラーの扱いは異なります。取得ファイルの中身だけのカウンターでは、すべての請求を再現できません。

HTTPSトンネルでは、プロキシは保護された内容を読まずに、運ぶ暗号化バイトを測れます。予算には事業者が示す方式と実測値を使ってください。すべてのリクエストに加算できる共通のオーバーヘッド率はありません。すでにそのバイトを含むカウンターへ加算すると二重計上になります。

GBとGiBで数値が異なる理由

1ギガバイト（GB）は1,000,000,000バイトです。1ギビバイト（GiB）は2³⁰バイト、つまり1,073,741,824バイト、または1,024 MiBです。GBは十進のべき乗、GiBは二進のべき乗を使います。同じ種類の量を、異なる大きさの単位で測っています。

たとえば32 GiBは34.359738368 GB、約34.36 GBです。GB表示の数値は約7.37%大きくなります。1 GiBに1.073741824 GB含まれるためです。通信が増えたわけではなく、どちらも同じバイト数です。逆に、32 GBの枠は約29.80 GiBなので、表示の数字が同じでも同じ量の枠とは限りません。

アプリケーションのカウンターと請求上の利用量を照合する前に、両方を同じ単位へ換算します。略称だけで判断せず事業者の定義を確認し、その後、計上範囲を確認してください。丸めは別の問題で、ダッシュボードの短い表示から請求時の精度は分かりません。

ページと同じくらい手順が重要な理由

初回と再訪では異なる

初回訪問では、サイトの表示や動作に必要なリソースを取得します。同じブラウザーの再訪なら一部をローカルから再利用できても、新しいプロファイルでは再取得が必要な場合があります。ブラウザーセッションをどう開始・再利用するかも、通信量モデルの一部です。

キャッシュには複数の結果があります。有効なローカルコピーは再取得せずに使えます。期限切れのコピーでは条件付きリクエストが必要になり、304 Not Modifiedなら保存内容を再利用できますが、検証通信は発生します。変更済みや再利用不可のリソースには新たな転送が必要です。プロファイルを残しても、すべてがキャッシュされるとは限りません。

監視作業にはキャッシュが有用な場合がありますが、新規訪問者の体験テストでは条件を損なう場合があります。実際に必要な条件で測定してください。安い再訪1回を、数千件の独立した初回訪問の見積もりには使えません。

出力形式にも注意が必要です。ローカルでのスクリーンショットは、読み込み済みの内容から画像を作る操作であり、それだけで画像をプロキシ経由で送り返すわけではありません。画像のアップロードは別の転送です。遠隔ブラウザーやスクリーンショットAPIは課金方式が異なる場合があるため、出力サイズを通常のローカルブラウザーの通信量と見なさないでください。

ダウンロードと動画は別に見積もる

ファイル転送では、文書サイズ、重複検出、中断からの再開可否が消費を大きく左右します。動画テストでは、ページ数より時間とビットレートが有用です。最初のページは小さくても、プレーヤーはテスト中ずっとメディアを取得し続ける場合があります。

メディアデータを平均毎秒6メガビットで18分間受信するとします。8で割るとビットをバイトに換算でき、6 × 1,080 ÷ 8 = 810メガバイト、つまり0.81 GBです。この完全なテストを12か所で繰り返すと、メディアだけで9.72 GBを転送します。仮の負荷であり、画面、その他の要求、計上対象のオーバーヘッドは追加です。自動画質調整やバッファリングで実測量は変わり得ます。

画質を下げて節約と呼べるのは、テストが本来の問いに答えられる場合です。動画が始まるかだけなら短い観察で済みます。高画質の継続再生を調べるなら、評価に十分な量を受信する必要があります。必要な証拠によって、省けるデータが決まります。

こうした違いから、通信量課金に適する場面が分かります。短い地域別チェックや、必要なプールへの断続的なアクセスは、少量で済む場合があります。継続的なメディアテストや大量の再取得は、同じ枠を急速に使います。適した製品ならどちらも技術的には可能ですが、経済性は作業量、日程、代替案に左右されます。

作業の組み合わせから予測する

測定前に、完了の定義を決めます。文書なら、期待する識別子を持ち読み取れるファイル、地域別テストなら、完了した操作と記録済みの結果などです。接続成功やHTTPステータスだけでは、作業完了は分かりません。

予定する地域、セッション設定、ソフトウェア、並列動作で試験運用します。認証情報や利用量の集計を無関係な作業と分けてください。報告遅延を考慮して同じ期間の利用量変化を記録し、試行数と完了数の両方を数えます。通常動作に背景通信があるなら、黙って除外せず、含めるか別に測定してください。

操作の種類ごとに重み付けする

予測には、想定する作業の構成比を残します。試験運用で次の仮の平均が得られたとします。各完了操作に必要な通常の要求と再試行は、すでに含まれています。予定操作はそれぞれ1つのカテゴリだけに属します。

同じ仮の単価$4.50/GBなら、予測通信料は$67.986、約$67.99です。メディアチェックは操作数の13分の1未満ですが、通信量のほぼ60%を占めます。したがって、はるかに件数の多い継続チェックを最適化するより、メディアテストの適切な変更の方が効果的な場合があります。

基本計算は、種類ごとに件数と実測平均通信量を掛け、その合計を求めます。別に測った初期設定や共有動作は、平均の外にある場合だけ追加します。同様に、試験運用に含まれる再試行へ、失敗率の倍率をもう一度適用しないでください。

予測を変える条件をテストする

平均が役立つのは、作業を比較できる間だけです。新プロファイルへの変更でキャッシュ節約がなくなり、別地域では別のページやメディアを受け取ることがあります。観察時間を延ばすと背景データが増える場合もあります。変更後は、古い平均を全体に使わず、影響するカテゴリを測り直してください。

通常の実行に加え、大きな文書、新セッション、中断の多い時間帯など、あり得る不利な実行もテストします。仮定を明示してください。こうした条件から得た予備枠は、説明のない一定率を全予算に足すより有用です。

適したサービスを選ぶには、各テストの結果を、同じ作業を完了するために必要な支出に換算します。消費した通信量と、避けられない購入条件を含めます。GB単価が安くても、試行数が異なったり必要セッションを完了できなかったりする場合、単価だけでは比較を決められません。

作業日程に合わせて購入する

上の予測は消費量です。通信量のパッケージ販売、必須のサブスクリプション、別のアクセス料金があれば、支払額は異なります。何がいつ利用でき、どの支払いが継続利用を認可するかを、購入全体として確認してください。

日付の重要性を示す例を考えます。プロジェクトは更新前に8 GB、更新後に28 GB必要です。仮に月間30 GBが$90で、繰り越しも追加費用もなければ、2か月分で$180が必要です。期限のない残高を20 GBずつ$80で販売する仮の方式なら、2口で$160、残り4 GBを利用できます。アクセス条件は同等と仮定します。月間方式のGB単価$3は、まとめ買い方式のGB単価$4より安くても、この日程では月間方式の方が多くの支払いを必要とします。

同じプロジェクトを1課金期間内に収めると比較が変わります。30 GBの枠にはさらに6 GBが必要で、追加価格が決め手になります。総需要に最低表示単価を掛けるだけでは不十分な理由です。更新日、購入単位、追加通信量の有効期限に沿って計算してください。

残り枠が後の作業に役立つのは、アカウント条件上まだ使える間だけです。通信量の失効、サブスクリプション更新、アカウント維持の要件を区別します。基本枠と追加枠で期限が違うなら、どちらを先に消費するか確認してください。未使用のまま失効する量に影響します。

設定も価格に含めて考えます。特定ネットワーク、細かな地域指定、予約アドレス、追加機能で料金が変わる場合があります。消費倍率があれば、実際のバイトと課金単位を区別します。利用量にまだ倍率が反映されていない場合だけ掛けてください。最低利用契約、追加通信量の単価、見積もりの税込・税別も同様に確認します。

継続的な大量処理では、計画全体を適した固定料金案と比較してください。代替案も、サイト、地域、セッション、許可通信、転送速度について同じ要件を満たす必要があります。固定料金は大量転送の予算を立てやすくし、通信量方式は、時々の作業でほとんど使わない容量の維持を避けられます。課金単位だけで、どのネットワークが適切かは決まりません。

同じ作業を再購入せずに復旧する

復旧は、最小の未完了部分から始めます。文書の大半を保存済みなのに一覧全体をやり直すと、同じ取得に何度も払うことになります。完了識別子を記録し、保存ファイルを検証して、残りのキューを再開します。ネットワークや単価を変えずに無駄を減らせます。

大きなファイルの中断には、専用の仕組みが必要です。サーバーとクライアントが範囲要求に対応すれば、未取得部分だけを要求できます。同じ版のファイルを続けているか確認しなければなりません。206 Partial Contentは範囲を返しますが、完全な200 OKを既存の断片へ無条件に追加してはいけません。正しく実装すれば、再開で転送バイトを節約できます。

エラーごとに判断を変えます。一時的な接続失敗なら回数を限った再試行が妥当な場合があります。繰り返す拒否、ログイン失効、枠の枯渇、不正な要求には別の対応が必要です。同じ問題を高速に繰り返すと、進展なく支出が増えます。遠隔アカウントを変更する操作では、再提出前に最初の試行が完了したか確認してください。

失敗しても、すでに転送したバイトは消えません。中断取得や拒否ページも有料通信を使う場合があり、自社の接続エラーを除外するサービスもあります。スクレイピングAPIの成功時のみ課金という約束を流用せず、実際のプロキシ製品の条件を適用してください。

セッションの継続性も復旧に影響します。IP交換でセッションに紐づく手順が無効になり、前段階からやり直す場合があります。IP維持は継続性に役立っても、後続転送を無料にせず、サイト側セッションの有効性も保証しません。可能な範囲で進捗を保存し、原因に合う復旧操作を選んでください。

実行中の作業を予算内に保つ

進捗と利用量を併せて見ます。残り枠、直近の毎分消費量、同期間の完了数が役立ちます。消費が増えて完了が止まるなら、残高切れ前に対応が必要です。比例して増えるなら、単に処理量が増えている場合があります。

たとえば残り14 GBで、毎分0.35 GBを継続消費するなら、その速度で約40分間使えます。計画用の見積もりであり、停止時刻の保証ではありません。速度は変わり、表示が遅れ、進行中の転送がまだ完了していない場合があります。残りキューと比較し、安全に終えられるよう早めに新規作業を止めるか減らしてください。

購入側とアプリ側の両方で管理します。アカウントでは、枠切れで停止するか、追加購入や超過料金を認可するかを意識して選びます。アプリでは、キュー、試行数、同時転送数、セッションを開く時間に上限を設けます。自動補充は資金を維持しても、作業にまだ費用をかける価値があるかまでは判断できません。

長時間の取得やメディアセッションには、明確な停止条件が必要です。新規リクエストを減らすだけでは、既存転送が消費し続ける場合があります。進行中の処理を取り消し、未使用セッションを閉じられるようにしてください。ダッシュボードの閾値を瞬時のスイッチとせず、報告や適用の遅れに備えた余裕を残します。

数値が合わなければ、範囲を区切った1回の実行を照合します。アカウントやユーザー、期間、単位、作業ログを合わせます。ブラウザーのネットワークツールは大きな転送や、転送サイズと展開後サイズの違いを調べるのに役立ちますが、アカウント利用の全プロセスをカバーするとは限りません。消費量は購入、残高移動、失効と別に追ってください。残高変化が必ず転送を意味するわけではありません。

次に、原因に合う変更を1つ行い、同じ作業を繰り返します。必要なブラウザー状態を残し、重複取得を避け、対応する圧縮を維持し、処理を壊さない範囲で無関係なリソースの開始を防ぎます。支出削減と完了の両方を確認してください。必要な証拠を取り除いた通信削減は、作業未完了です。