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

ロード バランシング - 障害が発生したサーバーの削除をより細かく制御

を設定する場合 ロードバランサを使用する場合、この API プロキシの 障害は、サーバーがロード バランシングのローテーションから削除される前に発生します。レスポンス エラー Apigee はターゲット サーバーからレスポンスを受信しません。その場合、失敗は 1 ずつインクリメントしますApigee がターゲットからレスポンスを受信すると、 response は、ターゲット サーバーからのレスポンスとしてカウントされます。 失敗カウンタがリセットされます不正な HTTP レスポンス（500 など）も 障害カウンタをインクリメントして、異常なサーバーをロード バランシングのローテーションから除外します。 できるだけ早急に、新しい <ServerUnhealthyResponse> 要素を追加して これをロードバランサの構成に <ResponseCode> 子要素に置き換えます。 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 ヘッダー内の IP アドレスを評価し、 <ph type="x-smartling-placeholder"></ph> X-Forwarded-For 評価動作。

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

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

RaiseFault ポリシーでは、FaultRules を作成する 2 つの新しい要素が追加されました。 よりクリーンでパワフルです

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

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

メッセージ テンプレート変数を使用して、IP アドレスと CIDR マスクを AccessControl ポリシー。たとえば、1 つのバケットに格納する Key-Value マップ（KVM）内の IP アドレスとマスク。これらの値は、設定した変数から取得できます。 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 による内部使用を目的としています。API プロキシの X-Apigee.* ヘッダーの値に依存しない これらのヘッダーはお客様による使用を意図しておらず、Apigee によっていつでも削除または変更される可能性があります。

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

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

ResponseCache ポリシーでは、NIOTheread はインスタンスから拒否されることなく実行されています。 スレッドプール

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

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

デプロイされた共有フローが一部の Message Processor で実行されない

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

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

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