Apigee의 알려진 문제

Apigee Edge 문서를 보고 있습니다.
Go to the Apigee X 문서로 이동합니다. info

다음 섹션에서는 Apigee Edge 및 Private Cloud용 Edge의 알려진 문제를 설명합니다. 대부분의 경우 나열된 문제는 향후 출시 버전에서 해결될 예정입니다.

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.

Edge UI의 알려진 문제

다음 섹션에서는 Edge UI의 알려진 문제를 설명합니다.

영역 알려진 문제
조직이 ID 영역에 매핑되면 탐색 메뉴에서 Edge SSO 영역 관리 페이지에 액세스할 수 없습니다. 조직을 ID 영역에 연결하면 더 이상 왼쪽 탐색 메뉴에서 Admin > SSO를 선택하여 Edge SSO 영역 관리 페이지에 액세스할 수 없습니다. 이 문제를 해결하려면 다음 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의 알려진 문제

다음 섹션에서는 프라이빗 클라우드용 Edge의 알려진 문제를 설명합니다.

지역 알려진 문제
프라이빗 클라우드용 Edge 4.53.01 NGINX 취약점 평가 (CVE-2026-42945)

NGINX의 ngx_http_rewrite_module에 영향을 미치는 취약점 (CVE-2026-42945)이 공개되었습니다. 이 모듈이 NGINX에 정적으로 컴파일되므로 보안 스캔 도구가 프라이빗 클라우드용 Apigee Edge에 포함된 NGINX 바이너리에 플래그를 지정할 수 있습니다.

프라이빗 클라우드용 Apigee Edge에 미치는 영향:

프라이빗 클라우드용 Apigee Edge는 기본 제공 구성에서 이 취약점의 영향을 받지 않습니다. CVE-2026-42945의 악용 가능성은 특정 NGINX 구성 패턴, 특히 특정 시퀀스에서 rewrite 명령어의 사용에 따라 다릅니다. 이러한 패턴은 표준 프라이빗 클라우드용 Apigee Edge NGINX 구성에 없습니다.

필요한 조치:

  • 기본 프라이빗 클라우드용 Apigee Edge 구성의 경우: 패치, 업그레이드 또는 운영 변경이 필요하지 않습니다. CVE-2026-42945와 관련된 스캐너 발견 항목은 기본 설치의 거짓양성으로 처리될 수 있습니다. 다음 텍스트를 사용하여 취약점 관리 시스템에서 이 예외를 문서화할 수 있습니다.

    CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

  • 맞춤설정된 NGINX 구성의 경우: 프라이빗 클라우드용 Apigee Edge 설치 내에서 NGINX 구성 파일을 수동으로 수정한 경우 (예: /opt/nginx 아래) 다음 자체 검사를 실행하여 맞춤설정으로 인해 실수로 취약한 패턴이 도입되지 않았는지 확인해야 합니다.
    1. rewrite 명령어 확인: 각 NGINX 노드에서 다음 명령어를 실행합니다. 
      sudo grep -rnI '^\s*rewrite\b' /opt/nginx
    2. 결과 분석:
      • 명령어가 출력을 반환하지 않으면 시스템이 영향을 받지 않습니다.
      • 일치하는 항목이 발견되면 각 인스턴스를 검토합니다. 취약점은 특정 블록에 대해 다음 조건을 모두 충족하는 경우에만 존재합니다.
        • rewrite 명령어가 사용됩니다.
        • 동일한 구성 블록 내에서 다른 rewrite, if 또는 set 명령어가 바로 뒤따릅니다.
        • 이름이 지정되지 않은 PCRE 캡처 그룹 (예: $1, $2 등)이 명령어에 사용됩니다.
        • 명령어의 대체 문자열에 물음표 (?)가 포함되어 있습니다.
    3. 완화 (취약한 경우): 맞춤 구성의 일부에 대해 위의 조건이 모두 참인 경우 다음을 수행하여 완화합니다.
      • 대체 문자열에서 물음표 (?)를 삭제합니다.
      • 이름이 지정되지 않은 PCRE 캡처 그룹 대신 이름이 지정된 PCRE 캡처 그룹을 사용합니다.
      • 연결된 명령어의 필요성을 다시 평가합니다.
