Rate Limiting - Plugin - v3.7.x

古いプラグインバージョンのドキュメントを閲覧しています。

Looking for the plugin's configuration parameters? You can find them in the Rate Limiting configuration reference doc.

指定期間 (秒、分、時間、日、月、または年単位) に実行可能な HTTP リクエスト数をレート制限します。基盤となるサービスまたはルートに認証レイヤーがない場合は、 クライアントの IP アドレスが使用されます。ただし、認証プラグインが設定されている場合は、コンシューマーが使用されます。

このプラグインの上級バージョンである、Rate Limiting Advanced では、スライディングウィンドウまたは固定ウィンドウで複数の制限を適用できます。

注: 制限は少なくとも 1 つ ( second 、 minute 、 hour 、 day 、 month 、 year ) 設定する必要がありますが、複数設定することもできます。

クライアントへの送信ヘッダー

このプラグインを有効にすると、許容制限、利用可能なリクエスト数、クオータがリセットされるまでの残り時間 (秒単位) を表示するための追加ヘッダーが Kong から送信されます。以下はヘッダーの例です。

RateLimit-Limit: 6
RateLimit-Remaining: 4
RateLimit-Reset: 47

このプラグインでは、利用可能な時間制限と残り時間を分で表示するために次のヘッダーも送信されます。

X-RateLimit-Limit-Minute: 10
X-RateLimit-Remaining-Minute: 9

複数の時間制限が設定されている場合、ヘッダーには次のすべての内容が含まれます。

X-RateLimit-Limit-Second: 5
X-RateLimit-Remaining-Second: 4
X-RateLimit-Limit-Minute: 10
X-RateLimit-Remaining-Minute: 9

プラグインは制限に達すると、次の JSON 本文と共にステータスコード「HTTP/1.1 429」を返します。

{ "message": "API rate limit exceeded" }

ヘッダー「RateLimit-Limit, RateLimit-Remaining」および「RateLimit-Reset」はインターネットドラフト HTTP 向け RateLimit ヘッダーフィールドに基づいていますが、将来、仕様更新を反映して変更する可能性があります。

実装に関する考慮点

IP アドレスによる制限

IP アドレスで制限する場合は、IP アドレスの決定方法を理解しておくことが重要です。IP アドレスは、ダウンストリームから Kong に送信されるリクエストヘッダーで決まります。ほとんどの場合、ヘッダー名は「X-Real-IP」または「X-Forwarded-For」です。

Kong では「X-Real-IP」というヘッダー名がデフォルトで使用されます。別のヘッダー名が必要な場合は、real_ip_header Nginx プロパティを使用して定義する必要があります。環境ネットワークの設定によっては、ロードバランサーの IP アドレスを含めるように trusted_ips Nginx プロパティを構成する必要がある場合もあります。

戦略

プラグインは次の 3 つの戦略をサポートしています。

戦略	長所	短所
`local`	パフォーマンスへの影響が最小限。	精度が低い。Kong の前にコンシステントハッシュ型のロードバランサーがある場合を除き、ノード数を拡大すると分岐する。
`cluster`	精度が高く、サポートする追加コンポーネントが不要。	リクエストごとに、自動的にデータストアが読み取り・書き込みされるため、パフォーマンスへの影響は相対的に最も大きい。
`redis`	精度が高く¹、「`cluster`」ポリシーよりもパフォーマンスへの影響は小さい。	Redis のインストールが必要。「`local`」ポリシーよりもパフォーマンスへの影響は大きい。

[1] : sync_rateオプションが-1に設定されているときのみ（同期動作）。Redisを使用する場合、同期レートを正の値に設定できますが、これにより不正確さが生じる可能性があります。詳細については、構成リファレンス参照してください。

一般的なユースケースには次の 2 つがあります。

すべてのトランザクションが重要なケース 。最高レベルの精度が必要とされます。財務的な結果を伴うトランザクションはその一例です。
バックエンド保護が必要なケース 。精度は比較的重要ではありません。特定のユーザーまたは攻撃のいずれかを原因とする過負荷からバックエンドサービスを保護することが唯一の要件です。

注 : エンタープライズのみ : このレート制限プラグインの Kong コミュニティエディションには、Redis Cluster または Redis Sentinel のサポートが含まれます。Kong Rate Limiting で Redis Cluster または Redis Sentinel を使用できるのは Kong Gateway Enterprise のお客様のみであり、パフォーマンスと可用性の高いプライマリレプリカを展開できます。

すべてのトランザクションが重要なケース

このシナリオでは、精度が重要であるため、「local」ポリシーは選択できません。まず Redis で必要となる可能性のあるサポート活動を検討してから、「cluster」または「redis」を選択します。

「cluster」ポリシーで始めてから、パフォーマンスが大幅に低下した場合は、「redis」に移行することもできます。

既存の使用状況指標をデータストアから Redis に移植することはできないのでご注意ください。この点は期限の短い指標 (秒や分など) では問題にならないかもしれませんが、もっと期間の長い指標 (月など) を使用する場合は、慎重に切り換えを計画する必要があります。

バックエンド保護が必要なケース

精度の重要性が比較的小さい場合は、「local」ポリシーを選択します。ユースケースに適した設定を見極めるには、多少試してみる必要があるかもしれません。クラスターが拡張してノード数が増えるほど、処理されるユーザーリクエスト数は増えます。クラスターの規模が小さくなると、検出漏れの確率が高まります。そのため、拡張時に制限を調整してください。

例えば、ユーザーが毎秒 100 件のリクエストを送信可能であり、負荷が均等の 5 ノードの Kong クラスターがある場合、制限を「local」に設定すると毎秒 30 前後のリクエストが処理されます。検出漏れが多すぎる場合は、制限を増やします。

エラーを最小限に抑えるには、Kong の前にコンシステントハッシュ型のロードバランサーを使用することを検討するとよいでしょう。このタイプでは、ユーザーは常に同じ Kong ノードに誘導されるため、エラーと拡張性の問題を減らすことができます。

IP のフォールバック

選択したポリシーを取得できない場合、プラグインは使用を制限するために IP アドレスを特定して、フォールバックします。この現象が発生する理由は複数あり、選択したヘッダーがクライアントから送信されなかったため、構成済みサービスが見つからなかったためなどといった例が考えられます。

次へ Rate Limiting設定