実際に達した上限を特定する
HTTP 429はリクエスト過多を示し、Retry-Afterを含む場合があります。数え方と適用範囲はサービスごとに異なります。平均が低くても、短時間の上限は超え得ます。
| 概念 | 制限するもの | 対応 |
|---|---|---|
| 割り当て | 一定期間の総量 | 共有枠を計画する。 |
| 頻度 | 短時間の到着数 | 開始時刻を分散する。 |
| 同時実行 | 処理中の操作数 | 並行する仕事を制限する。 |
| Retry-After: 120 | 120秒の待機 | 全体期限と再試行の安全性を確認する。 |
許可された負荷を計画する
- アカウント、プロジェクト、利用者、経路など、集計のキーを確認します。リセットのタイムゾーン、操作ごとの消費量、共有枠も調べます。
- 上限のあるキューで集中を平準化し、処理中の件数は別に制限します。キャンセルを伝播し、不要になった仕事を破棄します。
- Retry-AfterはHTTP日時または秒数として解釈します。全体の期限内で尊重し、存在しない場合も待機に上限を設けます。
保護を迂回せず再試行を判断する
429は、その操作を安全に繰り返せる証拠ではありません。冪等性、全体時間、回数を確認します。拒否件数とキュー長を測り、恒常的に契約を超える場合は需要を減らすか容量を相談します。
一次資料
レート制限の不正利用を可視化します。
リクエスト制限は、正当な利用と異常な行動を区別し、解釈可能なイベントを生成する場合に、より効果的に機能します。エラーコードだけでは、不正利用パターンの開始、期間、および影響範囲が隠蔽される可能性があります。
- しきい値、決定、経路、および最小限のコンテキストを秘密情報なしで記録します。
- 繰り返し拒否された場合と、正当なユーザーへの影響との相関関係を分析します。
- アラートが調査または適切な調整につながることをテストします。
一次資料：ACSC and partners — Event logging and threat detection. 関連する方法：実践ガイドを読む.