Apigee に関する既知の問題

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動
情報

以降のセクションでは、Apigee の既知の問題について説明します。これらの問題は今後のリリースで修正される予定です。

Miscellaneous Edge known issues

The following sections describe miscellaneous known issues with Edge.

Area/Summary 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.

Concurrent deployment requests for a SharedFlow or API proxy can result in an inconsistent state in the Management Server where multiple revisions are shown as deployed.

This can happen, for example, when concurrent runs of a CI/CD deployment pipeline occur using different revisions. To avoid this problem, avoid deploying API proxies or SharedFlows before the current deployment is complete.

Workaround: Avoid concurrent API proxy or SharedFlow deployments.

API call counts shown in Edge API Analytics might contain duplicate data.

Edge API Analytics can sometimes contain duplicate data for API calls. In that case the counts shown for API calls in Edge API Analytics are higher than the comparable values shown in third-party analytics tools.

Workaround: Export the analytics data and use the gateway_flow_id field to de-duplicate the data.

Known issues with the Edge UI

The following sections describe the known issues with the Edge UI.

Area Known issues
Can't access Edge SSO Zone Administration page from navigation bar after organization is mapped to an identity zone When you connect an organization to an identity zone, you can no longer access the Edge SSO Zone Administration page from the left navigation bar by selecting Admin > SSO. As a workaround, navigate to the page directly using the following URL: https://apigee.com/sso

Known issues with the integrated portal

The following sections describe the known issues with the integrated portal.

Area Known issues
SmartDocs
  • Apigee Edge supports OpenAPI Specification 3.0 when you create specifications using the spec editor and publish APIs using SmartDocs on your portal, though a subset of features are not yet supported.

    For example, the following features from the OpenAPI Specification 3.0 are not yet supported:

    • allOf properties for combining and extending schemas
    • Remote references

    If an unsupported feature is referenced in your OpenAPI Specification, in some cases the tools will ignore the feature but still render the API reference documentation. In other cases, an unsupported feature will cause errors that prevent the successful rendering of the API reference documentation. In either case, you will need to modify your OpenAPI Specification to avoid use of the unsupported feature until it is supported in a future release.

    Note: Because the spec editor is less restrictive than SmartDocs when rendering API reference documentation, you may experience different results between the tools.

  • When using Try this API in the portal, the Accept header is set to application/json regardless of the value set for consumes in the OpenAPI Specification.
  • 138438484: Multiple servers are not supported.
SAML identity provider Single logout (SLO) with the SAML identity provider is not supported for custom domains. To enable a custom domain with a SAML identity provider, leave the Sign-out URL field blank when you configure SAML settings.
Portal admin
  • Simultaneous portal updates (such as page, theme, CSS, or script edits) by multiple users is not supported at this time.
  • If you delete an API reference documentation page from the portal, there is no way to recreate it; you'll need to delete and re-add the API product, and regenerate the API reference documentation.
  • When configuring the content security policy, it may take up to 15 minutes for changes to fully apply.
  • When customizing your portal theme, it may take up to 5 minutes for changes to fully apply.
Portal features
  • Search will be integrated into the integrated portal in a future release.

Edge for Private Cloud の既知の問題

以降のセクションでは、Edge for Private Cloud の既知の問題について説明します。

地域 既知の問題
Edge for Private Cloud 4.53.00 Java コールアウト

FIPS をサポートするためにデフォルト プロバイダが Bouncy Castle FIPS に変更されたため、名前「BC」を使用して Bouncy Castle 暗号プロバイダを読み込もうとするカスタマー Java コールアウトが失敗することがあります。使用する新しいプロバイダ名は 「BCFIPS」 です。

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. メッセージ プロセッサを更新します。

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

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

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

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

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

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

    1. 各 Management Server ノードで /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. Message Processor コンポーネントを再起動します。
      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. Message Processor コンポーネントを再起動します。
      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. Message Processor コンポーネントを再起動します。
      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 をアップグレードする前に、 事前ステップを必ず行ってください。

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 を作成します。