レート制限ポリシー v1.2.0 の適用

レート制限 1.2.0 には、レート制限 1.0.0 および 1.1.0 の機能と、キー依存識別子別にクォータを適用する機能があります。このポリシーは Mule 4.1.0 以降で使用できます。

この識別子は文字列にマップする DataWeave 式で、セレクターキーを作成します。レート制限 1.0.0 および 1.1.0 では、ポリシーを API に適用するときに、設定された制限と ID を使用してポリシーごとにレート制限アルゴリズムが 1 つだけ作成されます。1.2.0 では、セレクターキーは ID の一部です。したがって、各セレクターキーに 1 つのアルゴリズムが作成され、それぞれに独自のクォータがあります。

ポリシーを適用するときに識別子を指定します。

[Apply Rate limiting policy (レート制限ポリシーを適用)] ページ。

この例では、レート制限をすべてのメソッドに適用します。クォータはメソッドごとに独立しています (3 要求/10 秒)。このようなポリシー設定は、次に示す仮説期間にわたってイベントが発生する可能性があります。

受け入れられた POST 要求と GET 要求の記号と、拒否された POST 要求と GET 要求の記号が、10 秒間隔のウィンドウサイズを示す大括弧付きのタイムライン上に表示された図。

この例は次を示しています。

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

  • レート制限ポリシーは、固定されたウィンドウで機能します (ウィンドウサイズの括弧を参照)。

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

非必須パラメーターの識別子を使用したレート制限の適用方法

識別子は非必須パラメーターです。識別子はデフォルトで空白になっており、次のようにレート制限ポリシーの以前のすべてのバージョンとの互換性を保持しています。

  • 未設定 (空白) の場合、1 つのバケットを使用してポリシーポイントカットによって照合されたすべての要求にクォータ制限が適用されます。

  • 必須の HTTP ヘッダーに設定されている場合、ヘッダーの大文字と小文字を区別した値ごとに独自のクォータが使用されます。クォータは遅延作成されます。

  • 非必須の HTTP ヘッダー、カスタムヘッダー、ペイロード、クエリパラメーターまたは式に設定されている場合、値ごとに独自のクォータが使用されます。

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

次の画像は後者を示し、DataWeave 式 ​#[attributes.queryParam[‘customIdentifier’]]​ をポリシー識別子として使用する 3 要求/10 秒のクォータに相当します。

[Apply Rate limiting policy (レート制限ポリシーを適用)] ページ。

この場合、次のアクションが発生します。

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

  • 識別子ごとに異なるバケットと独自の独立したクォータが使用されます。

DataWeave 式を使用したレート制限の適用方法

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

たとえば、すべてのクラス A および C の LAN 要求に 1 つのバケット、それ以外の要求に別のバケットを使用する識別子をレート制限ポリシーに設定できます。

識別子属性が強調表示された [Apply Rate limiting policy (レート制限ポリシーを適用)] ページ。

この設定では、要求を実行した IP の地域に対応する false または true のバケットが作成されます。

false と true は、HTTP ではなく、ブール値のドメインに対応しますが、エンジンでは解決された式が文字列として扱われるので、ポリシーは正しく機能します。

使用可能な識別子は、DataWeave を使用して要求から結果を抽出する必要がありますが、その他にはお客様の想像力以外の制約はありません。

注意:​ HTTP RFC は、ヘッダー名を大文字と小文字を区別するものとして宣言します。ヘッダー名は MuleSoft HTTP Connector によって小文字に変更されます。DataWeave はキーに依存します。したがって、識別子式を作成するときには、小文字のヘッダーを参照するようにしてください。

無制限の識別子セット

すべての識別子に 1 つのアルゴリズムが存在する必要があるので、(すべての識別子に少なくとも 1 つの要求がある場合は) 同じ量のアルゴリズムをメモリ内でホストしなければならないため、DataWeave 式を作成するときには、無制限の co ドメイン (大規模なドメイン) を返さないように注意します。たとえば、DataWeave 式で、インターネットに公開されたランタイムでの識別子として ip が使用されるとします。インターネット上のすべての公開 IPv4 IP がこのランタイムに対して要求を実行する場合、1 つのランタイムで 3,706,452,992 個のアルゴリズムが実行されます。アルゴリズムあたりの平均が 250 バイトであれば、レート制限アルゴリズムは約 1 テラバイトになります。

MuleSoft では、結果のセットをできるだけ小さくするために、有限個の識別子に解決される DataWeave 式を使用することをお勧めします。

Anypoint Service Mesh のレート制限

レート制限ポリシーは、次の制限を除き、Anypoint Service Mesh (Mule 以外のアプリケーション) と同様に機能します。

  • このポリシーでは、識別子によるサブバケット化がサポートされない (1 つのバケットのみ)。

  • このポリシーでは、ヘッダーを公開するオプションが提供されない。