1. Homepage
  2. Flex Gateway (1.7)
  3. 内部ポリシーディレクトリ

  4. レート制限

レート制限ポリシー

ポリシー名

レート制限

概要

一定期間に処理される要求の最大数を定義することで、API へのアクセスを監視します。

カテゴリ

サービス品質

使用可能な最小 Flex Gateway バージョン

v1.2.0

返される状況コード

429 - クォータを超過しました。現在のウィンドウが完了するまで要求はブロックされます。

概要

レート制限ポリシーにより、API が特定の期間中に受け取ることができる要求数を制限することで、API への受信トラフィックを制御できます。この制限に達すると、ポリシーはすべての要求を拒否して、バックエンド API の負荷増大を回避します。

レート制限ポリシーを設定するときには、クォータ (要求数) と時間ウィンドウ (期間) の値を自由に組み合わせて指定できます。

Flex Gateway API に適用されるレート制限ポリシーは、ゲートウェイではなくレプリカにスコープ設定されます。

ポリシーのパラメーターの設定

Flex Gateway のローカルモード

ローカルモードでは、宣言型の設定ファイルを使用してレート制限ポリシーを API に適用します。以下のポリシー定義とパラメーターの表を参照してください。

- policyRef:
    name: rate-limiting-flex
  config:
    rateLimits: <array> // REQUIRED
      - maximumRequests: <int> // REQUIRED
        timePeriodInMilliseconds: <int> // REQUIRED
    keySelector: <string> // OPTIONAL
    exposeHeaders: <bool> // OPTIONAL, default: false
    clusterizable: <bool> // OPTIONAL, default: true
パラメーター 必須または省略可能 デフォルト値 説明

rateLimits

必須

なし

1 つ以上のレート制限仕様を含むマップ

rateLimits.maximumRequests

必須

なし

ウィンドウで使用可能なクォータ値

rateLimits.timePeriodInMilliseconds

必須

なし

クォータが適用される時間 (数値)

keySelector

省略可能

なし

DataWeave 式で解決される各値の独立したカウンターでグループを作成するセレクターキー文字列。

たとえば、​#[attributes.queryParams['identifier']]​ は、​identifier​ クエリパラメーターを含む要求ごとに独立したカウンターグループを作成します。

exposeHeaders

省略可能

false

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義するブール値オプション

clusterizable

省略可能

true

Distributed (分散): このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます

リソースの設定例

次の例では、レート制限を 6 秒ごとに 3 件の要求として定義しています。

- policyRef:
    name: rate-limiting-flex
  config:
    rateLimits:
      - maximumRequests: 3
        timePeriodInMilliseconds: 6000
    keySelector: "#[attributes.method]"
    exposeHeaders: true
    clusterizable: false

#[attributes.method]​ DataWeave 式は、HTTP で使用できるメソッドごとに異なるグループを作成します。たとえば、ポリシーレート制限の GET 要求のグループを POST 要求とは別に作成します。

分散レート制限リソースの設定例

分散レート制限では、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、​「接続モードでの Flex Gateway の共有ストレージの設定」​を参照してください。

---
apiVersion: gateway.mulesoft.com/v1alpha1
kind: Configuration
metadata:
  name: shared-storage-redis
spec:
  sharedStorage:
    redis:
      address: redis:6379
      user: user
      password: pass
      DB: 1

---
- policyRef:
    name: rate-limiting-flex
  config:
    rateLimits:
      - maximumRequests: 3
        timePeriodInMilliseconds: 6000
    keySelector: "#[attributes.method]"
    exposeHeaders: true
    clusterizable: true

Flex Gateway の接続モード

UI からレート制限ポリシーを API に適用する場合は、次のパラメーターを設定できます。

パラメーター 説明 例

Identifier (識別子)

DataWeave または正規文字列を使用したセレクターキー

#[attributes.method]​ は、HTTP で使用できるメソッドごとに異なるグループを作成します。たとえば、ポリシーレート制限の GET 要求のグループを POST 要求とは別に作成します。

