rate-limit

Upstash によるレート制限

レート制限は、不正利用とコストを管理するための対策の1つです。ミドルウェアを組み込む前に、ポリシーを設計してください。

ワークフロー

1. Next.js／ランタイム／バージョン、デプロイ先のプロキシ／CDN、認証／API キーのモデル、インストール済みの Upstash のバージョン、保護対象のルート、操作コスト、既存のクォータ、ミドルウェア／プロキシがすでにリクエストを処理しているかを確認します。
2. ルートのクラスごとに、識別子、アルゴリズム／ウィンドウ／バースト、コストの重み、ユーザー階層、レスポンスの動作、ストア障害時の動作を含むポリシー表を定義します。脅威とコストのトレードオフを推測できない場合に限り、質問してください。
3. 認証済みユーザー、API キー、またはテナント＋ユーザーの識別子を優先します。IP は匿名トラフィックに限り、デプロイ環境が提供する信頼できる情報源から取得する場合のみ使用します。パブリックインターネットからの任意の x-forwarded-for を信頼しないでください。信頼するプロキシの段数やプラットフォームのヘッダーを設定してください。不明なクライアントを 127.0.0.1 にまとめないでください。
4. 環境とルート／ポリシーごとに名前空間を分けます。意図的に異なるキーを使った多層制限でない限り、包括的なミドルウェアとルートごとのレート制限を同じリクエストに適用しないでください。
5. Upstash のタイムアウトとログ／メトリクスを明示的に設定します。エンドポイントに応じて障害時の動作を選択します。
   • リスクの低い可用性重視のパスでは、テレメトリの低下を許容してフェイルオープンにできます。
   • 認証、高コストの生成、または不正利用に敏感なパスでは、ローカルの緊急制限、キュー、クレジットの予約、または明確な一時的レスポンスを伴うフェイルクローズを使用できます。
6. 429 を返す際は、負でない Retry-After と一貫したレート制限ヘッダーを設定します。有用な場合は、成功レスポンスにもヘッダーを追加します。フェイルオープンによる機能低下時に、誤解を招くゼロの制限値を出力しないでください。
7. 重み付けされた処理では、サーバー側で計算したバッチ／操作コストに基づいてトークンを消費します。必要に応じて、レート制限をリクエスト本文サイズの制限、同時実行制御、冪等性、予算／クレジット、プロバイダーのクォータと組み合わせます。
8. SDK が保留中の Promise を公開している場合は、ランタイムの waitUntil の仕組みを使って、分析データの同期などの非同期処理を維持します。

検証

可能であれば、分離したキーのプレフィックスと制御可能なクロック／ウィンドウを使って決定論的なテストを実施します。許可／ブロック／リセットの動作、ルートの分離、認証済み／匿名のキー、偽装された転送ヘッダー、有料／無料のポリシー、同時実行、重み付けされたリクエスト、ストアのタイムアウト／障害、ミドルウェアの重複回避をテストします。リポジトリの lint／型チェック／テスト／ビルドを実行し、有効化されている場合に限り Upstash の分析データを確認します。

出力

ポリシー表、識別子の信頼モデル、変更したファイル／環境変数名、障害時の動作、レスポンスヘッダー、多層制御、自動テストの証拠、残っている Upstash／デプロイ設定を報告します。