rate limitingとは何か? リクエスト量を上限で抑える

rate limitingとは、クライアントが一定の時間枠内に行えるリクエスト数を上限で抑えるポリシーで、過剰なリクエストを拒否することでサービスを過負荷や不正利用から守ります。

APIは無制限のリクエストを処理できないため、期間あたり一定数の呼び出しを許可し残りを拒否するrate limitを適用します。APIを密なループで呼び出す、あるいは同じAPIに対して多くのjobを同時に実行するpipelineは、日常的にこれらの上限に突き当たり、それを丁寧に扱う必要があります。

期間ごとの上限

rate limitは、クライアント、token、IPにスコープされた、分あたりや時間あたりのリクエストといった予算を定義します。予算を使い切ると、以降のリクエストは時間枠がリセットされるまで拒否されます。

429の応答

上限を超えると、APIは429 Too Many Requestsを返し、しばしばどれだけ待つべきかを伝えるRetry-Afterヘッダーを付けます。そのヘッダーを尊重するのが正しいbackoffの方法です。

CIが上限に当たる仕組み

多くの並列jobが1つのAPI tokenを共有する。
呼び出し頻度が高すぎる密なポーリングループ。
呼び出し回数を掛け算するmatrix build。

上限を丁寧に扱う

Retry-Afterを尊重し、jitter付きのbackoffを加え、応答をcacheし、不要な呼び出しを減らしましょう。リクエストを時間的に分散させると、pipelineは叩き続けてブロックされる代わりに上限の下に留まります。

gatewayでの上限

rate limitingは、しばしばサービスの前のAPI gatewayで適用されるため、429はリクエストがbackendに到達する前にgatewayから来ることがあります。

一時的でretry可能

429は、不正なリクエストを示す4xxと違い、指示された待機の後に明示的にretry可能です。Latchkeyのrunnerは一般的なエンドポイントからの一時的な429をbackoffしてretryし、Retry-Afterを尊重するため、短いthrottlingがjobを失敗させることはありません。

重要なポイント

rate limitingは、サービスを過負荷から守るために期間あたりのリクエストを上限で抑えます。
上限を超えると429が返り、通常は尊重すべきRetry-Afterが付きます。
429はbackoffを伴えばretry可能で、不正なリクエストを意味する4xxとは異なります。