Web スクレイピングを試したことがある人なら、おそらくある時点で恐ろしい 429 ステータス コードに遭遇したことがあるでしょう。この厄介な応答により、クローラーが追跡を停止し、データ抽出作業が台無しになる可能性があります。しかし、429 ステータス コードは正確には何を意味するのでしょうか。Web サイトのスクレイピング中にこのエラーが発生しないようにするにはどうすればよいでしょうか?この包括的なガイドでは、429 ステータス コードの詳細を詳しく説明し、Web スクレイピング プロジェクトの妨げにならないようにする実証済みの戦略を共有します。
429 ステータス コードを理解する
「リクエストが多すぎる」とも呼ばれる 429 ステータス コードは、ユーザーが短期間に過剰な数のリクエストを行ったときにサーバーが送信する HTTP 応答ステータス コードです。これは、クライアント側のエラーを示すステータス コードの 4xx クラスの一部です。
サーバーが 429 ステータス コードを返すと、基本的にはクライアント (この場合は Web スクレイパー) に、リクエスト送信のレート制限またはクォータを超過したことを伝えます。レート制限は、多くの Web サイトで、サーバーが多すぎるリクエストによる過負荷から保護し、リソースの悪用や悪用を防ぐために使用されている技術です。
スクレイピング中に 429 エラーが発生すると、対象の Web サイトへのアクセスが一時的にブロックされるため、イライラすることがあります。 429 を受信した後もリクエストを送信し続けると、サーバーによってより厳しいレート制限が課されたり、IP アドレスが完全に禁止されたりする可能性があります。したがって、Web スクレイピングの取り組みにおいて 429 エラーの原因とそれを回避する方法を理解することが重要です。
Web サイトにレート制限が導入されるのはなぜですか?
Web サイトはいくつかの理由からレート制限を実装します。
サーバーの保護: 過剰なリクエストは Web サイトのサーバーに負担をかけ、速度低下、クラッシュ、ダウンタイムを引き起こす可能性があります。特定の時間枠内でクライアントが実行できるリクエストの数を制限することで、Web サイトはサーバーの負荷を保護し、正規の訪問者に対してスムーズなユーザー エクスペリエンスを確保できます。
公平性とリソースの割り当て: レート制限により、Web サイトのリソースがユーザー間で公平に分配されるようになります。これにより、単一のクライアントまたは少数のユーザー グループがサーバーのリソースを独占することがなくなり、全員が平等にアクセスできるようになります。
虐待の防止: レート制限は、Web サイトの利用規約に違反するスパム、ブルートフォース攻撃、自動スクレイピングなどの不正行為に対抗するのに役立ちます。リクエストの数を制限することで、Web サイトは悪意のある攻撃者を阻止し、プラットフォームの整合性を維持できます。
API利用規約の遵守: 多くの Web サイトは、開発者がデータにアクセスするための API を提供しています。これらの API には、悪用を防止し、公正な使用を確保するために、特定の使用条件とレート制限が設けられていることがよくあります。指定されたレート制限を超えると、429 エラーが発生する可能性があります。
Webスクレイピングにおける429エラーの一般的な原因
Web サイトのスクレイピング中に、いくつかの要因によって 429 ステータス コードがトリガーされる可能性があります。
送信するリクエストが多すぎる: スクレイパーが短期間に大量のリクエストを Web サイトに送信すると、サーバーによって設定されたレート制限を超え、429 エラーが発生する可能性があります。
削りすぎが早すぎる: リクエストを遅延なく連続して送信すると、レート制限が発生する可能性があります。 Web サイトは、この動作を不正行為またはボットのようなものとして解釈し、429 ステータス コードで応答する場合があります。
Robots.txt の無視: Web サイトは、robots.txt ファイルを使用して Web クローラーのルールを指定します。スクレイパーがこれらのルールを無視し、制限されたページにアクセスしようとしたり、リクエストを頻繁に送信しようとしたりすると、429 エラーが発生する可能性があります。
単一の IP アドレスの使用: すべてのリクエストが単一の IP アドレスから発信されている場合、Web サイトはそれを不審な動作として認識し、レート制限を課す可能性があります。リクエストを複数の IP アドレスに分散すると、この問題を軽減できます。
セッションまたは Cookie が適切に処理されない: 一部の Web サイトではセッションベースのレート制限を使用しており、ユーザー セッションごとに制限が適用されます。スクレイパーがセッションや Cookie を正しく処理しない場合、リクエストごとに新しいユーザーとして扱われ、すぐにレート制限を使い果たす可能性があります。
Webスクレイピングでの429エラーを防ぐためのベストプラクティス
429 エラーの原因を理解したところで、エラーを防ぐためのベスト プラクティスをいくつか見てみましょう。
リクエストを抑制する: スクレイパーにスロットル メカニズムを実装して、特定の時間枠内に送信されるリクエストの数を制限します。リクエスト間に遅延を追加して人間のような動作をシミュレートし、サーバーに負荷がかかるのを防ぎます。 Python の time.sleep() などのライブラリを使用して、リクエスト間に一時停止を導入できます。
リクエストを複数の IP アドレスに分散する: プロキシのプールを使用するか、IP アドレスをローテーションしてリクエストを分散します。異なる IP アドレスからリクエストを送信することで、単一の IP に関連付けられたレート制限のトリガーを回避できます。信頼できるプロキシ サービスを使用するか、独自のプロキシ インフラストラクチャを設定することを検討してください。
ロボットを尊重する.txt: スクレイピングしている Web サイトの robots.txt ファイルを常に確認し、そのルールに従ってください。 robots.txt ファイルによって禁止または制限されているページをスクレイピングしないでください。 Web サイトのクロール ガイドラインを尊重することは、429 エラーを防ぎ、適切なスクレイピング エチケットを維持するのに役立ちます。
人間の閲覧パターンをシミュレートする: 検出を避けるために、スクレイパーに人間のブラウジング動作を模倣させます。リクエスト間にランダムな遅延を導入し、ユーザー エージェント文字列を変更し、Web サイトの要素 (ボタンをクリックする、フォームに記入するなど) を操作して、スクレイパーをより人間らしく見せることができます。
セッションを使用して Cookie を処理する: スクレイパーでセッションを維持し、Cookie を適切に処理します。一部の Web サイトではセッションベースのレート制限を使用しているため、リクエスト間でセッションを維持すると、レート制限内に留まることができます。 Python の request.Session() などのライブラリを使用して、セッションを効果的に管理します。
指数バックオフの実装: 429 エラーが発生した場合は、指数バックオフ戦略を実装してください。リクエストをすぐに再試行するのではなく、次のリクエストを送信するまで、徐々に時間がかかるまで待ってください。これにより、サーバーが回復する時間が与えられ、レート制限に再び達する可能性が減ります。
監視と適応: スクレーパーのパフォーマンスとそれが受け取る応答に注目してください。 429 エラーを監視し、それに応じてスクレイピング アプローチを調整します。レート制限が常に発生する場合は、スクレイピング速度を調整するか、別のプロキシ プールを使用するか、代替データ ソースを検討することを検討してください。
ウェブサイト所有者に連絡する: Web サイトをスクレイピングする正当な理由があり、レート制限を超える必要がある場合は、Web サイトの所有者に連絡することを検討してください。ユースケースを説明し、敬意を持ってスクレイピングを実践する姿勢を示し、より高いレートでスクレイピングする許可をリクエストします。一部の Web サイトでは、API アクセスを提供したり、特定のユースケース向けにスクレイピングに適したオプションを提供したりする場合があります。
スクレイピング コード内の 429 エラーの処理
429 エラーを防ぐために最善の努力を払っても、依然としてエラーが発生することがあります。スムーズなスクレイピング プロセスを確保するには、スクレイピング コードでこれらのエラーを適切に処理することが重要です。以下は、Python とリクエスト ライブラリを使用して 429 エラーを処理する方法の例です。
import requests
from requests.adapters import HTTPAdapter
from requests.packages.urllib3.util.retry import Retry
retry_strategy = Retry(
total=3, # Total number of retry attempts
status_forcelist=[429], # Retry on 429 status code
backoff_factor=1 # Backoff factor for exponential delay
)
adapter = HTTPAdapter(max_retries=retry_strategy)
with requests.Session() as session:
session.mount("https://", adapter)
session.mount("http://", adapter)
try:
response = session.get("https://example.com")
response.raise_for_status()
# Process the response data
except requests.exceptions.RequestException as e:
print("Error occurred:", e)この例では、 Retry からのクラス requests 図書館。再試行の合計回数、再試行のステータス コード (429)、および再試行間の指数関数的な遅延のバックオフ係数を指定します。次に、 HTTPAdapter 再試行戦略を使用して、HTTP リクエストと HTTPS リクエストの両方のセッションにマウントします。
このアプローチを使用すると、429 エラーが発生した場合、スクレイパーは自動的にリクエストを最大 XNUMX 回再試行し、試行間に指数関数的な遅延が生じます。これは、一時的なレート制限の問題に対処し、スクレーパーの回復力を向上させるのに役立ちます。
429 エラーを回避するために Web スクレイピングをアウトソーシングする
常に 429 エラーに直面している場合、またはスクレイピングのニーズが複雑な場合は、Web スクレイピング タスクをプロフェッショナル サービスまたは API にアウトソーシングすることを検討してください。これらのサービスには、大規模なプロキシ ネットワーク、堅牢なインフラストラクチャ、およびレート制限やその他のスクレイピングの課題を処理する専門知識が備わっていることがよくあります。
一般的な Web スクレイピング サービスと API には次のようなものがあります。
- Scrapy Cloud: インフラストラクチャを処理し、スクレイピング プロセスを管理するクラウドベースの Web スクレイピング プラットフォーム。
- ScrapingBee: プロキシ ローテーション、JavaScript レンダリング、CAPTCHA など、Web スクレイピングの複雑さを処理する API。
- ParseHub: コーディングを行わずにデータを抽出し、レート制限やその他の課題を裏で処理できるビジュアルな Web スクレイピング ツールです。
Web スクレイピングをアウトソーシングすると、429 エラーやその他のスクレイピングの障害に対処する時間と労力を節約できます。ただし、サービスを利用する前に、サービスプロバイダー、その価格設定、法的および倫理的なスクレイピング慣行への準拠状況を慎重に評価することが重要です。
429 エラーを引き起こさないスクレイピングの例
上記のベスト プラクティスの有効性を説明するために、429 エラーを引き起こさずに Web サイトをスクレイピングする例をいくつか見てみましょう。
例 1: スロットリングとプロキシを使用したニュース Web サイトのスクレイピング
人気のニュース Web サイトから記事をスクレイピングするとします。レート制限に達しないようにするには、スロットルを実装し、プロキシを使用してリクエストを複数の IP アドレスに分散します。 Python とリクエスト ライブラリを使用した簡略化された例を次に示します。
import requests
from time import sleep
from random import randint
proxies = [
{"http": "http://proxy1.example.com"},
{"http": "http://proxy2.example.com"},
{"http": "http://proxy3.example.com"}
]
def scrape_articles():
base_url = "https://example.com/articles?page="
num_pages = 10
for page in range(1, num_pages + 1):
proxy = proxies[randint(0, len(proxies) - 1)]
url = base_url + str(page)
try:
response = requests.get(url, proxies=proxy)
response.raise_for_status()
# Process the article data
sleep(randint(1, 3)) # Add random delay between requests
except requests.exceptions.RequestException as e:
print("Error occurred:", e)
scrape_articles()この例では、プロキシのリストを定義し、リクエストごとにプロキシをランダムに選択します。記事ページを繰り返し処理し、異なるプロキシを使用して各ページにリクエストを送信します。人間のような動作をシミュレートし、リクエストの送信が速すぎることを避けるために、リクエスト間にランダムな遅延を追加します。リクエストを複数の IP アドレスに分散し、リクエストを調整することにより、レート制限がトリガーされたり 429 エラーが発生したりする可能性が減ります。
例 2: セッションと Cookie を使用した電子商取引 Web サイトのスクレイピング
セッションベースのレート制限を使用する電子商取引 Web サイトから製品情報をスクレイピングするとします。セッションと Cookie を適切に処理するには、Python で request.Session() を使用します。以下に例を示します。
import requests
def scrape_products():
base_url = "https://example.com/products?page="
num_pages = 5
with requests.Session() as session:
for page in range(1, num_pages + 1):
url = base_url + str(page)
try:
response = session.get(url)
response.raise_for_status()
# Process the product data
except requests.exceptions.RequestException as e:
print("Error occurred:", e)
scrape_products()この例では、 requests.Session() スクレイピングプロセス全体を通じてセッションを維持します。製品ページを繰り返し処理し、セッションを使用してリクエストを作成します。セッションを使用すると、Cookie やその他のセッション関連情報を保存でき、Web サイトがリクエストを同じユーザー セッションの一部として扱うことが保証されます。これにより、セッションベースのレート制限がトリガーされるのを防ぎ、429 エラーが発生する可能性が減ります。
まとめ
429 ステータス コードの処理は Web スクレイピングでは避けられない部分ですが、原因を理解し、ベスト プラクティスを実装することで、これらのエラーが発生する可能性を大幅に減らすことができます。リクエストのスロットル、リクエストの複数の IP アドレスへの分散、robots.txt の尊重、人間の動作のシミュレート、セッションと Cookie の適切な処理はすべて、レート制限のトリガーを防ぐための効果的な戦略です。
Web スクレイピングは常に責任を持って倫理的に行う必要があることを忘れないでください。 Web サイトの利用規約を尊重し、法的ガイドラインを遵守し、スクレイピング活動が Web サイトのリソースに与える影響に注意してください。ベスト プラクティスに従っているにもかかわらず 429 エラーが継続的に発生する場合は、Web サイトの所有者に連絡するか、代替データ ソースを検討することを検討してください。
このガイドで説明されているテクニックとベスト プラクティスを適用すると、サービスを中断したり使用ポリシーに違反したりすることなく、429 ステータス コードに対処し、Web サイトを正常にスクレイピングする準備が整います。ハッピースクレイピング！
