Apigee의 알려진 문제

cachehit 흐름 변수가 LookupCache 정책 뒤에 사용되면 비동기 동작에 대해 디버그 포인트가 전달되는 방식으로 인해 LookupPolicy가 콜백이 실행되기 전에 DebugInfo 객체를 채우므로 오류가 발생합니다.

해결 방법: 첫 번째 호출 직후 프로세스를 다시 반복합니다 (두 번째 호출).

InvalidateCache 정책에서 PurgeChildEntries를 설정하면 KeyFragment 요소 값만 삭제해야 하지만 전체 캐시가 삭제됩니다.

해결 방법: KeyValueMapOperations 정책을 사용하여 캐시 버전 관리를 반복하고 캐시 무효화 필요성을 우회합니다.

예를 들어 다른 버전을 사용하여 CI/CD 배포 파이프라인의 동시 실행이 실행되는 경우 이런 문제가 발생할 수 있습니다. 이 문제를 방지하려면 현재 배포가 완료되기 전에 API 프록시 또는 SharedFlow를 배포하지 마세요.

해결 방법: 동시 API 프록시 또는 SharedFlow 배포를 피합니다.

Edge API 애널리틱스에는 API 호출에 대한 중복 데이터가 포함될 수 있습니다. 이 경우 Edge API 애널리틱스에서 API 호출에 표시되는 개수가 서드 파티 분석 도구에 표시되는 유사한 값보다 높습니다.

해결 방법: 애널리틱스 데이터를 내보내고 gateway_flow_id 필드를 사용하여 데이터 중복을 삭제합니다.

• 포털에서 SmartDocs를 사용하여 사양 편집기를 사용하여 사양을 만들고 API를 게시하는 경우 Apigee Edge는 OpenAPI 사양 3.0을 지원하지만 일부 기능은 아직 지원되지 않습니다.

  예를 들어 다음의 OpenAPI 사양 3.0 기능이 아직 지원되지 않습니다.

  • 스키마 결합 및 확장을 위한 allOf 속성
  • 원격 참조

  OpenAPI 사양에서 지원되지 않는 기능을 참조하는 경우, 도구가 기능을 무시하지만 API 참조 문서는 계속 렌더링합니다. 다른 경우에는 지원되지 않는 기능이 API 참조 문서의 성공적인 렌더링을 방지하는 오류를 일으킵니다. 두 경우 모두 지원되지 않는 기능이 향후 출시 버전에서 지원될 때까지 사용되지 않도록 OpenAPI 사양을 수정해야 합니다.

  참고: API 참조 문서를 렌더링할 때 사양 편집기는 SmartDocs보다 제한이 적으므로 도구에 따라 결과가 다를 수 있습니다.

• 포털에서 이 API 사용해 보기를 사용하는 경우 OpenAPI 사양에서 consumes에 설정된 값에 관계없이 Accept 헤더가 application/json으로 설정됩니다.
• 138438484: 여러 서버는 지원되지 않습니다.

• 현재 여러 사용자의 동시 포털 업데이트(예: 페이지, 테마, CSS, 스크립트 수정)는 지원되지 않습니다.
• 포털에서 API 참조 문서 페이지를 삭제하면 다시 생성할 수 없습니다. API 제품을 삭제 및 다시 추가하고 API 참조 문서를 다시 생성해야 합니다.
• 콘텐츠 보안 정책을 구성할 때 변경사항이 완전히 적용되는 데 최대 15분이 걸릴 수 있습니다.
• 포털 테마를 맞춤설정할 때 변경사항이 완전히 적용되는 데 최대 5분이 걸릴 수 있습니다.

• 향후 출시 버전에서는 통합 포털에 검색이 통합될 예정입니다.

이 문제는 MINT를 사용하거나 프라이빗 클라우드용 Edge 설치에서 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 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 for Private Cloud 버전 4.51.00.11 이상 단계
• Private Cloud용 Edge 버전 4.51.00.11 이전 버전의 단계

Edge Private Cloud 버전 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 for Private Cloud 버전이 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

Apigee-postgresql에서 Edge for Private Cloud 버전 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을 업그레이드하기 전에 사전 단계를 실행해야 합니다.

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 for Private Cloud 버전 19.01 및 19.06의 경우 HTTPClient 캐시 /opt/apigee/customer/application/message-processor.properties를 수정하고 구성할 수 있습니다.

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

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

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

참고: Private Cloud용 Edge 버전 50.00의 기본 설정은 500입니다.

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

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

Edge for Private Cloud의 해결 방법으로 apiproxy 범위에서 KVM을 만듭니다.