レート制限ポリシー

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

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

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

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

この例では、

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

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

この例では、

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

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

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

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

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

同じ 3 件の要求の設定例で、ウィンドウが 12:00:00 ちょうどに開始され、10 秒ごとにリセットされて、2 ノードのクラスターを使用するとします。両方のノードは同時にそれぞれのウィンドウを開始して終了し、クラスターではウィンドウごとに合計 3 件の要求が許可されます。

ポリシーがクラスター化されているため、クラスター全体で 3 件の要求を受け入れます。クラスター化ポリシーが無効化されると、Mule クラスターはウィンドウごとに 6 件の要求 (ノードごとに 3 件の要求) を受け入れることができます。

分散されたカウンターによってノードの同期が必要となり、その結果として発生するパフォーマンスの低下を回避するため、ポリシーではキャッシュメカニズムを使用して動作を予測し、スループットを最大化します。ただし、一部のシナリオではレイテンシーが増大するため、クラスター化設定を使用する場合は注意が必要です。

次のような設定により、環境で分散処理が行われている場合があります。

このようなシナリオでは、ポリシーをクラスター化設定で実行する必要はありません。単純に、最も弱いノードのバックエンド容量を下回るようにポリシー制限を設定すれば十分です。ノードが停止した場合には、ロードバランサーが役立つことがあります。

あるいは、次のような設定により、環境で中央処理が行われている場合があります。

このようなシナリオでは、クラスターは不要です。ただし、バックエンドの最大容量を超えないようにポリシーを設定する必要があります。

環境にロードバランサーが含まれていない場合は、スタンドアロンインスタンスではなくクラスターを使用することで、変動するトラフィックレベルにノードが対応できるようにしてください。レート制限ポリシーは、ワークロードが分散されていても分散されていなくても機能するように設計されています。バックエンドは過剰な要求を受け取らないため、最大容量を超えることはありません。

1 分より長い処理ウィンドウを使用するように環境を設定することで、クラスター内のノードが情報を共有することで発生する潜在的なレイテンシーを防止します。

この設定の推奨事項は、クラスターシナリオでのレート制限ポリシーとレート制限 SLA ポリシーの両方に適用されます。

レート制限ポリシーは、数日、数か月、あるいは数年に渡って永続するウィンドウを使用するように設定できます。たとえば、1 年間に 100 万件の要求をコンシュームできるようにしたいものの、その期間全体に渡ってノードが稼動しているかどうか、あるいは Mule Runtime Engine の再起動が発生するメンテナンスが必要になるかどうかについては確信が持てないとします。

アルゴリズムはすでに数か月間実行されているため、クライアントは重要な情報を失います。永続性では、現在のポリシー状態を定期的に保存することによってこの問題を解決します。再デプロイメントや再起動が発生した場合、アルゴリズムは最後の既知の永続的な状態から再作成されるか、クリーンな状態から開始されます。

永続性はデフォルトで有効になっていますが、次のプロパティを false に設定することで無効にできます。

throttling.persistence_enabled

また、永続性の頻度を調整できます。デフォルトは 10 秒です。

throttling.persistent_data_update_freq