ウェブスクリーピングの並行処理の設定方法をリトライストームなしで

TL;DR

• 並行制限は進行中の作業を制御し、レート制限は新しいリクエストの開始速度を制御します。
• 容量を共有する実際のソースとアカウントのスコープに制限を適用し、単に各ワーカーごとに適用するのではなくしてください。
• 再試行中のリクエストは、初回試行と同じ承認予算を消費する必要があります。
• HTTP 429を共有されたクールダウンのシグナルとして扱い、有効なRetry-Afterの指示を保持してください。
• 受け入れられたデータのスループットが不快な遅延、エラー、キューの増加なしに改善する間のみ、並行性を増加させてください。
• CAPTCHAタスクと宛先リクエストを別々のプールにし、それらの間で明示的なオーバーライドを実施してください。

スクリーパーはより多くのリクエストを発行し、有効なデータを収集できなくなる可能性があります。遅い応答は接続を占有し、ワーカーは失敗したリクエストを繰り返し、キューに進行中の作業のコピーが詰まります。ワーカー数を増やすと、同じボトルネックが拡大する可能性があります。有用なパフォーマンス指標は、ジョブのデッドライン内で受け入れられたデータの量であり、開始されたリクエスト数ではありません。

このガイドでは、認証された収集ワークフローに適したスクリーピングの並行制限の設定方法について説明します。これは、ソースレベルの承認、リトライスケジューリング、ブラウザの容量、および制御されたチューニングプロセスをカバーしています。CapSolverは、許可されたワークフローが必要とする場合に、別個のサポートされたCAPTCHAタスクステージに適合します。ワーカープールを大きくしても、チャレンジが完了しても、ソースのレートポリシーは変化しないため、スケジューラーは実行中にコントロールを保持する必要があります。

並行性とリクエストレートを分離する

並行性は現在進行中の操作の数であり、リクエストレートは時間経過に伴う開始数を測定します。並行制限だけでは、応答時間の変化によりスロットがどのようにして利用可能になるかに応じて、安定したリクエストレートを保証できません。

許可されたテストソースに4つのアクティブなリクエストスロットがあると仮定してください。リクエストが迅速に完了すると、そのスロットは短時間で多くの開始を生成します。応答が遅くなると、同じ4つのスロットはより少ない開始を生成し、より多くの時間を占有します。両方の動作は並行制限に従います。時間ベースの許容範囲内で開始数を維持する必要がある場合、別個のレートコントローラーが必要です。

並行性の用語集とレートリミットの用語集では関連するコンセプトが説明されています。あなたのスケジューラーでそれらを別個の設定として記録してください。最大待機キューとジョブのデッドラインを追加し、遅延した作業が他の合理的な制限の裏で無限に蓄積しないようにしてください。

一貫した最適な並行リクエスト数は存在しません。ソースポリシー、ペイロードサイズ、ブラウザレンダリング、帯域幅、および下流処理がすべて有用な運用ポイントに影響を与えます。ソースの文書化された許容範囲と自社の容量から始め、明示的に許可されたワークロードを測定してください。

ステップ1: 制限を共有するスコープを定義する

並行制限は、同じ容量または権限を競合するワーカーをカバーする必要があります。複数のプロセス、マシン、またはジョブが同じ制限されたソースにアクセスする場合、プロセスごとの設定は不十分です。

ワーカーを作成する前に、関連するスコープを特定してください。ホスト名、API資格情報、ソース定義のアカウントクォータ、または制御されたブラウザセッションかもしれません。URLごとに独立した容量があると仮定するのではなく、提供元が説明するスコープを使用してください。サブドメインもインフラストラクチャやアカウントレベルの許容を共有する可能性があります。

グローバル容量とソース容量を分離してください。グローバルな上限は、自社のマシンと出力リソースを保護します。ソースごとの上限は、一つの高速キューがすべての利用可能なスロットを消費することを防ぎます。ソースが一時的に停止している場合、他の独立して許可されたソースは、停止中のソースのアイデンティティやクォータを借りることなく継続できます。

ブラウザワークフローの場合、スロットを占めるものはナビゲーション、アクティブなページ、または全体のセッションであるかを決定してください。アカウントに束縛されたセッションは、並行ジョブ間で簡単に共有されてはなりません。そのクッキー、保留中のアクション、および期待される宛先には、タスクの期間中に所有者がいる必要があります。

ステップ2: すべてのリクエストが承認を通過するようにする

承認はリクエストが開始される前に発生し、初期試行、リダイレクト（クライアントで制御される場合）、およびワーカーの再起動に等しく適用される必要があります。トランスポートに直接送信するリトライパスは、メインスケジューラーの制限を打ち破る可能性があります。

意図された観測に一つのタスクIDを使用し、トランスポート作業に別の試行IDを使用してください。これにより、キューは正当なリトライと重複したスケジュールされたジョブを区別できます。ワーカーが再起動する場合、観測がすでに完了しているかを確認してから別のリクエストを作成する必要があります。