Number of Reqs (要求の数)

ウィンドウで使用可能なクォータ

正の数

Time Period (期間)

クォータが適用される時間

正の数

Time Unit (時間単位)

時間の単位 (ミリ秒、秒、分、時)

Minutes (分)

Distributed (分散)

このフラグを有効にして相互接続されたランタイムを使用する場合、クォータはすべてのノード間で共有されます。

オンまたはオフ

Expose Headers (ヘッダーを公開)

応答の一部として ​x-ratelimit ヘッダー​を公開するかどうかを定義するオプション

オンまたはオフ

ポリシーのしくみ

レート制限ポリシーは、現在のウィンドウ (使用可能なクォータ) 内で要求数を監視し、使用可能なクォータが 0 より大きい場合にのみ、要求がバックエンドに到達できるようにします。

ポリシー設定で識別子を使用することで、複数の要求グループに対してポリシーを設定できます。各グループは、それぞれのウィンドウで別々の使用可能なクォータを持ちます。

レート制限ポリシーの仕組みをわかりやすくするため、10 秒ごとに 3 件の要求という設定で、ウィンドウ内のクォータに基づいて受信要求が許可または拒否される例を見てみましょう。

レート制限ポリシーの例

最初のウィンドウでは、3 番目の要求でクォータに達したため、以降の要求はウィンドウが終了するまで拒否されます。2 番目のウィンドウでは、3 件の要求のうち 2 件しか処理されていないため、ウィンドウが終了しても、残りのクォータは少なくなります。