프라이빗 클라우드용 Edge 4.53.00 440148595: 지원 종료 팝업 경고가 과도하게 표시됨

프라이빗 클라우드용 Edge 4.53.00 이상에서 UI에 "지원 종료" (EOL) 경고 팝업이 표시됩니다. 이 경고는 반복적으로 표시되며 빈도를 방지하거나 줄일 수 없습니다.

현재 사용자가 이 EOL 경고를 사용 중지하거나 빈도를 줄일 수 있는 방법은 없습니다.
프라이빗 클라우드용 Edge 4.53.01 Java 호출

이름 'BC'를 사용하여 Bouncy Castle 암호화 프로바이더를 로드하려는 고객 Java 콜아웃은 FIPS를 지원하기 위해 기본 프로바이더가 Bouncy Castle FIPS로 변경되었으므로 실패할 수 있습니다. 사용할 새 프로바이더 이름은 "BCFIPS"입니다.
프라이빗 클라우드용 Edge 4.53.00 Java 호출

이름 'BC'를 사용하여 Bouncy Castle 암호화 프로바이더를 로드하려는 고객 Java 콜아웃은 FIPS를 지원하기 위해 기본 프로바이더가 Bouncy Castle FIPS로 변경되었으므로 실패할 수 있습니다. 사용할 새 프로바이더 이름은 "BCFIPS"입니다.
프라이빗 클라우드용 Edge 4.52.01 Mint 업데이트

이 문제는 MINT를 사용하거나 프라이빗 클라우드용 Edge 설치에서 MINT를 사용 설정한 사용자에게만 영향을 미칩니다.

영향을 받는 구성요소: edge-message-processor

문제: 수익 창출을 사용 설정하고 4.52.01을 새로 설치하거나 이전 프라이빗 클라우드 버전에서 업그레이드하는 경우 메시지 프로세서에 문제가 발생합니다. 열린 스레드 수가 점진적으로 증가하여 리소스가 소진됩니다. edge-message-processor system.log에 다음 예외가 표시됩니다.

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread
Apigee HTTP/2 취약점

최근 프라이빗 클라우드용 Apigee Edge를 포함하여 HTTP/2 프로토콜 (CVE-2023-44487)의 여러 구현에서 서비스 거부 (DoS) 취약점이 발견되었습니다. 이 취약점으로 인해 Apigee API 관리 기능에 대한 DoS가 발생할 수 있습니다. 자세한 내용은 Apigee 보안 게시판 GCP-2023-032를 참고하세요.

프라이빗 클라우드용 Edge 라우터 및 관리 서버 구성요소는 인터넷에 노출되며 잠재적으로 취약할 수 있습니다. HTTP/2가 프라이빗 클라우드용 Edge의 다른 Edge 관련 구성요소의 관리 포트에서 사용 설정되더라도 이러한 구성요소는 인터넷에 노출되지 않습니다. Cassandra, Zookeeper 등과 같은 에지가 아닌 구성요소에서 HTTP/2는 사용 설정되지 않습니다. 프라이빗 클라우드용 Edge 취약점을 해결하려면 다음 단계를 따르는 것이 좋습니다.

프라이빗 클라우드용 Edge 버전 4.51.00.11 이상을 사용하는 경우 다음 단계를 따르세요.

  1. 관리 서버 업데이트:

    1. 각 관리 서버 노드에서 /opt/apigee/customer/application/management-server.properties를 엽니다.
    2. 속성 파일에 다음 줄을 추가합니다. 
      conf_webserver_http2.enabled=false
    3. 관리 서버 구성요소를 다시 시작합니다. 
      apigee-service edge-management-server restart

  2. 메시지 프로세서 업데이트:

    1. 각 메시지 프로세서 노드에서 /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

프라이빗 클라우드용 Edge 버전 4.51.00.11 이전 버전을 사용하는 경우 다음 단계를 따르세요.

  1. 관리 서버 업데이트:

    1. 각 관리 서버 노드에서 /opt/apigee/customer/application/management-server.properties를 엽니다.
    2. 속성 파일에 다음 두 줄을 추가합니다. 
      conf_webserver_http2.enabled=false
