概要
Apigee Edge で実行されている API プロキシからバックエンド サービスへの受信接続を調整します。
使用するレート制限ポリシーがわからない場合は、Quota、Spike Arrest、Concurrent Rate Limit ポリシーの比較をご覧ください。
動画
Concurrent Rate Limit ポリシーを使用してバックエンドとの同時接続を制限する方法については、この動画をご覧ください。
サンプル
<ConcurrentRatelimit name="ConnectionThrottler" > <AllowConnections count="200" ttl="5" /> <Distributed>true</Distributed> <StrictOnTtl>false</StrictOnTtl> <TargetIdentifier name="MyTargetEndpoint" ref="header/qparam/flow variables" /> </ConcurrentRatelimit>
要素リファレンス
この要素リファレンスでは、ConcurrentRatelimit ポリシーの要素と属性について説明します。
<ConcurrentRatelimit async="false" continueOnError="false" enabled="true" name="Concurrent-Rate-Limit-1"> <DisplayName>Concurrent Rate Limit 1</DisplayName> <AllowConnections count="200" ttl="5"/> <Distributed>true</Distributed> <StrictOnTtl>false</StrictOnTtl> <TargetIdentifier name="default"></TargetIdentifier> </ConcurrentRatelimit>
<ConcurrentRatelimit> 属性
<ConcurrentRatelimit async="false" continueOnError="false" enabled="true" name="Concurrent-Rate-Limit-1">
次の表に、すべてのポリシーの親要素に共通する属性を示します。
属性 | 説明 | デフォルト | 要否 |
---|---|---|---|
name |
ポリシーの内部名。 管理 UI プロキシ エディタで |
なし | 必須 |
continueOnError |
ポリシーが失敗した場合にエラーを返すには、 ポリシーが失敗した後もフローの実行を続行する場合は、 |
false | 省略可 |
enabled |
ポリシーを適用するには、 ポリシーを無効にするには、 |
true | 省略可 |
async |
この属性は非推奨となりました。 |
false | 非推奨 |
<DisplayName> 要素
管理 UI プロキシ エディタで name
属性と一緒に使用して、ポリシーのラベルに使用する自然言語名を指定します。
<DisplayName>Policy Display Name</DisplayName>
デフォルト |
なし この要素を省略した場合、ポリシーの |
---|---|
要否 | 省略可 |
タイプ | 文字列 |
<AllowConnections> 要素
Apigee Edge とバックエンド サービス間で同時に許可する接続数を指定します。
<AllowConnections count="200" ttl="5"/>
デフォルト: | なし |
要否: | 必須 |
型: | なし |
属性
属性 | 説明 | デフォルト | 必須? |
---|---|---|---|
数 | Apigee Edge とバックエンド サービス間で同時に許可する接続数を指定します。 | なし | 必須 |
ttl |
指定した秒数が経過したときにカウンタを自動的に減らす場合に指定します。レスポンスパスで正しく減らされていない接続をクリーンアップする場合に役立ちます。 |
なし | 必須 |
<Distributed> 要素
Apigee Edge のサーバー インフラストラクチャのインスタンス間でカウンタ値を共有するかどうかを指定します。
<Distributed>true</Distributed>
デフォルト: | false |
要否: | 省略可 |
型: | Boolean |
<StrictOnTtl> 要素
true に設定すると、バックエンド サーバーのスループットに関係なく <AllowConnections> ttl
属性の設定が適用されます。高スループットまたは低レイテンシのバックエンド サービスの場合、このプロパティを true
に設定することを検討してください。
<StrictOnTtl>false</StrictOnTtl>
デフォルト: | false |
要否: | 省略可 |
型: | Boolean |
<TargetIdentifier> 要素
調整を適用する TargetEndpoint の名前を指定します。
<TargetIdentifier name="default"></TargetIdentifier>
デフォルト: | なし |
要否: | 省略可 |
型: | なし |
属性
属性 | 説明 | デフォルト | 要否 |
---|---|---|---|
名前 | 調整を適用する TargetEndpoint の名前を指定します。 | なし | 省略可 |
ref | なし | 省略可 |
フロー変数
ポリシーを実行するたびに、次の事前定義のフロー変数が読み込まれます。
concurrentratelimit.{policy_name}.allowed.count
concurrentratelimit.{policy_name}.used.count
concurrentratelimit.{policy_name}.available.count
concurrentratelimit.{policy_name}.identifier
エラーコード
このセクションでは、このポリシーによってエラーがトリガーされたときに返される障害コードとエラー メッセージ、Edge によって設定される障害変数について説明します。 これは、エラーに対処する障害ルールを作成するうえで重要な情報です。詳細については、ポリシーエラーについて知っておくべきことと障害の処理をご覧ください。
ランタイム エラー
このエラーは、ポリシーの実行時に発生することがあります。
障害コード | HTTP ステータス | エラーが発生する条件 |
---|---|---|
policies.concurrentratelimit.ConcurrentRatelimtViolation |
503 |
ConcurrentRatelimit 接続を超過した。接続制限: {0} 注: 左側に示す障害コードは正しいですが、 にスペルミス(「limt」)が含まれている。ここに表示されているコードをそのまま使用してください エラーをトラップするための障害ルールを作成します。 |
デプロイエラー
エラー名 | エラーが発生する条件 |
---|---|
InvalidCountValue |
ConcurrentRatelimit に無効なカウント値が指定されている。 |
ConcurrentRatelimitStepAttachment\ |
プロキシで同時レート制限ポリシー {0} の接続が許可されない 障害の 3 つのパスがあります。このポリシーは、Target Endpont に配置する必要があります。 |
ConcurrentRatelimitStepAttachment\ |
同時レート制限ポリシー {0} アタッチメントがターゲット リクエスト/レスポンス/障害にない あります。このポリシーは、Target Request Preflow、Target Response Postflow、DefaultFaultRule に配置する必要があります。 |
InvalidTTLForMessageTimeOut |
メッセージのタイムアウトに指定された ConcurrentRatelimit の無効な ttl 値。正の整数を指定する必要があります。 |
障害変数
このポリシーがエラーをトリガーした場合は、次の変数が設定されます。詳細については、ポリシーエラーについて知っておくべきことをご覧ください。
変数 | 説明 | 例 |
---|---|---|
fault.name="fault_name" |
fault_name は、上記のランタイム エラーの表に記載されている障害の名前です。障害コードの最後の部分が障害名になります。 | fault.name Matches "ConcurrentRatelimtViolation"
注: スペルミス(「limt」)が含まれていますが、この例に表示されているエラーコードは正確です。このエラーをトラップする障害ルールを作成する際には、ここに表示されているコードを正確に使用してください。 |
concurrentratelimit.policy_name.failed |
policy_name は、障害をスローしたポリシーのユーザー指定の名前です。 | concurrentratelimit.CRL-RateLimitPolicy.failed = true |
エラー レスポンスの例
レート制限を超えると、ポリシーはクライアントに HTTP ステータス 503 のみを返します。
障害ルールの例
<faultrule name="VariableOfNonMsgType"></faultrule><FaultRules> <FaultRule name="Quota Errors"> <Step> <Name>JavaScript-1</Name> <Condition>(fault.name Matches "ConcurrentRatelimtViolation") </Condition> </Step> <Condition>concurrentratelimit.CRL-RateLimitPolicy.failed=true</Condition> </FaultRule> </FaultRules>
スキーマ
使用上の注意
分散環境では、複製された複数の API プロキシでアプリのトラフィックが管理されている場合があります。それぞれの API プロキシで処理されている接続数が少なくても、一連の API プロキシが複数のデータセンターにまたがる冗長な Message Processor で実行され、すべてが同じバックエンド サービスを参照しているため、全体としてはバックエンド サービスの能力を上回る可能性があります。このポリシーを使用して、このトラフィックの総量を対処できる接続数に制限してください。
Apigee Edge で処理されるリクエスト数がポリシーの接続制限を超えると、Apigee Edge が HTTP レスポンス コード 503(Service Unavailable)を返します。
1 秒あたりのトランザクション数(TPS)が多い API プロキシの場合、このポリシーを使用すると、プロキシのパフォーマンス低下を招くことが確認されています。TPS の高い API プロキシで Concurrent Rate Limit ポリシーを使用してパフォーマンスが著しく低下した場合は、代わりに Spike Arrest ポリシーを試してください。
ポリシーの関連付けに関する詳細
ConcurrentRatelimit ポリシーは、TargetEndpoint の 3 つのフロー(リクエスト、レスポンス、DefaultFaultRule)にステップとして関連付ける必要があります。ポリシーを ProxyEndpoint フローなどの他のフローに関連付けると、デプロイ時に検証エラーが発生します。この Apigee コミュニティの投稿もご覧ください。
たとえば、ConnectionThrottler という ConcurrentRatelimit ポリシーを MyTargetEndpoint という TargetEndpoint に接続するには、次のような TargetEndpoint 構成を作成します。エラー発生時もレート制限カウンタが正しく維持されるように、DefaultFaultRule にもポリシーを追加する必要があります。
<TargetEndpoint name="MyTargetEndpoint"> <DefaultFaultRule name="DefaultFaultRule"> <Step><Name>ConnectionThrottler</Name></Step> <AlwaysEnforce>true</AlwaysEnforce> </DefaultFaultRule> <PreFlow name="PreFlow"> <Request> <Step><Name>ConnectionThrottler</Name></Step> </Request> </PreFlow> <PostFlow name="PostFlow"> <Response> <Step><Name>ConnectionThrottler</Name></Step> </Response> </PostFlow> <HTTPTargetConnection> <URL>http://api.mybackend.service.com</URL> </HTTPTargetConnection> </TargetEndpoint>
関連トピック
Quota、Spike Arrest、Concurrent Rate Limit ポリシーの比較