受け入れられた要求は API を経由してバックエンドに送られます。一方、拒否された要求は 429 の HTTP 状況コード (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。

一方、拒否された要求は 429 の HTTP 状況コード (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。

例

上記の 10 秒ごとに 3 件の要求という設定で、レート制限ポリシーがクラスター用に設定され、識別子を使用する場合を考えてみましょう。

正規文字列を使用した識別子の設定

UI を使用してポリシー設定に識別子を追加することで、要求のグループを定義できます。設定された制限は、各グループに別々に適用されます。レート制限ポリシー設定では、HTTP メソッドごとに 1 つのバケットに対して識別子 ​#[attributes.method]​ を使用できます。

UI の ​Identifier​ は非必須パラメーターです。デフォルトでは ​Identifier​ は値を持ちません。デフォルトを使用するか、または値を指定するかにより、ポリシーは次のように機能します。

  • 未設定 (デフォルト)

    レート制限は、バケットまたはグループごとにすべての要求に適用されます。

  • 必須 HTTP ヘッダーを使用するように設定

    各ヘッダーには個別のクォータが割り当てられます。ヘッダー値では大文字と小文字が区別されます。クォータは​遅延作成​を使用して作成されます。

  • 非必須 HTTP ヘッダーを使用するように設定

    カスタムヘッダー、ペイロード、クエリパラメーター、または式の値には、個別のクォータが割り当てられます。

    識別子が要求で送信されない場合、デフォルトで空の値に設定され、独自のクォータが使用されます。この動作では、未制御のクライアントによってコンシュームされる API にレート制限ポリシーを適用できると同時に、識別子を送信するクライアントの特別なバケットに対応します。

次の例は、10 秒おきに 3 つの要求の設定で識別子 ​#[attributes.method]​ を使用した場合に、一定期間に発生するイベントの順序を示しています。

レート制限の識別子設定例

この例では、

  • すべての HTTP メソッドでは 10 秒おきに 3 つの要求が許可されます (この例では、API に対して GET 要求と POST 要求のみが実行されています)。

  • レート制限ポリシーは、固定されたウィンドウで機能します。

    詳細は、図中のウィンドウサイズの括弧を参照してください。

  • ウィンドウの開始時間は独立しています。

  • エンジンはメソッドの最初の要求を受信するとレート制限アルゴリズムをスプールする​遅延作成​戦略を使用します。

DataWeave 式を使用した識別子の設定

レート制限エンジンは HTTP に依存せず、DataWeave 式の解決のみに左右されます。複雑なレート制限シナリオに対応するために UI の ​Identifier​ 式を変更することができます。

たとえば、すべてのクラス A およびクラス C の LAN 要求に 1 つのバケット、それ以外の要求に別のバケットを使用する識別子をレート制限ポリシーに設定できます。次の画像は前の文の 2 つ目のバケットを示し、DataWeave 式 ​#[attributes.queryParam[‘customIdentifier’]]​ をポリシー識別子として使用する 10 秒ごとに 3 件のクォータに相当します。

DataWeave によるレート制限の識別子設定例

この例では、

  • 識別子のない要求はすべて空の識別子に解決されます。したがって、1 つのレート制限アルゴリズムを使用します。

  • 識別子ごとに異なるバケットが使用され、各バケットには独立したクォータが割り当てられます。

この設定では、要求を実行した IP の地域に対応する false または true のバケットが作成されます。​false​ 値と ​true​ 値は、HTTP ではなくブール値のドメインに対応します。

いずれにせよ、エンジンは解決された式を文字列として扱うため、ポリシーは正常に機能します。この場合、値は自動的にブールから文字列にキャストされます。スクリプトに ​output text/plain ---​ を追加することで、DataWeave でキャストを明示的に定義できます。

HTTP RFC のヘッダー名では、大文字と小文字は区別されません。MuleSoft HTTP 用 Anypoint Connector は、ヘッダー名を小文字に変換します。ただし、DataWeave キーでは大文字と小文字が区別されます。したがって、​Identifier​ 式を作成するときには、小文字のヘッダーを参照するようにしてください。

無制限の識別子セットの設定

すべての識別子結果では 1 つのアルゴリズムが使用されます。DataWeave 式が無制限の (非常に大規模な) 共用ドメインを返さないように注意して作成してください。このようなドメインが返されると、同じ数のアルゴリズムをメモリ内でホストしなければならなくなります (アルゴリズムが​遅延作成​戦略で作成されるため、可能なすべての識別子に対して最低 1 つの要求を実行する必要があります)。

たとえば、DataWeave 式で、インターネットに公開された Flex Gateway インスタンスでの識別子として IP アドレスを使用するとします。インターネット上のすべての公開 IPv4 IP がこのインスタンスに対して要求を実行すると、1 つのインスタンスで 3,706,452,992 件のアルゴリズムが実行されます。

アルゴリズムの平均サイズが 250 バイトであれば、レート制限アルゴリズムのサイズは約 1 テラバイトになります。そのため、有限数の識別子に解決される DataWeave 式を使用することで、結果のセットをできるだけ小さくしてください。

FAQ

このウィンドウはいつ開始されますか?

このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。

アルゴリズムが使用するウィンドウの種別は?

固定ウィンドウです。

クォータを使い果たすとどうなりますか?

アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。各要求は、期間が終了するまで、現在のウィンドウの要求クォータをコンシュームします。

要求クォータを使い果たすと、レート制限ポリシーは要求を拒否します。ウィンドウが終了すると、要求クォータはリセットされ、同じ固定サイズの新しいウィンドウが開始されます。

複数の制限を定義するとどうなりますか?

ポリシーはウィンドウあたりの要求クォータ設定を使用して各制限のアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在のウィンドウで使用可能な要求クォータが存在する必要があります。

各レスポンスヘッダーの意味は?

各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。

  • X-Ratelimit-Remaining: 使用可能な要求クォータ

  • X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数

  • X-Ratelimit-Reset: 新しいウィンドウが開始されるまでの残り時間 (ミリ秒)

デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に ​[Expose Headers (ヘッダーを公開)]​ を選択します。

レート制限 SLA やスパイク制御ではなくレート制限ポリシーを使用する必要がある状況は?

レート制限ポリシーと​レート制限 SLA​ ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (​レート制限 SLA​ を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりに​スパイク制御​を使用してください。