レート制限および調整

ここでは、Mule 3.x 以前にデプロイされた API に関する調整とレート制限ポリシーのトピックに対応する、調整とレート制限の基盤となるテクノロジについて詳しく説明します。説明の多くは、Mule Runtime 4.x にデプロイされた API にも該当します。

用語

レート制限と調整では、次の用語が使用されます。

  • 制限: 一連のペア - 割り当てと期間

  • 割り当て: API マネージャで設定する ​# of Reqs

  • 期間: API Manager ペア - 期間と時間単位

  • 再試行: 要求をキューに登録する調整機能

  • コントラクト: アプリケーションと SLA の間の関係

制限

API Manager で制限を選択すると、制限および調整アルゴリズムの​ 期間 ​あたりの​ 割り当て ​設定が定義されます。アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。

各要求は、期間が終了するまで、現在の期間の割り当てをコンシュームします。 割り当てが枯渇した場合のアクションは、ポリシーによって異なります。

  • レート制限では、要求は拒否されます。

  • 調整では、要求は再試行のためにキューに登録されます。

期間が終了すると、割り当てはリセットされ、同じ固定サイズの新しい期間が開始されます。 ポリシーは各制限の​ 期間 ​あたりの​ 割り当て ​設定を使用してアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在の期間で使用可能な割り当てが存在する必要があります。

応答ヘッダー

次のアクセス制限ポリシーは、要求の現在の状態に関する情報を含むヘッダーを返します。

  • X-Ratelimit-Remaining: 使用可能な割り当て量。

  • X-Ratelimit-Limit: 期間あたりに使用可能な最大要求数。

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

調整再試行

調整は、急増を緩和することを目的としているため、Mule Runtime は要求を遅延させて、後で再試行できます。次の例は、要求の拒否と受け入れがどのように行われるかを示しています。

拒否される要求

ポリシー設定: 5 件の要求/10 秒の期間、500ms の遅延で 1 回の再試行

throttling rejected request

ユーザは最初の 6 秒間で 5 件の要求を送信し、そのすべてが受け入れられます。8 秒の時点で新しい要求を受信しますが、割り当てが残っていないため、この要求は 500ms 遅延されます。

8.5 秒の時点でキューに登録された要求が再処理されます。期間がまだ終了していないため、割り当ては使用できないままです。再試行回数も残っていないため、この要求は拒否されます。

受け入れられる要求

ポリシー設定: 5 件の要求/10 秒の期間、500ms の遅延で 1 回の再試行

throttling accepted request

ユーザは最初の 9 秒間で 5 件の要求を送信し、そのすべてが受け入れられます。 9.7 秒の時点で新しい要求を受信しますが、割り当てが残っていないため、この要求は 500ms 遅延されます。

10 秒の時点で期間が終了し、割り当ては 5 にリセットされます。 開始から 10.2 秒後 (現在の期間の 0.2 秒の時点) に、キューに登録された要求が再処理されます。今回は、使用可能な割り当てがあるため、要求は受け入れられます (使用可能な割り当ては 4 に減ります)。

設定

調整ポリシーは HTTP スタック上で機能するため、キューに登録された各要求が再処理されるには、ユーザと API の間で開かれた接続が保持される必要があります。このプロセスは大量のリソースを要するため、期間が長い場合は、HTTP または下層の TCP がタイムアウトのために接続をキャンセルすることがあります。

ゲートウェイ 2.x と Mule Runtime 3.x では強制されていませんが、使用期間は短くすることをお勧めします。1 秒の最大期間は短いとみなされます。このポリシーをスタンドアロン環境で使用することをお勧めします。

クラスタとスタンドアロン

弾力性を実現する 1 つの方法は冗長性を使用することです。つまり、同じ API に複数の Mule Runtime インスタンスを使用します。

この状況で考慮すべきことは、レート制限 (SLA ありまたはなし) を共有するかどうかということです。複数の Mule Runtime をクラスタで実行するように設定して、設定した制限を共有し、すべてのノードを全体として扱うことができます。レート制限ポリシーは、クラスタノード間でクォータを共有する、または共有しないように設定できます。デフォルトでは、クォータがクラスタノード間で共有されます。

次に、さまざまなシナリオに対応した分析を示します。

分散処理

