Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動 。 情報
以降のセクションでは、Apigee の既知の問題について説明します。ほとんどの場合、ここに記載されている問題は今後のリリースで修正される予定です。
Miscellaneous Edge known issues
The following sections describe miscellaneous known issues with Edge.
Area
Known issues
Cache expire results in incorrect cachehit
value
When the cachehit
flow variable is used after the
LookupCache policy, due to the way debug points are dispatched for
asynchronous behavior, the LookupPolicy populates the DebugInfo object
before the call back has executed, resulting in an error.
Workaround: Repeat the process (make second call) again right
after the first call.
Setting InvalidateCache Policy
PurgeChildEntries
to true does not work correctly
Setting PurgeChildEntries
in the
InvalidateCache policy should purge the KeyFragment
element values only but
clears the entire cache.
Workaround: Use the
KeyValueMapOperations policy
to iterate cache versioning and bypass the need for cache invalidation.
Edge UI の既知の問題
以降のセクションでは、Edge UI の既知の問題について説明します。
地域
既知の問題
組織が ID ゾーンにマッピングされると、ナビゲーション バーから [Edge SSO Zone Administration] ページにアクセスできなくなります。
組織を ID ゾーンに接続する と、左側のナビゲーション バーから [管理者] > [SSO] を選択しても、[Edge SSO Zone Administration] ページにアクセスできなくなります。回避策として、https://apigee.com/sso から直接ページに移動します。
統合ポータルの既知の問題
以降のセクションでは、統合ポータルの既知の問題について説明します。
領域
既知の問題
SmartDocs
仕様エディタを使用して仕様を作成 し、ポータルで SmartDocs を使用して API を公開 する場合、Apigee Edge は OpenAPI 仕様 3.0 をサポートしますが、一部の機能はまだサポートされていません。たとえば、OpenAPI 仕様 3.0 の次の機能は現時点ではサポートされていません。
スキーマの組み合わせと拡張用の allOf
プロパティ
リモート参照
サポートされていない機能が OpenAPI 仕様で参照されると、ツールはその機能を無視し、API リファレンス ドキュメントをレンダリングする場合があります。それ以外の場合、サポートされていない機能によってエラーが発生し、API リファレンス ドキュメントの正常なレンダリングができないようにします。いずれの場合も、今後のリリースでサポートされるまで、OpenAPI 仕様を変更して、サポートされていない機能の使用を避ける必要があります。
注 : API リファレンス ドキュメントのレンダリング時は、仕様エディタで SmartDocs よりも制限が緩いため、ツールによって結果が異なる場合があります。
ポータルでこの API を試しに使用すると、OpenAPI 仕様の consumes
に設定されている値に関係なく、Accept
ヘッダーが application/json
に設定されます。
SAML ID プロバイダ
SAML ID プロバイダを使用したシングル ログアウト(SLO)は、カスタム ドメインではサポートされていません。SAML ID プロバイダを使用してカスタム ドメインを有効にするには、SAML 設定を構成する ときに [ログアウト URL ] フィールドを空白のままにします。
ポータル管理者
現時点では、複数のユーザーによる同時のポータルの更新(ページ、テーマ、CSS、スクリプトの編集など)はサポートされていません。
API リファレンス ドキュメントのページをポータルから削除した場合、再作成する方法はありません。API プロダクトを削除して再度追加し、API リファレンス ドキュメントを再生成する必要があります。
コンテンツ セキュリティ ポリシーの設定 時に、変更が完全に適用されるまでに最長で 15 分ほどかかる場合があります。
ポータルのテーマをカスタマイズ するときには、変更が完全に適用されるまで最大で 5 分かかることがあります。
ポータルの機能
Google 検索は今後のリリースで統合ポータルに統合される予定です。
Edge for Private Cloud の既知の問題
以降のセクションでは、Edge for Private Cloud の既知の問題について説明します。
地域
既知の問題
OPDK 4.52.01 Mint アップデート
この問題は、Edge for Private Cloud インストールで MINT を使用しているか、MINT を有効にしているユーザーのみに影響します。
影響を受けるコンポーネント: edge-message-processor
問題: 収益化を有効にしていて、4.52.01 を新規インストールとしてインストールする場合、または以前の Private Cloud バージョンからアップグレードする場合、Message Processor で問題が発生します。開いているスレッドの数が徐々に増加し、リソースが枯渇する可能性があります。Edge-message-processor system.log に次の例外があります。
Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
アップグレードに関する注: Apigee では、この問題を修正するためのパッチを計画しています。Edge for Private Cloud で MINT を使用している場合は、パッチが適用されてから 4.52.01 にアップデートすることをおすすめします。
Apigee HTTP/2 の脆弱性 先ごろ、Apigee Edge for Private Cloud を含む HTTP/2 プロトコル(CVE-2023-44487)の複数の実装で、サービス拒否攻撃(DoS)の脆弱性が発見されました。この脆弱性により、Apigee API 管理機能の DoS が発生する可能性があります。詳細については、Apigee のセキュリティに関する公開情報 GCP-2023-032 をご覧ください。
Edge for Private Cloud のルーターと管理サーバーのコンポーネントはインターネットに公開されているため、脆弱性が生じる可能性があります。 HTTP/2 は、他の Edge for Private Cloud の Edge 固有のコンポーネントの管理ポートで有効になっていますが、これらのコンポーネントはインターネットに公開されません。Cassandra や Zookeeper などの Edge 以外のコンポーネントでは、HTTP/2 は有効になっていません。次の手順で Edge for Private Cloud の脆弱性に対処することをおすすめします。
Edge Private Cloud バージョン 4.51.00.11 以降を使用している場合は、次の操作を行います。
管理サーバーを更新します。
各 Management Server ノードで、/opt/apigee/customer/application/management-server.properties
を開きます。
次の行をプロパティ ファイルに追加します。
conf_webserver_http2.enabled=false
Management Server コンポーネントを再起動します。
apigee-service edge-management-server restart
Message Processor を更新します。
各 Message Processor ノードで /opt/apigee/customer/application/message-processor.properties
を開きます。
次の行をプロパティ ファイルに追加します。
conf_webserver_http2.enabled=false
Message Processor コンポーネントを再起動します。
apigee-service edge-message-processor restart
ルーターを更新します。
各ルーターノードで /opt/apigee/customer/application/router.properties
を開きます。
次の行をプロパティ ファイルに追加します。
conf_webserver_http2.enabled=false
Message Processor コンポーネントを再起動します。
apigee-service edge-router restart
QPID を更新します。
各 QPID ノードで /opt/apigee/customer/application/qpid-server.properties
を開きます。
次の行をプロパティ ファイルに追加します。
conf_webserver_http2.enabled=false
Message Processor コンポーネントを再起動します。
apigee-service edge-qpid-server restart
Postgres を更新します。
各 Postgres ノードで /opt/apigee/customer/application/postgres-server.properties
を開きます。
次の行をプロパティ ファイルに追加します。
conf_webserver_http2.enabled=false
Message Processor コンポーネントを再起動します。
apigee-service edge-postgres-server restart
4.51.00.11 より前のバージョンの Edge for Private Cloud を使用している場合は、次の操作を行います。
管理サーバーを更新します。
各 Management Server ノードで、/opt/apigee/customer/application/management-server.properties
を開きます。
プロパティ ファイルに次の 2 行を追加します。
conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
Management Server コンポーネントを再起動します。
apigee-service edge-management-server restart
Message Processor を更新します。
各 Message Processor ノードで /opt/apigee/customer/application/message-processor.properties
を開きます。
プロパティ ファイルに次の 2 行を追加します。
conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
Message Processor コンポーネントを再起動します。
apigee-service edge-message-processor restart
ルーターを更新します。
各ルーターノードで /opt/apigee/customer/application/router.properties
を開きます。
プロパティ ファイルに次の 2 行を追加します。
conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
Message Processor コンポーネントを再起動します。
apigee-service edge-router restart
QPID を更新します。
各 QPID ノードで /opt/apigee/customer/application/qpid-server.properties
を開きます。
プロパティ ファイルに次の 2 行を追加します。
conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
Message Processor コンポーネントを再起動します。
apigee-service edge-qpid-server restart
Postgres を更新します。
各 Postgres ノードで /opt/apigee/customer/application/postgres-server.properties
を開きます。
プロパティ ファイルに次の 2 行を追加します。
conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
Message Processor コンポーネントを再起動します。
apigee-service edge-postgres-server restart
アップグレードに関する注: 古いバージョンの Private Cloud を 4.51.00.11 以降にアップグレードした後、上記の各ファイルから 2 行目の「conf/webserver.properties+http2.enabled=false」を削除して、それぞれのコンポーネントを再起動できます。
バージョン 4.52 への更新時の Postgresql のアップグレード Apigee-postgresql で、Edge for Private Cloud バージョン 4.50 または 4.51 からバージョン 4.52 へのアップグレードで問題が発生します。問題は主に、テーブル数が 500 を超えている場合に発生します。
Postgres のテーブルの合計数を確認するには、次の SQL クエリを実行します。
select count(*) from information_schema.tables
回避策:
Apigee Edge 4.50.00 または 4.51.00 を 4.52.00 に更新する 場合は、Apigee-postgresql をアップグレードする前に、必ず
準備手順 を実行してください。
注: この回避策に従わないと、Postgres のアップグレードが失敗する可能性があります。このような場合は、PG スタンバイを使用するか、PG または VM のバックアップを復元して動作中のバージョンにロールバックしてから、回避策の手順に沿ってアップグレードを再度実行してください。
RHEL 8.0 上の apigee-mirror
apigee-mirror
は Red Hat Enterprise Linux(RHEL)8.0 で機能しません。
回避策: 回避策として、以前のバージョンの RHEL または Apigee 用にサポートされている別のオペレーティング システム を実行しているサーバーに apigee-mirror
をインストールします。これにより、RHEL 8.0 サーバーに Apigee をインストールしている場合でも、ミラーを使用してパッケージを追加できます。
LDAP ポリシー
149245401: LDAP リソース を使用して構成された JNDI の LDAP 接続プール設定が反映されず、JNDI のデフォルトによって毎回 1 回限りの接続が発生する。その結果、1 回の使用のたびに接続の開閉が発生し、LDAP サーバーに対して 1 時間に多数の接続が作成されます。
回避策:
LDAP 接続プールのプロパティを変更するには、次の手順で、すべての LDAP ポリシーにグローバルな変更を設定します。
構成プロパティ ファイルが存在しない場合は作成します。
/opt/apigee/customer/application/message-processor.properties
次のものをファイルに追加します(LDAP リソースの構成要件に基づいて、Java Naming and Directory Interface(JNDI)プロパティの値を置き換えます)。
bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
-Dcom.sun.jndi.ldap.connect.pool.prefsize=2
-Dcom.sun.jndi.ldap.connect.pool.initsize=2
-Dcom.sun.jndi.ldap.connect.pool.timeout=120000
-Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"
ファイル /opt/apigee/customer/application/message-processor.properties
の所有者が apigee:apigee であることを確認してください。
各 Message Processor を再起動します。
接続プールの JNDI プロパティが有効になっていることを確認するには、tcpdump を実行して、LDAP 接続プールの動作の推移を観察します。
注: 上記の手順で指定した接続プールのプロパティはグローバルであるため、Edge の Message Processor が確立する接続プール対応の LDAP 接続すべてに適用されます。
リクエスト処理のレイテンシが高い
139051927: Message Processor で高いプロキシ処理レイテンシが、すべての API プロキシに影響しています。症状としては、通常の API レスポンス時間と比べて処理時間が 200 ~ 300 ミリ秒の遅延が生じることや、TPS が低い場合でもランダムに発生することがあります。これは、Message Processor が接続しているターゲット サーバーが 50 台を超える場合に発生することがあります。
根本原因: Message Processor は、ターゲット サーバーへの送信接続のために、ターゲット サーバーの URL を HTTPClient オブジェクトにマッピングするキャッシュを保持します。デフォルトでは、この設定は 50 に設定されていますが、ほとんどのデプロイでは少なすぎる可能性があります。デプロイメントの設定に org/env の組み合わせが複数あり、ターゲット サーバーの総数が 50 を超えている場合、ターゲット サーバーの URL がキャッシュから削除され続けると、レイテンシが発生します。
検証: ターゲット サーバーの URL エビクションがレイテンシの問題を引き起こしているかどうかを判断するには、Message Processor の system.logs でキーワード「onEvict」または「Eviction」を検索します。ログにこれらのエントリが存在する場合は、キャッシュ サイズが小さすぎるためにターゲット サーバーの URL が HTTPClient キャッシュから削除されていることを示しています。
回避策: Edge for Private Cloud バージョン 19.01 と 19.06 では、HTTPClient キャッシュ /opt/apigee/customer/application/message-processor.properties
を編集して構成できます。
conf/http.properties+HTTPClient.dynamic.cache.elements.size=500
Message Processor を再起動します。すべての Message Processor に同じ変更を行います。
値 500 は一例です。設定の最適な値は、Message Processor が接続するターゲット サーバーの数よりも大きくする必要があります。このプロパティを高く設定することによる副作用はありません。唯一の影響は、Message Processor プロキシ リクエストの処理時間の改善です。
注: Edge for Private Cloud バージョン 50.00 のデフォルト設定は 500 です。
Key-Value マップの複数のエントリ
157933959: 組織レベルまたは環境レベルをスコープとする同じ Key-Value マップ(KVM)に対して同時挿入と更新を行うと、データが不整合になり、更新が失われます。
注: この制限は、Edge for Private Cloud にのみ適用されます。Edge for Public Cloud と Edge for Hybrid には、この制限はありません。
Edge for Private Cloud での回避策として、apiproxy
スコープ で KVM を作成します。