関連する操作が実際に完了したとき、またはトランスポートがキャンセルされたときにスロットを解放してください。コールャーが待機をやめただけで容量を解放すると、名目上の制限を超えて隠れたリクエストが実行されたままになる可能性があります。状態が解決されるまで、不確実または実行中の作業を占有された容量として扱ってください。

キューも制限してください。作業が多すぎる場合、後続の収集ウィンドウを遅らせる、余分な要件を拒否する、またはサービス契約に従って要求されたスコープを減らすことができます。無制限のバックログを保持すると、失敗がメモリの圧力と古くなった観測に移行します。

ステップ3: 睡眠をすべてに適用するのではなくリトライをスケジュールする

リトライは、将来の有効時間、試行回数、および残りのタスクデッドラインを持つ制御されたキューに戻るべきです。ワーカー内で散在するスリープコールでは、共有されたソースのクールダウンを調整するのが困難です。

HTTP 429ステータスは、関連する期間内にあまりにも多くのリクエストが送信されたことを示します。応答にRetry-Afterが含まれている場合、その遅延または日付の意味を保持してください。すべてのワーカーが短い待機時間を独自に選択しないようにしてください。

影響を受けたスコープに対して共有されたクールダウンを使用してください。クールダウンが有効な間、新しい作業の承認を停止してください。これは、これまでに失敗していないリクエストにも適用されます。すでに実行中の作業は完了するかもしれませんが、1つのワーカーからの成功応答が他のワーカーが観測した有効なクールダウンを自動的に消去してはなりません。

明示的なサーバーの指示のない一時的な読み取りタイムアウトの場合、操作に適したバウンドされたリトライポリシーを適用してください。ステガレッドスケジュールは、一時停止後の同期されたバーストを回避できます。その効果と再実行可能性が理解されていない限り、フォーム送信やその他の状態変更操作にリトライを追加しないでください。

観測	スケジューラーの対応	保持する証拠
HTTP 429	影響を受けたスコープを一時停止し、リトライの指示を尊重	ソーススコープ、応答時間、クールダウン
一時的な読み取りタイムアウト	試行とデッドラインの予算内で再キュー	試行IDと残りの時間
認証またはアクセス拒否	停止またはアクセスレビューにルーティング	非表示にされた応答カテゴリ
サポートされたCAPTCHAチェックポイント	別個の許可されたチャレンジステージに移行	現在の観測とチャレンジコンテキスト
無効な抽出されたレコード	パースまたはソースデータの調査	保持されたページ参照と検証エラー

CapSolverボーナスコードを取得する

自動化予算を即座に増やす！
CapSolverアカウントにチャージする際、ボーナスコード CAP26 を使用して、すべてのチャージで 5%のボーナス を受け取ることができます — 制限なし。
今すぐCapSolverダッシュボードで取得してください

ステップ4: チャレンジ処理が需要を増やさないようする

CAPTCHAチェックポイントは、スクリーパーの隣で実行される追加のリクエストループを作成するのではなく、制御されたオーバーライドを作成する必要があります。宛先の観測は、サポートされたチャレンジステップを必要とする場合でも、1つのタスクのままです。

CapSolver createTaskドキュメントはタスクの提出を定義し、getTaskResultは結果の取得を文書化しています。関連するタスク要件に従い、返されたタスクIDを現在の観測に関連付けてください。既知のタスクをポーリングし、新しいタスクを作成することは異なる操作です。

このステージに独自の制限（アクティブな作業、時間、試行回数）を設定してください。ブラウザが再開されたとき、宛先のレート許容範囲が依然として適用されます。チャレンジ結果は、ソースのクールダウンを即座に例外として扱うか、すべての停止中のワーカーが同時に再起動することを引き起こしてはなりません。

タスクの提出が承認が確認される前にタイムアウトした場合、不確実性を保持してください。盲目的に別のタスクを提出すると、作業が重複する可能性があります。スケジューラーは、現在の結果を待っているのか、不確実なリクエストを調査しているのか、または観測をレビューするために閉じているのかを知っている必要があります。

宛先が進捗した後、期待されるページを検証し、契約を記録してください。それ以外の場合、増加したチャレンジスループは、受け入れられた収集出力が改善していないことを隠す可能性があります。

ステップ5: 制御された並行性の増加を実行する

並行性の増加は、1つの容量設定を変更しながら、比較ワークロードと受け入れ基準を安定させなければなりません。明示的に許可されたロードテストが可能な所有されたテストソースまたは別の環境を使用してください。

基準を確立する

小さな許可されたワークロードから始め、完了した観測、受け入れられたレコード、リクエストの遅延、エラーの種類、キューの年齢を記録してください。承認待ちの時間とネットワークまたはブラウザでの時間は分離してください。長いエンドツーエンドの期間には、異なる原因があり、それぞれ異なる修正が必要です。

最初の試行とリトライを同じレポートに表示してください。受け入れられたレコードが一定のまま、総リクエスト数が増加している場合、追加のトラフィックは有用なスループットを生成していません。ワーカーを追加する前に、リトライポリシー、ページの準備状況、または下流の検証が違いを説明しているかを確認してください。

