スパイク制御ポリシー

スパイク制御ポリシーは、API で処理されるメッセージ数を制限して、API 要求トラフィックを規制します。このポリシーにより、指定された時間内に処理されるメッセージ数が、設定した制限を超えなくなります。この数を超えると、要求はキューに入り、設定したポリシーに基づいて再試行されます。

スパイク制御ポリシーでは、クォータの適用は実行されません。設定パラメーターは、API およびバックエンドを保護するために制限されています。そのため、パフォーマンスを最大化するには、これらのパラメーターに設定する値をできる限り小さくします。

スパイク制御ポリシーは、​スライディングウィンドウアルゴリズム​を使用して、トラフィックの急増を緩和し、ゲートウェイインスタンスを保護します。ウィンドウの表示サイズは、結果の推移に合わせて自己調整されます。

現在のウィンドウに要求クォータが残っていない場合は、クライアントとの接続を閉じずに、後で処理するように要求をキューに入れることができます。ポリシーで要求をキューに入れるには、次の例に示すようにポリシーパラメーターを設定する必要があります。

要求をキューに入れると、スレッドと HTTP 接続を保持する必要があります。ポリシーで ​Queuing Limit​ パラメーターを指定すると、リソースが不足しないようにゲートウェイが保護され、攻撃を受けた場合でも API が失敗しなくなります。

次の図は、前のセクションで定義された設定を使用して、アルゴリズムによって受け入れられた各要求の有効期限を示しています。

この例は、要求の遅延と、キューに入れてトラフィックの急増を規制する方法を示しています。競合の多いシナリオでは、バックエンドが適切に機能し続けます (最後の Y ミリ秒に処理される要求数が X を超えない)。

API を照会するユーザーには、レイテンシーは長くなりますが、要求が処理中であることが表示される場合があります。ポリシーの正確な設定は API とそのスループットのみに依存します。

このスライディングウィンドウはいつ開始されますか?

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

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

アルゴリズムは、スライディングウィンドウを使用して、ポリシーで設定されている期間でトランザクションを監視します。

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

要求クォータを使い果たすと、スパイク制御ポリシーによって要求がキューに登録され、設定に従って再試行されます。複数回の再試行後もクォータが残っていない場合、要求は拒否されます。他の要求用のクォータは、最初の要求がポリシーで設定されている時間制限を超えてから使用可能になります。このようにして、要求が循環して処理されます。

複数のウィンドウを設定できますか?

いいえ。 スパイク制御ポリシーにより、バックエンドサーバーが処理容量を超えた数の要求を処理しないことが保証されます。説明責任を果たす必要がある場合は、レート制限 SLA ポリシーまたはレート制限ポリシーを使用してください。

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

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

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

スパイク制御を Mule クラスターで使用できますか?

いいえ。このポリシーはゲートウェイインスタンスを保護します。アーキテクチャで Mule クラスターを使用する場合は、スパイク制御ポリシーを使用して各インスタンスを別々に保護してください。

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

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