API レート制限

目次

• 概要
• 使用時機
• クイックスタート
• リファレンスガイド
• ベストプラクティス

概要

複数のレート制限アルゴリズムを使用して、ユーザー別、IP別、エンドポイント別の戦略でAPIを悪用から保護し、トラフィックを管理します。

使用時機

• APIをブルートフォース攻撃から保護する
• トラフィックスパイクを管理する
• 段階的なサービスプランを実装する
• DoS攻撃を防止する
• リソース割り当てにおける公平性を確保する
• クォータと使用制限を実装する

クイックスタート

最小限の動作例：

// Token Bucket Rate Limiter
class TokenBucket {
  constructor(capacity, refillRate) {
    this.capacity = capacity;
    this.tokens = capacity;
    this.refillRate = refillRate; // tokens per second
    this.lastRefillTime = Date.now();
  }

  refill() {
    const now = Date.now();
    const timePassed = (now - this.lastRefillTime) / 1000;
    const tokensToAdd = timePassed * this.refillRate;

    this.tokens = Math.min(this.capacity, this.tokens + tokensToAdd);
    this.lastRefillTime = now;
  }

  consume(tokens = 1) {
    this.refill();

    if (this.tokens >= tokens) {
      this.tokens -= tokens;
      return true;
    }
// ... (詳細な実装はリファレンスガイドを参照)

リファレンスガイド

references/ ディレクトリの詳細な実装：

ベストプラクティス

✅ すべきこと

• レスポンスにレート制限ヘッダーを含める
• 分散レート制限にRedisを使用する
• 異なるユーザープランに対して段階的な制限を実装する
• 適切なウィンドウサイズと制限を設定する
• レート制限メトリクスを監視する
• 明確なリトライガイダンスを提供する
• APIドキュメントにレート制限を記載する
• 高負荷下でテストを行う

❌ すべきでないこと

• 本番環境でメモリ内ストレージを使用する
• 制限を過度に厳しく設定する
• Retry-Afterヘッダーを含め忘れる
• 分散シナリオを無視する
• レート制限を公開する（セキュリティ上の理由）
• 分散システムで単純なカウンターを使用する
• 古いデータのクリーンアップを忘れる