【テクニカル・上級編】レートリミットの設計：トークンバケットアルゴリズム – Web APIアーキテクチャ・データ連携実践ガイド

トークンバケットの深淵：レートリミットを越えて「ネットワークの呼吸」を制御する

我々が日々設計するAPIのエンドポイントは、単なるデータの出入り口ではない。それは、背後のデータベース、キャッシュ層、そしてネットワークの帯域という有限のリソースを守るための防波堤だ。

特にREST APIにおけるレートリミット設計は、単なる「回数制限」で片付けてはいけない。今日は、多くの現場で採用されながらも、その数学的・物理的本質が見落とされがちな「トークンバケットアルゴリズム」について、インフラ屋の視点から深掘りしていこう。

—

1. なぜ「固定ウィンドウ」ではなく「トークンバケット」なのか

多くの初学者が選ぶ「固定ウィンドウ（Fixed Window）」方式は、実装が容易だが大きな欠陥を抱えている。それは境界値における「バーストの集中」だ。例えば「1分間に100リクエスト」という制限を設けた場合、0秒と59秒にリクエストが集中すれば、実質的にその一瞬で200リクエストを処理しなければならず、バックエンドのTCP接続キューは瞬時に飽和する。

一方、トークンバケットアルゴリズムは、バケット（バッファ）内にトークンを蓄積し、リクエストが来るたびにそれを消費する。

バーストの許容: バケットが満タンであれば、短時間に数発のパケットを流せる。
平均レートの制限: トークンの補充速度（Refill Rate）によって、長期間の平均トラフィックを厳密に制御できる。

これは、ルーターにおける「トラフィックシェーピング」と全く同じ概念だ。バックエンドのCPUが「呼吸」をするように、パケットを平準化して流し込む。これが、高負荷時におけるシステム崩壊を未然に防ぐための唯一の解となる。

—

2. パケットレベルの最適化とTLSハンドシェイクの罠

レートリミットを導入する際、忘れてはならないのが「リミット判定のためのコスト」だ。リミットの判定ロジックが重すぎて、TLSハンドシェイクの最中にCPUが張り付いてしまっては元も子もない。

TCP/TLSハンドシェイクの高速化

レートリミットを適用するゲートウェイ（NginxやEnvoyなど）では、以下のチューニングが必須だ。

# TCPウィンドウサイズの拡大（RTTが長い通信の効率化）
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 16384 16777216"

# TLS 1.3の強制と0-RTT（Early Data）の慎重な利用
# 0-RTTはリプレイ攻撃の脆弱性があるため、冪等性のあるGETリクエストのみに限定する
ssl_protocols TLSv1.3;

レートリミット用のカウンタは、Redis等のインメモリDBに置くのが一般的だが、ここで「RTT（往復時間）」がボトルネックになる。Redisとの通信をいかにオフロードするかが、スループット向上の鍵だ。

—

3. トークンバケットの実装例：LuaとRedisの協奏

Nginxの ngx_http_lua_module を使えば、リクエストのパケット処理と同時に極めて低レイテンシでレートリミットを判定できる。

-- Luaスクリプト：Redisを使ったトークンバケット判定
local redis = require "resty.redis"
local red = redis:new()

-- 接続プールを利用してハンドシェイク時間を最小化
red:set_timeout(50)
local ok, err = red:connect("127.0.0.1", 6379)

-- Luaのスクリプトでアトミックに実行（レースコンディションを防止）
local script = [[
  local tokens = redis.call('get', KEYS[1]) or ARGV[1]
  tokens = tonumber(tokens) - 1
  if tokens < 0 then
    return 0
  else
    redis.call('set', KEYS[1], tokens)
    return 1
  end
]]

local res, err = red:eval(script, 1, "rate_limit:user_123", 10) -- バケットサイズ10

ここで重要なのは、eval を使ってRedis側でロジックを完結させることだ。アプリケーションサーバーとRedisの間を何度も往復（ラウンドトリップ）させると、TCPのACK待ちでネットワーク帯域とCPUが浪費される。

—

4. セキュリティとネットワーク設計の盲点

レートリミットは、DoS攻撃への防御策として語られるが、「ヘッダー圧縮」と「リクエストサイズ」の視点が抜けているケースが多い。

1. HPACK圧縮の活用: HTTP/2以降、ヘッダーはHPACKによって圧縮される。しかし、悪意あるクライアントが極端に長いヘッダーを送り続けると、メモリが枯渇する。client_header_buffer_size の制限は必須だ。
2. TCPバッファの最適化: レートリミットを適用してパケットをドロップ（429 Too Many Requests を返す）する場合、OSレベルで tcp_abort_on_overflow を有効にしていると、接続が強制的にRSTパケットで切断され、クライアント側でリトライの連鎖（Thundering Herd Problem）が起きる可能性がある。適切に 429 ヘッダーを返し、Retry-After を含めることで、クライアントに「少し休め」という指示を出すのがプロトコル上の作法だ。

—

終わりに：ネットワークは「生き物」である

スペックシート上の数値や、教科書的なアーキテクチャ図はあくまで「静止画」に過ぎない。現実のネットワークは、パケットのロス、TCPの輻輳制御、TLSハンドシェイクの微細な遅延が絡み合う「生き物」だ。

トークンバケットアルゴリズムは、この予測不可能なトラフィックに対して、システムに「リズム」を与えるための調律師である。美しいエンドポイント設計とは、単にURLの命名規則が整っていることではない。「過負荷に直面したとき、システムがどれほど優雅に、そして論理的に振る舞えるか」、それこそが真のアーキテクトが目指すべき地平なのだ。

今日の設計が、明日の安定した通信を支える。さあ、次はどのプロトコルの深淵を覗こうか。