429 Too Many Requestsとは何か? rate limitに当たる

429 Too Many Requestsとは、クライアントがrate limitで許可される数を超えてリクエストを送り、再試行の前に待つ必要があるときにサーバーが返すHTTPステータスです。

ほとんどの4xxエラーと違い、429はリクエストが不正だったことを意味するのではなく、送りすぎ、速すぎたことを意味します。多くのjobへ広がったり、APIを積極的にポーリングしたりするpipelineは、429によく当たります。正しい対応はbackoffしてretryすることで、理想的には応答内のサーバーのヒントに従います。

rate-limitのシグナル

サーバーは、あなたのtoken、IP、アカウントについて許可されたリクエストレートを超えると429を返します。これは、静かに失敗する代わりにAPIが "減速して" と言う明示的な方法です。

ヘッダーを読む

Retry-Afterはどれだけ待つべきかを伝えます。
rate-limitヘッダーは残りのquotaとリセット時刻を報告します。
これらを尊重するのが、正しく礼儀正しいbackoffの方法です。

CIが429に当たる理由

matrix build、tokenを共有する並列job、密なポーリングループは、quotaを素早く使い切ることがあります。多くの呼び出しを短いバーストに集中させるのが通常の原因です。

正しくbackoffする

jitter付きの指数backoffを使い、retryが一斉に再試行するのではなく分散するようにします。cacheを加え、不要な呼び出しを削って、そもそも上限の下に留まりましょう。

retry可能、ただし待機を伴う

429はretryが意図されている数少ないクライアント側コードの1つですが、指示された遅延の後だけです。すぐにretryすると別の429を招くだけで、ペナルティを延ばすことがあります。

runnerでの自動backoff

堅牢なツールは429を検知し、Retry-Afterを尊重した後にretryします。Latchkeyのrunnerは一般的なエンドポイントからの一時的な429をbackoffしてretryするため、短いthrottlingが本来健全なjobを失敗させることはありません。

重要なポイント

429はrate limitを超えたことを意味し、retryの前に待つべきです。
すぐにretryせず、Retry-Afterとrate-limitヘッダーを尊重しましょう。
他のほとんどの4xxエラーと違い、遅延の後にretry可能です。