レート制限: SLA ベースのポリシー
ポリシー名 |
レート制限 SLA |
概要 |
SLA に基づいた期間中に処理される要求の最大数を定義することで、API へのアクセスを監視します。 |
カテゴリ |
サービス品質 |
使用可能な最小 Flex Gateway バージョン |
v1.2.0 |
返される状況コード |
401 - 指定されたクライアントログイン情報 (クライアント ID またはクライアントシークレット) が無効であるため、要求がブロックされました。 |
429 - クォータを超過しました。現在のウィンドウが完了するまで要求はブロックされます。 |
概要
レート制限サービスレベル契約 (SLA) ポリシーにより、API が特定の期間中に受け取ることができる要求数を制限することで、API への受信トラフィックを制御できます。期間が終了する前にこの制限に達すると、ポリシーはすべての要求を拒否して、バックエンド API の負荷増大を回避します。
レート制限 SLA ポリシーを API に適用するには、先にその API と登録済みクライアントアプリケーションとの間でコントラクトを作成する必要があります。特定の期間中に API が受け取ることのできる要求の数は、API Manager の [contracts (コントラクト)] セクションで定義します。
各要求は、クライアント ID と (ポリシー設定によって) 省略可能なクライアントシークレットによって識別される必要があります。登録済みクライアントアプリケーションのクライアントログイン情報の取得方法は、「登録済みクライアントアプリケーションのクライアントログイン情報の取得」を参照してください。
|
Flex Gateway API に適用されるレート制限 SLA ポリシーは、ゲートウェイではなくレプリカにスコープ設定されます。 |
ポリシーのパラメーターの設定
管理 Flex Gateway および Flex Gateway の接続モード
UI からポリシーを API インスタンスに適用するときに、以下のパラメーターが表示されます。
| パラメーター | 説明 | 例 |
|---|---|---|
Client ID Expression (クライアント ID 式) |
API のコントラクトについてクライアントアプリケーションの ID を解決する DataWeave 式 |
レート制限アルゴリズムは、ID ごとに 1 つだけ作成されます。
|
Client Secret Expression (クライアントシークレット式) |
API のコントラクトについてクライアントアプリケーションのクライアントシークレットを解決する DataWeave 式 |
省略可能な値です。
例: |
Distributed (分散) |
有効にすると、クォータが Flex レプリカ間で共有されます |
オンまたはオフ |
Expose Headers (ヘッダーを公開) |
応答の一部として x-ratelimit ヘッダーを公開するかどうかを定義する |
オンまたはオフ |
Block on unknown quota (不明なクォータでブロック) |
分散レート制限を使用するポリシーでは、ポリシーが共有ストレージからのクォータを取得できない場合に要求をブロックします。有効でない場合、クォータを取得できなければ、レート制限は適用されません。 |
オンまたはオフ |
共有ストレージの有効化
分散レート制限では、共有ストレージを有効にする必要があります。共有ストレージについての詳細は、接続モードでの Flex Gateway の共有ストレージの設定を参照してください。
ポリシーのしくみ
レート制限 SLA ポリシーは、現在のウィンドウ (使用可能なクォータ) 内で要求数を監視し、使用可能なクォータが 0 より大きい場合にのみ、要求がバックエンドに到達できるようにします。
ウィンドウで使用可能なクォータはクライアントごとに別々に定義されるため、クライアントアプリケーションは API との間で SLA (コントラクト) を定義する必要があります。したがって、要求が SLA の制限内にあるかどうかを検証するには、要求からクライアント ID と必要に応じてクライアントシークレットを取得する手段を定義する必要があります。
クライアントアプリケーションと API との間でコントラクトを作成すると、API ゲートウェイは API Manager 設定を監視することで、自動的にこれらのコントラクトを管理します。さらに API ゲートウェイは、Anypoint Platform 管理プレーンで予期しないダウンタイムが発生した場合に備えて、高可用性戦略を実装します。
レート制限 SLA ポリシーの仕組みをわかりやすくするため、ID が「ID#1」のクライアントについて 10 秒ごとに 3 件の要求という設定で、ウィンドウ内のクォータに基づいて受信要求が許可または拒否される例を見てみましょう。
この例では、次のようになります。
-
ID が「ID#1」のクライアントの要求:
最初のウィンドウでは、3 番目の要求でクォータに達したため、以降の要求はウィンドウが終了するまで拒否されます。2 番目のウィンドウでは、3 件の要求のうち 2 件しか処理されていません。このウィンドウは終了したため、残りのクォータは未使用となります。
受け入れられた要求は API を経由してバックエンドに送られます。一方、拒否された要求は 429 status for HTTP (API が WSDL であれば 400 または 500) を返してバックエンドには到達しません。
-
ID が「ID#2」のクライアントの要求:
このクライアントは API との間で定義されているコントラクトを持たないため、すべての要求が拒否され、要求は 1 つも許可されません。
1 つの API は、それぞれ SLA が異なる複数のコントラクトを持つことができます。レート制限 SLA ポリシーは、コントラクトごとに 1 つのレート制限アルゴリズムを作成することで、各クライアントの使用可能なクォータ (およびウィンドウ) を別々に監視します。API に最初の要求が送られた時点で、遅延作成戦略によってアルゴリズムが作成されます。
FAQ
このウィンドウはいつ開始されますか?
このウィンドウは、ポリシーが正常に適用された後の最初の要求で開始されます。
アルゴリズムが使用するウィンドウの種別は?
固定ウィンドウです。
クォータを使い果たすとどうなりますか?
アルゴリズムは、最初の要求を受信したときにオンデマンドで作成されます。このイベントによって、期間が固定されます。各要求は、期間が終了するまで、現在のウィンドウの要求クォータをコンシュームします。
要求クォータを使い果たすと、レート制限 SLA ポリシーは要求を拒否します。ウィンドウが終了すると、要求クォータはリセットされ、同じ固定サイズの新しいウィンドウが開始されます。
SLA で複数の制限を定義するとどうなりますか?
ポリシーはウィンドウあたりの要求クォータ設定を使用して各制限のアルゴリズムを作成します。そのため、複数の制限が設定されている場合、要求が受け入れられるには、すべてのアルゴリズムに現在のウィンドウで使用可能な要求クォータが存在する必要があります。
各レスポンスヘッダーの意味は?
各レスポンスヘッダーは、要求の現在の状態に関する情報を返します。
-
X-Ratelimit-Remaining: 使用可能な要求クォータ
-
X-Ratelimit-Limit: 各ウィンドウで使用可能な最大要求数
-
X-Ratelimit-Reset: 新しいウィンドウが開始されるまでの残り時間 (ミリ秒)
デフォルトでは、応答の X-RateLimit ヘッダーは無効になっています。これらのヘッダーを有効にするには、ポリシーの設定時に [Expose Headers (ヘッダーを公開)] を選択します。
|
分散モードでは、X-Ratelimit-Remaining ヘッダーがすべてのレプリカと完全には同期されません。 分散モードで複数のレプリカがある場合、X-Ratelimit-Remaining ヘッダーはレプリカ自体で使用できるクォータの量の推定となります。API に使用できる残りのクォータの実際の値が表示されるわけではありません。 有効なシナリオを次に示します。
これは、クォータを超えるという意味ではありません。 |
レート制限 SLA やスパイク制御ではなくレート制限ポリシーを使用する必要がある状況は?
レート制限 SLA ポリシーとレート制限 SLA ポリシーは、説明責任を果たすためにハード制限を (レート制限で識別子を使用して) グループまたは (レート制限 SLA を使用して) クライアントアプリケーションに適用する場合に使用します。バックエンドを保護するには、代わりにスパイク制御を使用してください。