結果が改善する間のみ増加させる

予定された小さなステップで制限を増やし、同等の間隔を観測してください。受け入れスループットが平坦化し、失敗頻度が増加し、尾部の遅延がタスクの要件を超えると、増加を停止してください。これらの観測は、そのワークロードの容量境界を識別しますが、プロバイダー全体の永久的な制限を証明するものではありません。

ペイロードサイズとページタイプごとに代表的なケースを繰り返してください。軽量なHTMLページとJavaScriptが豊富なダッシュボードは、非常に異なるブラウザリソースを必要とする可能性があります。最も簡単なページだけからオペレーティング制限を選択しないでください。

変動の余地を確保する

失敗境界の下に余裕があるオペレーティングポイントを選択してください。一時的に最高値を永久に実行するのではなく、ソースのパフォーマンスと自社のインフラが変化する可能性があります。予定された作業に容量を確保し、探索的なジョブが全体のプールを占有することを防いでください。

自動スロットリングが制御するものを理解する

自動スロットリングは、観測された遅延に応じてリクエストタイミングを調整できる場合がありますが、その動作は実装と設定された制限に依存します。2番目のスケジューラーと組み合わせる前に、使用するフレームワークのドキュメントを読んでください。

Scrapy AutoThrottleドキュメントは、設定された並行制限を尊重しながら、ターゲット並行性と遅延ベースの調整を説明しています。そのターゲットは、常に正確な数のリクエストがアクティブであることを保証するものではありません。非成功応答も遅延計算で特別な扱いを受けています。

フレームワーク固有のコントロールを使用してください。クローラーのローカルスロットリングは、別個の展開を自動的に調整したり、全体的な組織のクォータを課したりしません。いくつかのジョブが1つの許容範囲を共有している場合、それらの独立ワーカーの上に共有コントローラーを配置してください。

各実行で使用された有効な構成を記録してください。フレームワーク、トランスポートプール、リトライミドルウェア、および外部スケジューラーが同時に変化すると、並行性の実験は再現が困難になります。ブラウザインフラストラクチャの概要は、これらのリソースを分離するための有用な文脈を提供します。

容量を増やす前にスループットの低下を診断する

受け入れられたスループットの低下は、ネットワーク、ソース、ブラウザ、パーサー、または宛先ストアから来る可能性があります。より多くのフェッチワーカーは、その中の一部のボトルネックにのみ役立ち、他のボトルネックを悪化させる可能性があります。

キューが増加しているがネットワークスロットが空いている場合、承認とクールダウンロジックを検査してください。ブラウザメモリが増加している場合、セッションの有効期間とページのクリーンアップをレビューしてください。リクエストが完了してもレコードが拒否されている場合、コンテンツの準備状況、スキーマの変更、パーサーの動作を検査してください。受け入れられたレコードが保存されるのを待っている場合、下流のライターからバックプレッシャーを適用してください。

明確な一時停止プロセスを保持してください。オペレーターは、1つのソースの新しい開始を停止し、進行中のタスクIDを保持し、問題が理解された後に徐々に再開できる必要があります。すべてのワーカーを同時に再起動するのは、制御された容量の再開の代わりにはなりません。

有用な収集出力を目指してチューニングする

スクリーピングの並行性をソースポリシー、実際のリソース所有、および受け入れられたレコードに基づいて設定してください。すべての試行を承認を通じてルーティングし、クールダウンを調整し、完全なパイプラインが恩恵を受ける場合にのみ負荷を増やしてください。

サポートされたCAPTCHA処理を必要とするワークフローの場合、CapSolverを別個の制限付きステージ内で使用し、その後同じソースコントロールに戻ってください。厳格なスケジューラーは、ロードとページ動作が変化するたびにシステムを運用しやすくします。

FAQ

Q: 並行制限は1秒あたりのリクエスト数の制限と同じですか？

いいえ。並行制限はアクティブな操作を制御します。リクエストレート制限は時間経過に伴う開始数を制御するため、両方の制御が必要になる場合があります。

Q: 同じレートリミットスコープを共有するワーカーは、HTTP 429を個別に処理すべきですか？

同じレートリミットスコープを共有するワーカーは、クールダウンを調整する必要があります。個別のリトライは、各ワーカーが保守的であってもバーストを再生成する可能性があります。

Q: 並行性を増やすことで遅いスクリーピングを修正できますか？

ソースの許容範囲内で受け入れられた出力が改善する場合のみ可能です。まず、取得、レンダリング、パース、または保存がボトルネックであるかを特定してください。

Q: CAPTCHAの結果はスケジューラーをスキップするリクエストに影響しますか？

いいえ。チャレンジ処理が完了した後も、宛先のレートと並行制限ルールが依然として適用されます。

Q: 下流のストレージが遅れるとどうなりますか？

バックプレッシャーにより、新しい取得を減らすか一時停止してください。取得されたページの無制限のキューはリソースの使用を増やし、受け入れられる前に観測が古くなる可能性があります。