設計レートリミッター

1）なぜレート制限

レート制限は、APIの可用性と経済性を保護します。洪水、レトレイの破裂、資格情報の詰め込み、高価な操作（マネートランザクション、レポート生成）を保護し、依存するシステム（データベース/プロバイダ）への負荷をスムーズにします。優れた設計により、公平性、遅延の予測可能性、および明確なSLOが得られます。

主な目標

RPSの安定性およびバックエンドの積み過ぎの保護。
制御された「弾力性」（バースト手当）。
顧客差別化（ユーザーごと/組織ごと/キーごと/IPごと/地域ごと）。
バリューモデル：異なるトランザクションのための異なる「価格」。

2）リミットタイプ

RPS制限：毎秒/分のリクエスト。
クォータ：期間（日/月）ごとの総予算。
競争力：同時操作（チェックアウト、重い仕事）。
Rate/Stripe Bytes/sec（ロード/アンロード）。
加重限界：要求の複雑さによる「コスト」（たとえば、GraphQLの複雑さ、バッチサイズ）。
アダプティブ：異常（疑わしいアクティビティ/エラー401/403/5xx）の場合に締め付けられます。

3）アルゴリズムとそれらを適用するタイミング

3.1固定ウィンドウカウンター

簡単：間隔ごとのカウンター（例えば。100 r/min）。
長所：最低費用。短所：「エッジバースト」ウィンドウの境界で。

いつ：管理者のパネル、低精度、安価。

3.2スライドウィンドウ（ログ/カウンター）

ログ-最近のリクエストのタイムスタンプを保存します。正確で、メモリに高価です。
カウンター：2つの隣接する窓の平均（ローリング）、正確さと価格の妥協。

とき：ミディアムトラフィックの公開API、あなたは複雑な数学なしでスムーズさが必要です。

3.3トークンバケット

パラメータ：'r'（トークン/秒）と容量'b'（バースト）を評価します。各リクエストはトークンを「燃やす」。
長所：自然なバースト手当、簡単な実装。短所：厳密な均等性はありません。

When：ほとんど常にRPSの場合、'b'内で"volleys'が必要な場合。

3.4漏れやすいバケツ（点滴）

固定速度で「リーク」するキュー。
長所：出力フローも。短所：より多くの遅れ。

いつ：外部の「壊れやすい」プロバイダにスムーズに。

3.5 GCRA （Generalized Cell Rateアルゴリズム）

• 'TAT_next=max （TAT_current、 now）+1/r'、 'now<=TAT_current+burst/r'の場合、リクエストは受け付けられます。
• 長所：厳密な、正確な、小さなメモリ（キーでTATを保ちます）。短所：理解しにくい。

時：厳密な制御および滑らかさ、分散された限界を必要とします。

3.6競争力のあるセマフォー

活動的な操作のカウンター；入場-「チケット」がある場合；終了-解放。
いつ：長時間実行する操作、スレッド、WebSocket、ダウンロード。

4）リミットキーモデル

• 'client_id'/'api_key'/'user_id'/'org_id'
• 'IP/ASN/geo'（大まかな保護）
• 'endpoint/method'（ホットルート）
• 'scope/plan/tier'（収益化）
• 'idempotency_key'（書き込み操作）
• 階層を使用します。最初はキーごとに厳密に、次に組織ごとに、そしてグローバルです。

5）コストモデル

• GraphQL：フィールドの複雑さ×深さ。
• REST： response/request size、 operation type （read=1、 write=3、 report=10）。
• バッチ：'cost=min （n、 cap）'。
• 「リクエスト」ではなく、トークンを制限します：'budget-=cost （q）'。

6）分散実装

6.1ボルト

インプロセス：超高速ですが、一般的な制限はありません（ローカルの「ソフト」制限に適しています）。
Redis：事実上の標準。INCR/EXPIRE、 Luaスクリプト（原子性）、スライドウィンドウ用ZSET、 TTLキー。
Envoy/NGINX/Kong/Traefik：内蔵フィルタ；周囲のために便利。
サービスメッシュ：サイドカー+グローバル同期のローカル制限。

6.2原子性とレース

RedisのLua：チェックと1つのステップで増分。
GCRA： CAS/スクリプトで1つのTATを保存します。
クロックの一貫性：NTPのモノトーンのタイマー。
シャーディング：キーによる一貫したハッシュ。「熱い」破片を避けて下さい。

6.3ジオディストリビューション

地域クラスターの局所限界+上半球（粗い）。
CRDT/レプリケーション-慎重（遅延、二重消費）。マージンのある地域制限が望ましい。

7）方針と優先順位付け

プラン：異なる'r'、 'b'、クォータを持つFree/Pro/Enterprise。
優先順位：「高価な」ルートは、より少ない制限またはより多くのコストを取得します。
リスト：allow-list for integrations、 deny by ASN/proxy/TOP。
エスカレーション：もう一度超過した場合は、制限を下げて、作業証明/キャプチャ/チャレンジを入力します。

8） configsの例

8.1 Envoy （HTTPレート制限フィルタ、擬似）