conf/webserver.properties+http2.enabled=false
    3. 관리 서버 구성요소를 다시 시작합니다. 
      apigee-service edge-management-server restart

  2. 메시지 프로세서 업데이트:

    1. 각 메시지 프로세서 노드에서 /opt/apigee/customer/application/message-processor.properties를 엽니다.
    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. 속성 파일에 다음 두 줄을 추가합니다. 
      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. 속성 파일에 다음 두 줄을 추가합니다. 
      conf_webserver_http2.enabled=false
conf/webserver.properties+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
conf/webserver.properties+http2.enabled=false
    3. 메시지 프로세서 구성요소를 다시 시작합니다. 
      apigee-service edge-postgres-server restart
버전 4.52로 업데이트할 때 Postgresql 업그레이드

Apigee-postgresql은 프라이빗 클라우드용 Edge 버전 4.50 또는 4.51에서 버전 4.52로 업그레이드하는 데 문제가 있습니다. 이 문제는 주로 테이블 수가 500개를 초과할 때 발생합니다.

아래의 SQL 쿼리를 실행하여 Postgres의 총 테이블 수를 확인할 수 있습니다.

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 기본값으로 인해 매번 일회용 연결이 발생합니다. 따라서 연결이 일회용으로 매번 열리고 닫히므로 LDAP 서버에 시간당 많은 연결이 생성됩니다.

해결 방법:

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. 각 메시지 프로세서를 다시 시작합니다.

연결 풀 JNDI 속성이 적용되는지 확인하려면 tcpdump를 실행하여 시간 경과에 따른 LDAP 연결 풀의 동작을 관찰하면 됩니다.
높은 요청 처리 지연 시간

139051927: 메시지 프로세서에서 발견된 높은 프록시 처리 지연 시간이 모든 API 프록시에 영향을 미칩니다. 증상으로는 일반 API 응답 시간보다 200~300ms 지연되는 처리 시간이 있으며 TPS가 낮은 경우에도 무작위로 발생할 수 있습니다. 메시지 프로세서가 연결하는 대상 서버가 50개를 초과할 때 발생할 수 있습니다.

근본 원인: 메시지 프로세서는 대상 서버 URL을 대상 서버로의 아웃바운드 연결을 위한 HTTPClient 객체에 매핑하는 캐시를 유지합니다. 기본적으로 이 설정은 50으로 설정되어 있으며 대부분의 배포에 너무 낮을 수 있습니다. 배포에 설정에 여러 조직/환경 조합이 있고 총 50개를 초과하는 많은 대상 서버가 있는 경우 대상 서버 URL이 캐시에서 계속 삭제되어 지연 시간이 발생합니다.

유효성 검사: 대상 서버 URL 삭제로 인해 지연 시간 문제가 발생하는지 확인하려면 메시지 프로세서 system.logs에서 키워드 "onEvict" 또는 "Eviction"을 검색합니다. 로그에 이러한 키워드가 있으면 캐시 크기가 너무 작기 때문에 대상 서버 URL 이 HTTPClient 캐시에서 삭제되고 있음을 나타냅니다.

해결 방법: 프라이빗 클라우드용 Edge 버전 19.01 및 19.06의 경우 HTTPClient 캐시 /opt/apigee/customer/application/message-processor.properties를 수정하고 구성할 수 있습니다.

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

그런 다음 메시지 프로세서를 다시 시작합니다. 모든 메시지 프로세서에 동일한 변경사항을 적용합니다.

값 500은 예시입니다. 설정의 최적 값은 메시지 프로세서가 연결할 대상 서버 수보다 커야 합니다. 이 속성을 더 높게 설정해도 부작용은 없으며 메시지 프로세서 프록시 요청 처리 시간이 개선되는 효과만 있습니다.

참고: 프라이빗 클라우드용 Edge 버전 50.00의 기본 설정은 500입니다.
키-값 맵의 여러 항목

157933959: 조직 또는 환경 수준으로 범위가 지정된 동일한 키-값 맵 (KVM)에 대한 동시 삽입 및 업데이트로 인해 데이터가 일관되지 않고 업데이트가 손실됩니다.

참고: 이 제한사항은 프라이빗 클라우드용 Edge에만 적용됩니다. 퍼블릭 클라우드용 Edge 및 Hybrid에는 이 제한사항이 없습니다.

프라이빗 클라우드용 Edge의 해결 방법은 apiproxy 범위에서 KVM을 만드는 것입니다.