HTTP 429 Too Many Requestsは、一定時間内のリクエストが多すぎることを示す応答です。ただし、何回で制限されるか、利用者をどの単位で数えるかはサービスごとに異なります。
429を受けたときは、待ち時間だけでなく、同じ枠を使う別の処理と再試行の条件を確認します。
429だけでは制限枠は分からない
RFC 6585は429を定義していますが、利用者の識別方法や要求の数え方を固定していません。APIキー単位、利用者単位、特定の操作単位など、実際の条件は利用先の仕様で調べます。
仮に一つの連携処理の回数が少なくても、複数のジョブが同じ契約枠を使っていれば、全体の呼出しが影響する可能性があります。自分のプロセスだけを見て制限値を推定しないことが大切です。
Retry-Afterの有無と値を確認する
429の応答はRetry-Afterを含む場合がありますが、必須ではありません。値の形式には秒数とHTTP日時があります。RFC 9110のRetry-After
| 観測した状態 | 次に確認すること |
|---|---|
| 待ち時間が示されている | 値の形式、対象の要求、サービスの再送条件 |
| 待ち時間がない | 公式の制限仕様、利用状況、エラー本文 |
| 複数処理で発生 | 共有する資格情報や契約枠、実行時刻 |
| 待っても続く | 制限単位の誤認、継続する別処理、停止条件 |
待ち時間が経過したことは、次の要求が必ず成功するという保証ではありません。制限が続いたときの停止・通知も決めます。
再試行の回数と担当をまとめる
アプリ、ジョブ基盤、HTTPクライアントがそれぞれ再試行すると、一件の失敗から想定以上の要求が生じるおそれがあります。再送を担う層を整理し、回数と総待ち時間の上限を共有します。
仮に三つの処理が同じAPIを同時に使う場合、各処理が個別に待つだけでなく、全体として開始をずらす、同じ取得をまとめる、不要な呼出しを減らすなどを検討できます。これらは負荷を抑える設計案であり、利用規約や提供元の制限を回避する方法ではありません。
更新処理では結果を先に確かめる
参照と更新では、再送時に確認するリスクが異なります。注文や決済などの更新は、APIの再試行契約や識別子の扱いを確認し、結果不明の処理を無条件で繰り返さないようにします。
429の意味と、別途発生したタイムアウトや通信切断を混ぜないことも必要です。どの要求に何が返ったか、記録を対応づけます。
再発時に判断できる記録を残す
発生時刻、操作、機密値を含まない枠の識別、応答コード、Retry-After、再試行の回数、最終結果を残すと、呼出し方を見直せます。記録の扱いはログ管理の基本も参考になります。
制限の単位・待機条件・再送上限を一組にして、待つ・減らす・止める判断を行いましょう。