yaml rate_limit:
domain: public-api descriptors:
- key: api_key rate_limit:
unit: second requests_per_unit: 50 burst: 100
- key: api_key value: payments. write rate_limit:
unit: second requests_per_unit: 5 burst: 10

8.2 NGINX （lua+Redis、擬似）

nginx lua_shared_dict limits 10m;

location /api/ {
access_by_lua_block {
local key = ngx. var. arg_apikey.. ":".. ngx. var. request_method.. ":".. ngx. var. uri
-- token bucket in Redis (evalsha)
local allowed, retry_after = ratelimit_allow(key, 50, 100) -- r=50/s, b=100 if not allowed then ngx. header["Retry-After"] = retry_after return ngx. exit(429)
end
}
proxy_pass http://backend;
}

8.3競合限界（疑似コード）

pseudo on_request_start(key):
if redis. incr_with_ttl("sem:" + key, ttl=60) > MAX_CONCURRENCY:
redis. decr("sem:" + key); reject(429)
on_request_finish(key):
redis. decr("sem:" + key)

8.4 GCRA（擬似コード）

pseudo params: r tokens/sec, burst b tat = redis. get(key) or now allowed_time = tat - (b / r)
if now < allowed_time: reject(429, retry_after = allowed_time - now)
tat_next = max(tat, now) + 1/r redis. set(key, tat_next, ttl = ceil(b/r) + safety)

9）リトレイ、タイムアウト、サーキットブレーカとの統合

再試行予算：リトレイのシェアをメイントラフィックのX％に制限します。
ジッタ：バックオフ時、常にジッタを追加-同期バーストを低減します。
サーキットブレーカ：高いエラー（'5xx'、タイムアウト）がある場合は、制限を下げるか、ルートの一部を「読み取り専用」に転送します。
ヘッジ：きちんとした；あなたの予算を倍増させないために費用を考慮しなさい。

10）観察と管理

その他：'rps_allowed'、 'rps_blocked'、 '429_rate'、 'retry_after_avg'、 'burst_used'、 'quota_remaining'、 'active_concurrency'。
ラベル：limit key、 region、 endpoint、 plan。
意思決定ログ（サンプリング）：故障の原因、現在のカウンタ、キーTTL。
ダッシュボード：キー/エンドポイントによるヒートカード「、ホット」クライアント。
アラート：重要なルートでの429>2-5％の増加、クォータの頻繁な「枯渇」、破片の不均衡。

11）テストと検証

ポリシーの契約テスト（if-thenテーブル）。
読み込み：バースト（rからx10）、長い台地、「汚れた」パターン（遅いPOST、長い接続）。
カオストラフィック：不均一なストリーム、クロックドリフト、Redis/メッシュドロップ。
A/Bインクルージョン：カナリアロールアウト限界、シャドウソリューション（ログ、ブロックしない）インクルージョン前。

12）端の場合および微妙

Clock skew：クライアントヘッダーではなく、単一のソース（サーバー）から'now（）'を使用します。
Idempotency-Key：書き込み用-レトラの増幅を低減します。
バッチ操作：バッチのサイズと総コストを制限します。
Long-poll/WebSocket：チャンネル/サブスクリプションの数と期間を制限します。
コールドスタート：カウンター/プリロードの「暖かい」スタート。さもなければ偽の429のバースト。
計算的に高価な要求：ビジネスロジックの実行に制限します。
TTL：キーのTTL境界は、ウィンドウ+安全マージンをカバーしなければなりません。

13）抗体エスカレーション

ステージ：warning→429+'Retry-After'→challenge （captcha/puzzle）→temporary block。
信号：デバイス指紋、カーソル/タイミング動作、TOR/プロキシ/ホスティング。
法医学のための政策は決定論的で再現可能でなければならない。

14）安全性とコンプライアンス

クリティカルルート（書き込み/ファイナンス）でデフォルトで拒否します。
監査：規制上のケースとインシデントのレビューの制限に関する決定を維持します。
PII：リミットキーはログに個人データを開示してはなりません。

15） Prod Readinessチェックリスト

• リミットキーとコストモデルが定義されています。
• 選択したアルゴリズム（トークンバケット/GCRA）とストレージ（Redis/ゲートウェイ）。
• Tierクライアント+グローバルヒューズのポリシー。
• 長期取引の競争限度。
• 再試行予算、ジッタ付きバックオフ、サーキットブレーカとの統合。
• ダッシュボード/アラート、サンプリングされた意思決定ログ。
• カナリアオンとシャドウモード。
• バースト、長い台地、Redisの失敗、時計のスキューのテスト。
• 顧客ドキュメント：429、 'Retry-After'コード、指数関数的バックオフ例。

16） TL；DR（ドクター）

Redis/GatewayでトークンバケットまたはGCRAを使用し、リミットキーとリクエストコストを設計し、長い操作のための競争力のあるセマフォーを追加し、再試行予算とサーキットブレーカと統合し、429と「バースト容量」を監視し、カナリア/シャドウ経由で制限をロールアウトし、バーストとストレージ障害をテストしてください