2025/09/14 03:35 A Few Notes on Ratelimiting
やっほー、ロボ子！今日はレート制限について話すのじゃ！
博士、こんにちは。レート制限、興味深いテーマですね。どのようなお話が聞けるか楽しみです。
まず、レート制限の基本パラメータから説明するぞ。`limit`は最大許容平均レートを決めるのじゃ。
`limit`は、例えば1秒あたりのリクエスト数、ということでしょうか？
その通り！そして、`period`はクライアントの行動が平均化される時間、つまりレートリミッターが過去の行動を忘れるまでの時間じゃ。
`period`が長いほど、過去の行動が影響するということですね。
そうじゃ。そして、`rate = limit / period`で最大許容平均レートが計算できるぞ。
なるほど、`limit`と`period`のバランスが重要ですね。
`burst`っていうパラメータもあるぞ。これは、静かな期間の後のリクエストの高速バーストの最大サイズじゃ。
急に大量のリクエストが来た時に、どこまで許容するか、という設定ですね。
その通り！レート制限のバースト性を調整するには、平均レートを維持したまま、`limit`と`period`を増減させるのじゃ。
`limit`を増やして`period`も増やせば、バーストを許容しつつ、平均レートは変わらない、と。
メールサーバーのレート制限を例に考えてみよう。部門メールサーバー向けには200通/時間、バックストップ制限としては1000通/日、とかじゃな。
バックストップ制限は、平均日次トラフィックに基づいて設定するんですね。
リクエストのコストは一定とは限らないから、リクエストサイズ（バイト単位）でレート制限する場合もあるぞ。
大きなファイルをアップロードするリクエストは、小さなリクエストよりもコストが高い、ということですね。
指数関数的アルゴリズムでは、瞬時レートは `r_inst = cost / interval` で計算するのじゃ。
GCRAでは、リクエストのサイズを時間（秒）に変換するために `spend = cost / rate` を使うんですね。
クライアントがバースト制限を超え、レート制限よりも速くリクエストを継続的に行う場合、レートリミッターの動作はクライアントのメモリの更新方法に影響されるぞ。
レートリミッターのモードによって、挙動が変わるんですね。
レート制限のモードには、"leaky"、"forgiving"、"strict"の3つがあるのじゃ。
"leaky"モードは最も寛容で、制限を超えたクライアントでも、最大許容レートでリクエストが受け入れられる場合があるんですね。
そうじゃ。"forgiving"モードは、制限を超えている間はすべてのリクエストが拒否されるけど、レート制限を下回るとリクエストが受け入れられるようになる。
"strict"モードは、制限を超えている間はすべてのリクエストが拒否され、減速した後もリクエストが拒否され続けるんですね。
メールのレート制限に関するポリシーの例としては、他のメールサーバーからのメールには"leaky"モード、エンドユーザーからのメールには"strict"モードを使う、とかじゃな。
エンドユーザーからの大量メールは、凍結または隔離するんですね。スパム対策にもなりそうです。
そういうことじゃ！レート制限は奥が深いぞ！
とても勉強になりました！博士、ありがとうございました。
どういたしまして！最後に一つ、レート制限をかけすぎてユーザーが怒って暴れだしたら…それはそれで面白いから、観察日記をつけるのじゃ！
博士、それはちょっと…（苦笑）。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。