Redisでレート制限を実装するにはどうするか？

Question

Accepted Answer

**レート制限**（時間ウィンドウ内でリクエスト/アクションがいくつまで許可されるかを制限すること）はRedisの一般的なユースケースです。Redisの高速なアトミックカウンターとTTLはこのために理想的です。複数のアルゴリズム（固定ウィンドウ、スライディングウィンドウ、トークンバケット）が存在し、それぞれトレードオフがあります。

## 固定ウィンドウ（最も単純）

```js
// allow N requests per time window using an atomic counter with a TTL
async function rateLimit(userId, limit = 100, windowSec = 60) {
  const key = `rate:${userId}:${Math.floor(Date.now() / 1000 / windowSec)}`;
  const count = await redis.incr(key);     // atomic increment
  if (count === 1) await redis.expire(key, windowSec);  // set TTL on first request
  return count <= limit;                    // allowed if under the limit
}
// → INCR is atomic (correct under concurrency); the key auto-expires each window
```

**固定ウィンドウ**アプローチ：（ユーザー、時間ウィンドウ）ごとのアトミックカウンターにTTLを設定し、リクエストごとにインクリメント、制限を超えたら拒否します。アトミック`INCR`と自動有効期限を活用した、シンプルで効率的です。

```text
✗ Limitation: bursts at window boundaries (2x limit possible across two adjacent windows)
```

## スライディングウィンドウ（より滑らか）

```text
SLIDING WINDOW → tracks requests over a rolling time period (no boundary bursts)
  → often uses a SORTED SET: add each request with a timestamp score,
    remove old entries (ZREMRANGEBYSCORE), count remaining (ZCARD)
  ✓ More accurate/smooth  ✗ More memory and complexity
```

## トークンバケット（制御されたバースト許可）

```text
TOKEN BUCKET → tokens refill at a steady rate; each request consumes a token
  → allows bursts (up to the bucket size) while limiting the average rate
  → often implemented with a Lua SCRIPT for atomic check-and-consume
```

## Redisがこれに理想的な理由

```text
✓ ATOMIC counters (INCR) → correct under concurrency, no race conditions
✓ Fast (in-memory) → minimal latency added to each request
✓ TTL → automatic window cleanup (no manual expiry management)
✓ SHARED across servers → distributed rate limiting (all app servers use one Redis)
→ Redis is the standard tool for distributed rate limiting.
```

## なぜ重要なのか

Redisでレート制限を実装することは一般的で実践的なユースケースであり、これを理解することは価値のある知識です。レート制限（APIやサービスを不正使用から保護し、公正な使用を確保し、過負荷を防止）はほぼ普遍的なニーズであり、Redisがそのための標準的なツールです。

**Redisが理想的な理由**を理解することが重要です。**アトミックカウンター**（`INCR`）は並行性下でのレート計数を正確にします（競合状態や計数損失なし）。**高速性**（インメモリ）は各リクエストに最小限のレイテンシを追加します。**TTL**はウィンドウクリーンアップを自動的に処理し、重要なことに**サーバー間で共有**されるため、すべてのアプリケーションサーバーが1つの一貫した制限を強制する**分散レート制限**が可能です（複数サーバーデプロイメントでは不可欠で、サーバーごとのインメモリ制限では機能しません）。

**アルゴリズム**とそのトレードオフを理解することで、適切に選択できます。**固定ウィンドウ**（最も単純で、時間ウィンドウごとのアトミックカウンターですが、境界バースト許可）、**スライディングウィンドウ**（タイムスタンプ付きリクエストのソート済みセットを使用した、より滑らかで正確な方法ですが、メモリコスト増加）、**トークンバケット**（制御されたバースト許可と平均レート制限、しばしばアトミック性のためのLuaスクリプト経由）です。

これらを実装する方法（特に`INCR` + `EXPIRE`を使った単純で一般的な固定ウィンドウパターン）を知ることは、実践的で適用可能なスキルです。

レート制限はサービス保護の一般的な要件であり、Redisはそのための標準的で理想的なツール（アトミックカウンター、高速性、TTL、サーバー間共有）であるため、Redisでの実装方法を理解することは、アルゴリズム、トレードオフ、そしてなぜRedisが適しているのかを含めて、堅牢で保護されたサービスを構築するための価値のある、頻繁に適用できる知識であり、キャッシング以外の最も一般的な実践的なRedis応用の1つです。