19.03.01 - Apigee Edge for Public Cloud リリースノート

ロード バランシング - 障害が発生したサーバーを削除するための制御の強化

API プロキシの ロードバランサを構成するときに、ロード バランシング ローテーションからサーバーが削除されるまでに発生するレスポンス エラーの数を指定できます。レスポンス エラーとは、Apigee がターゲット サーバーからのレスポンスを 1 つも受信していないことを意味します。この状況が発生した場合、エラーカウンタが 1 つ増えます。Apigee がターゲットからレスポンスを受信すると、そのレスポンスが HTTP エラー（500 など）であってもターゲット サーバーからのレスポンスとしてカウントされ、エラーカウンタはリセットされます。できる限り早く異常なサーバーをロード バランシングのローテーションから除外するため、不正な HTTP レスポンス（500 など）もエラーとしてカウントさせたい場合は、<ResponseCode> 子要素を含む新しい <ServerUnhealthyResponse> 要素をロードバランサの構成に加えます。Edge は、これらのコードを含むレスポンスも失敗としてカウントするようになります。

<HTTPTargetConnection>
  <LoadBalancer>
    <Algorithm>RoundRobin</Algorithm>
    <Server name="target1" />
    <Server name="target2" />
    <ServerUnhealthyResponse>
        <ResponseCode>500</ResponseCode>
        <ResponseCode>502</ResponseCode>
        <ResponseCode>503</ResponseCode>
    </ServerUnhealthyResponse>
    <MaxFailures>5</MaxFailures>
  </LoadBalancer>
</HTTPTargetConnection>
  
  

AccessControl ポリシーの強化

AccessControl ポリシーは、API プロキシを呼び出すことができる IP アドレスを決定します。このポリシーの新しい要素により、API デベロッパーは評価する IP アドレスをより詳細に制御できます。

<IgnoreTrueClientIPHeader>: 省略可（デフォルトは false）。true に設定すると、ポリシーは True-Client-IP ヘッダーを無視し、構成した X-Forwarded-For 評価動作に従って X-Forwarded-For ヘッダーの IP アドレスを評価します。

<AccessControl async="false" continueOnError="false"
    enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

詳しくは、こちらのコミュニティ投稿をご覧ください。

RaiseFault ポリシーで 2 つの新しい要素を使用できるようになり、FaultRules の処理がよりクリーンで強力になりました。

• ShortFaultReason はブール値です。true に設定すると、ポリシー名が fault.reason 変数に格納されます。
• FaultResponse で使用可能な AssignVariable を使用すると、API プロキシフローの他のポリシーで使用される変数に障害レスポンスを割り当てることができます。

ホスト型ターゲットに制限が適用されるようになりました。制限の詳細については、制限をご覧ください。

メッセージ テンプレート変数を使用して、AccessControl ポリシーで IP アドレスと CIDR マスクを設定できるようになりました。たとえば、IP アドレスとマスクを Key-Value マップ（KVM）に保存する場合は、API プロキシ フローで設定した変数からこれらの値を取得できます。これにより、ポリシー構成を変更することなく、実行時に IP 値を簡単に変更できます。

たとえば、次の操作を行います。

<MatchRule action="DENY">
    <SourceAddress mask="24">198.51.100.1</SourceAddress>
</MatchRule>
     

値が KVM に保存され、KeyValueMapOperations ポリシーを使用して値を取得し、ここに示されている変数に割り当てる場合、ポリシーは次のように構成できます。

<MatchRule action="DENY">
    <SourceAddress mask="{kvm.mask.ref}">{kvm.ip.ref}</SourceAddress>
</MatchRule>
     

API Monitoring には、API Monitoring 管理者と API Monitoring ユーザーの 2 つのロールがあります。これについては、API Monitoring へのアクセスで説明しています。これらは 2018 年 12 月に利用可能になりました。

Edge は、各リクエストに X-Apigee.Message-Timeout ヘッダーを追加するようになりました。このヘッダーは Edge の内部使用を目的としています。これらのヘッダーはお客様用ではなく、いつでも Apigee によって削除または変更される可能性があるため、API プロキシの X-Apigee.* ヘッダーの値を信頼しないでください。

API 呼び出しが失敗しないようにキーストア削除エラーを処理

x-apigee.edge.execution.sense.action が常に null に設定される

ResponseCache ポリシーで、NIOTheread がスレッド プールからの拒否なしで実行されている

Apigee ルーター上の複数のログ エクスポーターが原因で CPU 使用率が高くなる

特定の組織で 404 が断続的に発生する

デプロイされた共有フローが一部のメッセージ プロセッサで実行されない

この修正は、次の Edge for Private Cloud リリースに含まれる予定です。

この修正は、次の Edge for Private Cloud リリースに含まれる予定です。

この修正は、次の Edge for Private Cloud リリースに含まれる予定です。