Apigee に関する既知の問題

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 へのインプレース アップグレード

Edge for Private Cloud 4.53.00 では、新しいクラスタを設定するには、新規インストールの手順を行う必要があります。インプレース アップグレードはサポートされていません。現在、古いバージョンの Edge for Private Cloud を実行している場合、Edge for Private Cloud 4.53.00 に直接アップグレードすることはできません。

インプレース アップグレードはサポートされていませんが、新しい 4.53.00 Edge for Private Cloud クラスタを設定し、Management API を使用して古いクラスタからデータをエクスポートして、新しい 4.53.00 クラスタにインポートできます。
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
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 以降を使用している場合は、次の手順に沿って操作します。

  1. 管理サーバーを更新します。

    1. 各 Management Server ノードで /opt/apigee/customer/application/management-server.properties を開きます。
    2. プロパティ ファイルに次の行を追加します。 
      conf_webserver_http2.enabled=false
    3. Management Server コンポーネントを再起動します。 
      apigee-service edge-management-server restart

  2. Message Processor を更新します。

    1. 各 Message Processor ノードで /opt/apigee/customer/application/message-processor.properties を開きます。
    2. プロパティ ファイルに次の行を追加します。 
      conf_webserver_http2.enabled=false
    3. メッセージ プロセッサ コンポーネントを再起動します。 
      apigee-service edge-message-processor restart

  3. ルーターを更新する:

    1. 各ルータノードで /opt/apigee/customer/application/router.properties を開きます。
    2. プロパティ ファイルに次の行を追加します。 
      conf_webserver_http2.enabled=false
    3. メッセージ プロセッサ コンポーネントを再起動します。 
      apigee-service edge-router restart

  4. QPID を更新する:

    1. 各 QPID ノードで /opt/apigee/customer/application/qpid-server.properties を開きます。
    2. プロパティ ファイルに次の行を追加します。 
      conf_webserver_http2.enabled=false
    3. メッセージ プロセッサ コンポーネントを再起動します。 
      apigee-service edge-qpid-server restart

  5. Postgres を更新します。

    1. 各 Postgres ノードで /opt/apigee/customer/application/postgres-server.properties を開きます。
    2. プロパティ ファイルに次の行を追加します。 
      conf_webserver_http2.enabled=false
    3. メッセージ プロセッサ コンポーネントを再起動します。 
      apigee-service edge-postgres-server restart

4.51.00.11 より前のバージョンの Edge for Private Cloud を使用している場合は、次の手順を行います。

  1. 管理サーバーを更新します。

    1. 各管理サーバー ノードで /opt/apigee/customer/application/management-server.properties を開きます。
    2. プロパティ ファイルに次の 2 行を追加します。 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Management Server コンポーネントを再起動します。 
      apigee-service edge-management-server restart

  2. メッセージ プロセッサを更新します。

    1. 各 Message Processor ノードで /opt/apigee/customer/application/message-processor.properties を開きます。
    2. プロパティ ファイルに次の 2 行を追加します。 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. メッセージ プロセッサ コンポーネントを再起動します。 
      apigee-service edge-message-processor restart

  3. ルーターを更新する:

    1. 各ルータノードで /opt/apigee/customer/application/router.properties を開きます。
    2. プロパティ ファイルに次の 2 行を追加します。 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. メッセージ プロセッサ コンポーネントを再起動します。 
      apigee-service edge-router restart

  4. QPID を更新する:

    1. 各 QPID ノードで /opt/apigee/customer/application/qpid-server.properties を開きます。
    2. プロパティ ファイルに次の 2 行を追加します。 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. Message Processor コンポーネントを再起動します。 
      apigee-service edge-qpid-server restart

  5. Postgres を更新します。

    1. 各 Postgres ノードで /opt/apigee/customer/application/postgres-server.properties を開きます。
    2. プロパティ ファイルに次の 2 行を追加します。 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. メッセージ プロセッサ コンポーネントを再起動します。 
      apigee-service edge-postgres-server restart
バージョン 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 をアップグレードする前に、 事前ステップを必ず行ってください。
apigee-mirror（RHEL 8.0）

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 ポリシーにわたってグローバルな変更を設定します。

  1. 構成プロパティ ファイルが存在しない場合は作成します。 
    /opt/apigee/customer/application/message-processor.properties
  2. ファイルに次の内容を追加します（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"
  3. ファイル /opt/apigee/customer/application/message-processor.properties の所有者が apigee:apigee であることを確認します。
  4. 各 Message Processor を再起動します。

接続プールの JNDI プロパティが有効になっていることを確認するには、tcpdump を実行して、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 を作成します。