Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動 。 情報
以降のセクションでは、Apigee の既知の問題について説明します。ほとんどの場合、ここに記載されている問題は今後のリリースで修正される予定です。
その他の Edge の既知の問題
以下のセクションでは、Edge に関するその他の既知の問題について説明します。
領域
既知の問題
キャッシュが期限切れになると cachehit
値が正しくない
cachehit
フロー変数を LookupCache ポリシーの後に使用する場合、非同期動作でのデバッグ ポイントのディスパッチ方法により、LookupPolicy によってコールバックの実行前に DebugInfo オブジェクトにデータが入力されるため、エラーが発生します。
回避策: 最初の呼び出しの直後に、プロセスをもう一度繰り返します(2 回目の呼び出しを行います)。
InvalidateCache ポリシー PurgeChildEntries
を true に設定しても正しく機能しない
InvalidateCache ポリシーで PurgeChildEntries
を設定すると、KeyFragment
要素の値のみがパージされますが、キャッシュ全体がクリアされます。
回避策: KeyValueMapOperations ポリシー を使用してキャッシュ バージョニングを繰り返し、キャッシュ無効化の必要性を回避します。
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 の既知の問題について説明します。
4.53.00 SSO と新しい UI のインストール
この問題は、Edge for Private Cloud 4.53.00 で FIPS 対応の RHEL 8 に SSO または新しい UI をインストールしようとするユーザーに影響します。
影響を受けるコンポーネント: SSO、新しい UI
問題: FIPS 対応の RHEL 8 オペレーティング システムに SSO または新しい UI をインストールすると、インストールに失敗します。
回避策: 機能がすべて揃っており、UI の機能要件を満たしている従来の UI を使用することをおすすめします。
Edge for Private Cloud 4.52.01 Mint アップデート
この問題は、MINT を使用している場合、または Edge for Private Cloud のインストールで MINT が有効になっている場合にのみ発生します。
影響を受けるコンポーネント: edge-message-processor
問題: 収益化が有効になっている状態で、4.52.01 を新規インストールまたは以前の Private Cloud バージョンからアップグレードすると、メッセージ プロセッサに関する問題が発生します。開いているスレッド数が徐々に増加し、リソースが枯渇します。edge-message-processor system.log に次の例外が表示されます。
Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
アップグレードに関する注意: この既知の問題は、パッチ リリース 4.52.01.01 で修正されています。Edge for Private Cloud で MINT を使用しているお客様は、この問題を回避するためにバージョン 4.52.01.01 にアップグレードすることをおすすめします。
Apigee HTTP/2 の脆弱性 先ごろ、サービス拒否攻撃(DoS)の脆弱性が HTTP/2 プロトコル(CVE-2023-44487)の複数の実装で発見されました(Apigee Edge for Private Cloud を含む)。この脆弱性により、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 ノードで /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 ノードで /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 のメッセージ プロセッサが確立する、接続プール対応のすべての LDAP 接続に適用されます。
リクエスト処理のレイテンシが高い
139051927: Message Processor で発生したプロキシ処理のレイテンシが高いため、すべての API プロキシに影響しています。症状としては、通常の API レスポンス時間よりも処理時間が 200 ~ 300 ミリ秒遅延し、TPS が低い場合でもランダムに発生することがあります。これは、Message Processor が接続するターゲット サーバーが 50 台を超えている場合に発生することがあります。
根本原因: メッセージ プロセッサは、ターゲット サーバーへのアウトバウンド接続用に、ターゲット サーバー 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 が例です。設定の最適な値は、メッセージ プロセッサが接続するターゲット サーバーの数よりも大きくする必要があります。このプロパティを大きく設定しても副作用はありません。唯一の影響は、メッセージ プロセッサ プロキシ リクエストの処理時間が短縮されることです。
注: 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 を作成します。