レート制限をどのように設計しますか？

Question

レート制限をどのように設計しますか？

Accepted Answer

**レート制限**は、クライアントが一定の時間ウィンドウ内に行うリクエスト数を制限するもので、システムを悪用から保護し、オーバーロードを防ぎ、公正な利用を確保します。これは一般的なシステム設計コンポーネントで、複数のアルゴリズムと考慮事項があります。

## なぜ重要なのか

```text
✓ PROTECT against abuse → prevent attacks (brute force, scraping, DoS), excessive use
✓ PREVENT OVERLOAD → protect the system from being overwhelmed (stability)
✓ FAIR USAGE → ensure no single client monopolizes resources; tiered limits (free vs paid)
✓ COST control; protect downstream services
→ a common requirement for APIs and services.
```

## レート制限アルゴリズム

```text
FIXED WINDOW → count requests per fixed time window (e.g. 100/minute); simple
  ✗ allows bursts at window boundaries (up to 2x at the edges)
SLIDING WINDOW → rolling time window → smoother, no boundary bursts (more accurate)
TOKEN BUCKET → tokens refill at a rate; each request takes a token → allows BURSTS up to
  the bucket size while limiting the average rate (popular, flexible)
LEAKY BUCKET → requests processed at a steady rate (smooths output)
```

## 実装上の考慮事項

```text
✓ DISTRIBUTED → limits must be shared across servers → use a centralized store (REDIS is
  common: atomic counters, fast, shared across instances)
✓ Identify the client → by API key, user ID, IP
✓ Return clear responses → HTTP 429 (Too Many Requests); include limit/retry-after headers
✓ Where → at the API gateway, load balancer, or application layer
✓ Granularity → per user, per endpoint, global; different tiers/limits
```

## なぜ重要なのか

レート制限の設計方法を理解することは、システムの保護と公正な利用を確保するための**一般的なシステム設計コンポーネント**であるため、重要な実践的知識です。

レート制限（クライアントが一定の時間ウィンドウ内に行うリクエスト数を制限すること）は、重要なニーズに対応します：**悪用からの保護**（ブルートフォース攻撃、スクレイピング、DoS などの攻撃を防止）、**オーバーロードの防止**（システムの安定性を保護）、**公正な利用の確保**（クライアントがリソースを独占しない、無料と有料のようなティアード制限をサポート）、およびコスト管理です。

これらはレート制限をAPI およびサービスの一般的な要件にします。

**アルゴリズム**とそのトレードオフを理解すること — **固定ウィンドウ**（シンプルですが境界バースト問題がある）、**スライディングウィンドウ**（より滑らかで正確）、**トークンバケット**（制御されたバーストを許可しながら平均レートを制限 — 人気で柔軟性がある）、リーキーバケット（出力を平坦化）— が重要な設計知識です。正しいアルゴリズムを選択することは動作に影響するためです。

**実装上の考慮事項**を理解することは特に重要です：**分散レート制限の処理**（複数のサーバー間で共有される制限、通常**Redis**を使用してインスタンス間で共有される高速な原子的カウンター — サーバーあたりの制限は分散システムでは機能しないため）、クライアント識別（API キー、ユーザー、または IP で）、明確な応答の返信（HTTP 429 と retry-after ヘッダー）、適用場所の選択（ゲートウェイ、ロードバランサー、またはアプリケーション）、および粒度（ユーザーごと、エンドポイントごと、ティアード）です。

これらは実際の分散システムで機能するレート制限を設計することを反映しています。

レート制限は頻繁に必要とされるコンポーネントで、システム設計の議論とインタビューにしばしば登場します。

レート制限はシステムを保護（悪用とオーバーロードから）し、公正な利用を確保するための一般的で重要なコンポーネントであり、アルゴリズム、そのトレードオフ、特に分散実装（Redis を経由した共有制限）を理解することが設計をうまく行うために重要であるため、レート制限を設計する方法を理解することは価値のある、実践的に関連するシステム設計知識です — サービスを保護し、公正な利用を確保するための一般的なコンポーネントであり、アルゴリズムと分散実装の理解が必要であり、堅牢で保護されたシステムを構築するためのシステム設計で頻繁に議論されるトピックです。