HTTP 429 Too Many Requests：意味と解決方法

このエラーの意味と見分け方

• ブラウザ、APIクライアント、監視ツール、チェッカーが 429 Too Many Requests を受け取ります。
• レスポンスの影響はサイト全体ではなく、1つのURL、APIルート、HTTPメソッド、IPアドレス、アカウント、クライアントなどに限定される場合があります。
• 一定時間が経過するとリクエストが再び成功することがあり、一時的なレート制限と一致します。
• レスポンスに Retry-After やその他のレート制限関連ヘッダーが含まれる場合があります。
• DNSが名前解決でき、TLSネゴシエーションに成功していても、リクエストがHTTP対応のエンドポイントに到達しただけの可能性があります。これらの確認結果だけでは、アプリケーション層でリクエストが許可されたことは証明できません。
• 制限がIP、識別情報、トークン、セッションのいずれかを対象としている場合、クライアントやネットワークによって結果が異なることがあります。

可能性の高い順の主な原因

1. リクエストレートの制限を超えた。 アプリケーション、APIゲートウェイ、Webサーバーは、IPアドレス、アカウント、セッション、APIキー、ルート、その他のクライアント識別情報ごとにリクエストを制限する場合があります。
2. プロキシ、CDN、WAFが独自のポリシーを適用した。 中間処理装置は、リクエストがオリジンサーバーに到達する前に429を返すことがあります。
3. 自動化されたトラフィックが速すぎる間隔でリクエストを送信している。 クローラー、監視チェック、スクリプト、リトライ、並列ワーカーは、個々のリクエストが正しく見えても制限を引き起こすことがあります。
4. クライアントがバックオフなしでリトライしている。 障害後にリトライを繰り返すと、クライアントが制限ウィンドウ内に留まり続けたり、負荷が増大したりすることがあります。
5. 設定またはデプロイによって実効的なしきい値が変わった。 最近追加されたルール、ルーティングの変更、認証連携、プロキシポリシーによって、カウントまたは制限されるリクエストが変わった可能性があります。
6. 制限は意図されたものだが、クライアントのワークフローが対応していない。 たとえば、バッチ処理には、即時のリトライを繰り返すのではなく、リクエスト間隔の調整、コネクションの再利用、承認済みのリクエスト割り当てが必要な場合があります。

修正方法

訪問者とAPI利用者向け

1. 調査中は、短時間でのページ更新、並列リクエスト、自動リトライを停止します。
2. レスポンスヘッダーで Retry-After を確認します。存在する場合は、指定された待機時間または時刻まで待ってから再試行してください。
3. 待機後、同じメソッドを使って正確なURLまたはAPIエンドポイントを再試行します。制限を回避するためだけにメソッドを変更したり、リクエスト内容を繰り返し変えたりしないでください。
4. クライアントを管理している場合は、上限付きのリトライ、指数バックオフ、ジッターを使用し、サービスが文書化しているリクエスト割り当てを尊重します。APIがリトライ動作を定義していない限り、繰り返し実行しても安全でないリクエストをリトライしないでください。
5. 問題が1つのクライアント、アカウント、APIキー、ネットワーク、エンドポイントのどれに影響しているかを確認します。別のクライアントで結果が異なっても、それだけで原因を特定することはできません。
6. 429が続く場合は、エンドポイント、メソッド、タイムスタンプ、レスポンスヘッダー、リクエスト頻度の説明を添えて、サイトまたはAPIの所有者に連絡します。共有する情報からCookie、認証情報、APIシークレットを削除してください。

サイト所有者と開発者向け

1. 影響を受けたメソッド、URL、クライアント識別情報、リクエストレートに一致する、最小限の許可済みテストでレスポンスを再現します。ステータス、タイムスタンプ、関連するレスポンスヘッダーを記録してください。
2. レスポンスを生成したレイヤーを特定します。アーキテクチャに合った順序で、CDNまたはWAFのレスポンス詳細、リバースプロキシのログ、Webサーバーのログ、アプリケーションログを確認します。オリジンがレスポンスを生成したと決めつけないでください。
3. 関連するログで、同じタイムスタンプ、ルート、クライアント識別子、レート制限の判定を検索します。何がカウントされ、どの制限ウィンドウまたはポリシーが適用されたかを特定してください。
4. 影響を受けたリクエストを通常のリクエストと比較します。HTTPメソッド、認証コンテキスト、送信元の識別情報、ルート、キャッシュ経路、最近のデプロイまたは設定変更を確認してください。
5. 制限が意図されたものである場合は、クライアント向けの案内を改善します。適切な場合は正確な Retry-After 値を返し、割り当てを文書化し、クライアントが短いリトライループではなく制御されたバックオフを使用できるようにします。
6. 制限が誤っている場合は、レスポンスを生成したレイヤーに対して、許可を受けた最小限の修正を適用します。関係のないセキュリティ対策や不正利用対策を弱めることなく、影響を受けたルートへの効果を検証してください。
7. 同じリクエストとレートで再テストし、その後、周辺の代表的なルートとクライアント識別情報をテストします。意図した制限が引き続き機能し、正当なトラフィックがレスポンスによってブロックされなくなったことを確認してください。

予防と修正確認

• APIと自動化クライアントについて、リクエスト割り当て、制限の範囲、リトライ動作を定義し、文書化します。
• 適切な場合は、サービス設計でサポートされる Retry-After を含め、有用なレート制限情報を返します。
• クライアントでは、即時のリトライを繰り返すのではなく、上限付きの指数バックオフとジッターを実装します。
• ルート、クライアント識別情報、ネットワーク、デプロイごとに429の発生率を監視し、広範な増加と、限定的な不正利用または問題のあるクライアントを区別できるようにします。
• CDN、WAF、プロキシ、サーバー、アプリケーションのレート制限設定をバージョン管理し、リリース前に変更をレビューします。
• デプロイ後に重要なAPIメソッドと公開ルートをテストし、しきい値に達した場合の想定動作も確認します。
• 429レスポンスを生成したコンポーネントと照合できるよう、サニタイズ済みのリクエスト情報とポリシー判定のログを十分に保持します。

よくある質問