レート制限（Rate Limiting）

レート制限は、クライアントが API を呼び出せる頻度を制限する仕組みです。たとえば「API キーごとに 1 分あたり 100 リクエスト」のように設定し、上限を超えたリクエストはウィンドウがリセットされるまで拒否されます。サービスを過負荷や悪用から守り、1 つの騒がしいクライアントがほかのクライアントのリソースを奪うのを防ぎ、パスワード推測のような攻撃を遅らせます。上限は通常、API キー、ユーザー、トークン、IP アドレスのいずれかの単位で管理されます。

例

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30

{"error": "rate_limited", "message": "Try again in 30 seconds"}

429 Too Many Requests と Retry-After は標準の HTTP です。X-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Reset のように残りの割り当てを伝えるヘッダーは広く使われる慣習ですが、単一の標準ではないため、対象 API のドキュメントを確認してください。

主なアルゴリズム

• 固定ウィンドウ（fixed window）: 暦上の 1 分ごとにリクエストを数えます。シンプルですが、クライアントがウィンドウの境界をまたいで 2 倍のバーストを送れてしまいます。
• スライディングウィンドウ（sliding window）: 直近 N 秒間のリクエストを数えるため、境界の影響がならされます。
• トークンバケット（token bucket）: トークンが一定の速度で補充され、リクエストごとに 1 つ消費されます。平均レートを守らせつつ、バケットサイズまでの短いバーストを許容します。

テストすべきこと

• 上限そのもの: 上限 + 1 件のリクエストを送り、超過した 1 件だけが 429 を受け取ることを確認します。
• 回復: Retry-After またはリセット時刻を過ぎたら、再びリクエストが成功します。
• スコープ: あるユーザーやキーのトラフィックが、別のユーザーやキーの割り当てを消費してはいけません。上限がキー単位、ユーザー単位、IP 単位のどれで適用されるか、そして安価に変えられる何かを入れ替えるだけでクライアントが上限を回避できないかを確認します。
• 機密性の高いエンドポイント: ログイン、パスワードリセット、OTP 検証には、通常の読み取りより厳しい上限を設けるべきです。
• レスポンス形式: 拒否されたリクエストは、500 やハングした接続ではなく、役に立つボディ付きの 429 を返します。
• クライアントの振る舞い: 自社のクライアントが、短いループで再試行するのではなく、バックオフして Retry-After を守ることを確認します。

レート制限とテストスイート

並列実行の API テストや負荷テストは、本番相当の上限に引っかかり、テスト対象の変更とは無関係な理由で失敗することがあります。テスト環境では専用のキーを使うか上限を引き上げましょう。また、容量の測定を目的とする負荷テストでは、レートリミッターではなくサービスそのものを測っていることを確認してください。