ConcurrentRateLimit ポリシー

概要

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

ポリシーの内部名。name 属性の値には、英字、数字、スペース、ハイフン、アンダースコア、ピリオドを使用できます。この値は 255 文字を超えることはできません。

管理 UI プロキシ エディタで <DisplayName> 要素を追加して、ポリシーのラベルに使用する別の自然言語名を指定することもできます。

 なし 必須
continueOnError

ポリシーが失敗したときにエラーを返す場合は、false に設定します。これは、ほとんどのポリシーで想定される動作です。

ポリシーが失敗した後もフローの実行を続行する場合は、true に設定します。

 false 任意
enabled

ポリシーを適用するには、true に設定します。

ポリシーを無効にするには、false に設定します。ポリシーがフローに接続されている場合でも適用されません。

 true 任意
async

この属性は非推奨となりました。

 false 非推奨

<DisplayName> 要素

管理 UI プロキシ エディタで name 属性と一緒に使用して、ポリシーのラベルに使用する自然言語名を指定します。

<DisplayName>Policy Display Name</DisplayName>
デフォルト

なし

この要素を省略した場合、ポリシーの name 属性の値が使用されます。
要否 任意
種類 文字列

<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

エラーコード

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle errors. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Fault code HTTP status Occurs when
policies.concurrentratelimit.ConcurrentRatelimtViolation 503

ConcurrentRatelimit connection exceeded. Connection limit : {0}

Note: The Fault code shown on the left is correct, although it contains a misspelling ("limt"). Be sure to use the code exactly as shown here when creating fault rules to trap this error.

Deployment errors

Error name Occurs when
InvalidCountValue ConcurrentRatelimit invalid count value specified.
ConcurrentRatelimitStepAttachment\
NotAllowedAtProxyEndpoint		 Concurrent Ratelimit policy {0} attachment is not allowed at proxy request/response/fault paths. This policy must be placed on the Target Endpoint.
ConcurrentRatelimitStepAttachment\
MissingAtTargetEndpoint		 Concurrent Ratelimit policy {0} attachment is missing at target request/response/fault paths. This policy must be placed in the Target Request Preflow, Target Response Postflow, and DefaultFaultRule.
InvalidTTLForMessageTimeOut ConcurrentRatelimit invalid ttl value specified for message timeout. It must be a positive integer.

Fault variables

These variables are set when this policy triggers an error. For more information, see What you need to know about policy errors.

Variables Where Example
fault.name="fault_name" fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. fault.name Matches "ConcurrentRatelimtViolation"

Note: The Error code shown in the example is correct, although it contains a misspelling ("limt"). Please be sure to use the code exactly as shown here when creating fault rules to trap this error.

concurrentratelimit.policy_name.failed policy_name is the user-specified name of the policy that threw the fault. concurrentratelimit.CRL-RateLimitPolicy.failed = true

Example error response

If the rate limit is exceeded, the policy returns only an HTTP status 503 to the client.

Example fault rule

<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>

関連トピック

割り当てポリシー

Spike Arrest ポリシー

Quota、Spike Arrest、Concurrent Rate Limit ポリシーの比較