n 個のノードがあり、次のようになっています。

  • 各ノードにはそれぞれのバックエンドがある。

  • 最速の応答が必要である。

  • 処理される要求数は、バックエンドの容量によってのみ制限される。

  • SLA レベルが​ ない ​か、各ノードに 1 つだけある。

    たとえば、2 つのノードが必要で、1 つは会社の有料ユーザに割り当て、もう 1 つはその他に割り当てる場合などです。

このシナリオの分散処理では、クラスタの必要はありません。単に最も弱いノードのバックエンド容量を下回るポリシーを設定します。SLA のないシナリオでは、ノードがダウンした場合にロードバランサが役立つことがあります。

中央処理

n 個のノードがあり、次のようになっています。

  • バックエンドが一元化されている。

  • 処理される要求数は、バックエンドの容量によってのみ制限される。

  • SLA レベルが​ ない ​か、すべてのノードの SLA は 1 つで、同じである。

    たとえば、すべてのノードが会社の有料ユーザに割り当てられている場合などです。

前方にロードバランサがあれば、クラスタの必要はありません。バックエンドの最大容量を ​ q ​ とすると、ポリシーを次のように設定します。

quota policy formula

ここで、omega は、バックエンドの最大容量を下回る小さな数値です。

ロードバランサがない場合、各ノードが処理するトラフィックを事前に設定できないため、スタンドアロンよりもクラスタノードをお勧めします。これらのポリシーは、ワークロードのバランスが完全に取れている場合でも、非常に不均衡な場合でも機能するように設計されています。バックエンドは余分な要求を受信しません。

複数のワーカー

n 個の CloudHub ワーカーがあり、次のようになっています。

  • 各ワーカーは同じ API を表している。

  • アプリケーションのワークロードはワーカー間に等しく分散されている。

アプローチは、​ 中央処理 ​のユースケースと同じです。

複数のコントラクトの使用

n 個のノードがあり、次のようになっています。

SLA が適用されている。

レート制限 SLA が適用されていて、各ノードが複数の SLA からの要求を受け入れる必要がある場合は、各ノードが各 SLA からの何件の要求を処理するかを事前に決定できないため、クラスタが適しています。

クラスタ内の期間の長さ

クラスタでは、クラスタ内での一貫性を保つためにノードは情報を共有する必要があります。共有プロセスにより遅延が発生するため、パフォーマンスについて確認するときには考慮する必要があります。

最悪の場合、クラスタの一貫性のために遅延の影響を受ける要求の数は一定で、設定された割り当ての実際のサイズとは関係がありません。そのため、期間が短いほど、遅延する可能性がある要求の割合は大きくなります。したがって、レート制限ポリシーとレート制限 SLA ポリシーの設定では、1 分より長い期間​ のみ ​を設定することを強くお勧めします。

遅延の最小化

クラスタアルゴリズムは、共有する情報の量を最小化することによって、パフォーマンスを最大化します。応答ヘッダー (X-Rate-Limit ヘッダー) は、クラスタ内で使用可能な割り当てのサイズを予測するヒューリスティックを使用して計算されるため、要求のたびに再同期する必要がありません。ヘッダー情報内のエラーは常に 10% 未満です。それでも、受け入れられる要求の量が定義された割り当てより大きくなることはありません。

設定

API ゲートウェイランタイム 2.x と Mule Runtime 3.x では、SLA ありまたはなしのレート制限ポリシーは、クラスタ内で自動的に分散実行されます。この機能を無効にすることはできません。

永続性

レート制限および調整アルゴリズムで日、月、年といった長い期間を使用するように設定できます。たとえば、クライアントとしてユーザ X が 1 年に 100 万件の要求をコンシュームすることを許可したいとします。ノードが期間中ずっと稼働しているか、それともメンテナンスが必要になるかを予測することはできません。メンテナンスを行うとランタイムを再起動する可能性があります。アルゴリズムはすでに数か月間実行されているため、クライアントは重要な情報を失います。永続性では、現在のポリシー状態を定期的に保存することによってこの問題を解決します。再デプロイメントや再起動が発生した場合、アルゴリズムは最後の既知の永続的な状態から再作成されるか、クリーンな状態から開始されます。

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

throttling.persistence_enabled

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

throttling.persistent_data_update_freq

重要:​ この機能は CloudHub では無効になっています。

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub