504 게이트웨이 시간 초과

Apigee Edge 문서입니다.
Apigee X 문서로 이동 정보

증상

클라이언트 애플리케이션은 API 호출에 대한 응답으로 Gateway Timeout 메시지가 포함된 HTTP 상태 코드 504를 수신합니다.

HTTP 상태 코드 - 504 Gateway Timeout 오류는 API 실행 중에 클라이언트가 에지 게이트웨이 또는 백엔드 서버로부터 적시에 응답을 받지 못했음을 나타냅니다.

오류 메시지

클라이언트 애플리케이션은 다음 응답 코드를 받습니다.

HTTP/1.1 504 Gateway Timeout

경우에 따라 다음 오류 메시지가 표시될 수도 있습니다.

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

게이트웨이 제한 시간 초과는 왜 발생하나요?

Edge 플랫폼을 통한 API 요청의 일반적인 경로는 아래 그림과 같이 클라이언트 -> 라우터 -> 메시지 프로세서 -> 백엔드 서버입니다.

Edge 플랫폼 내의 클라이언트 애플리케이션, 라우터, 메시지 프로세서는 적절한 제한 시간 값으로 설정됩니다. Edge 플랫폼은 제한 시간 값을 기준으로 모든 API 요청에 대해 일정 기간 내에 응답이 전송될 것으로 예상합니다. 지정된 시간 내에 응답을 받지 못하면 504 Gateway Timeout Error이 반환됩니다.

다음 표에는 Edge에서 제한 시간이 발생할 수 있는 시점에 관한 자세한 내용이 나와 있습니다.

시간 초과 발생 횟수 세부정보
메시지 프로세서에서 제한 시간 발생
  • 백엔드 서버가 메시지 프로세서의 지정된 제한 시간 내에 메시지 프로세서에 응답하지 않습니다.
  • 메시지 프로세서가 타임아웃되고 응답 상태를 504 Gateway Timeout로 라우터에 전송합니다.
라우터에서 시간 초과가 발생함
  • 메시지 프로세서가 라우터의 지정된 제한 시간 내에 라우터에 응답하지 않습니다.
  • 라우터가 타임아웃되고 응답 상태를 504 Gateway Timeout로 클라이언트 애플리케이션에 전송합니다.
클라이언트 애플리케이션에서 시간 초과가 발생함
  • 라우터가 라우터에서 지정된 제한 시간 내에 클라이언트 애플리케이션에 응답하지 않습니다.
  • 클라이언트 애플리케이션이 타임아웃되고 최종 사용자에게 응답 상태를 504 Gateway Timeout로 종료합니다.

가능한 원인

Edge에서 504 Gateway Timeout 오류의 일반적인 원인은 다음과 같습니다.

원인 세부정보 다음에 대해 제공된 단계
느린 백엔드 서버 API 요청을 처리하는 백엔드 서버가 높은 부하 또는 저조한 성능으로 인해 너무 느립니다. 퍼블릭 및 프라이빗 클라우드 사용자
Edge에서 API 요청 처리가 느림 Edge에서 부하가 높거나 성능이 저하되어 API 요청을 처리하는 데 시간이 오래 걸립니다.

느린 백엔드 서버

백엔드 서버가 매우 느리거나 API 요청을 처리하는 데 시간이 오래 걸리면 504 Gateway Timeout 오류가 발생합니다. 위 섹션에서 설명한 대로 다음 시나리오 중 하나에서 제한 시간이 발생할 수 있습니다.

  1. 백엔드 서버가 응답하기 전에 메시지 프로세서가 시간 초과됩니다.
  2. 메시지 프로세서/백엔드 서버가 응답하기 전에 라우터가 시간 초과됩니다.
  3. 라우터/메시지 프로세서/백엔드 서버가 응답하기 전에 클라이언트 애플리케이션의 시간이 초과됩니다.

다음 섹션에서는 이러한 각 시나리오에서 문제를 진단하고 해결하는 방법을 설명합니다.

시나리오 1: 메시지 프로세서가 백엔드 서버가 응답하기 전에 제한 시간 초과됨

진단

다음 절차에 따라 느린 백엔드 서버로 인해 504 Gateway Timeout 오류가 발생했는지 진단할 수 있습니다.

절차 1: Trace 사용

문제가 계속 발생하는 경우 (504 오류가 계속 발생함) 아래 단계를 따르세요.

  1. Edge UI에서 영향을 받는 API를 추적합니다. 오류가 발생할 때까지 기다리거나 API 호출이 있는 경우 API를 호출하고 504 Gateway Timeout 오류를 재현합니다.
  2. 오류가 발생하면 응답 코드가 504로 표시되는 특정 요청을 검사합니다.
  3. 각 단계에서 경과된 시간을 확인하고 시간이 가장 많이 소비된 단계를 기록합니다.
  4. 다음 단계 중 하나를 수행한 직후에 경과 시간이 가장 긴 오류가 발생하면 백엔드 서버가 느리거나 요청을 처리하는 데 시간이 오래 걸리는 것입니다.
    • 요청이 대상 서버로 전송됨
    • ServiceCallout 정책

다음은 55초 후에도 백엔드 서버가 응답하지 않아 504 Gateway Timeout 오류가 발생했음을 보여주는 샘플 Trace입니다.

위 트레이스에서 백엔드 서버가 응답하지 않으므로 메시지 프로세서가 55, 002ms 후에 제한 시간 초과됩니다.

절차 2: 메시지 프로세서 로그 사용

  1. 메시지 프로세서의 로그(/opt/apigee/var/log/edge-message-processor/logs/system.log)를 확인합니다.

  2. 특정 시간의 특정 API 프록시 요청에 대해 Gateway Timeout 및 onTimeoutRead 오류가 발견되면 메시지 프로세서의 타임아웃이 발생한 것입니다.

    게이트웨이 시간 초과 오류를 보여주는 샘플 메시지 프로세서 로그

    2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

    위의 메시지 프로세서 로그에서 IP 주소 XX.XX.XX.XX로 표시된 백엔드 서버가 55초 후에도 응답하지 않았습니다 (lastIO=55000ms). 따라서 메시지 프로세서의 시간이 초과되어 504 Gateway Timeout 오류를 보냈습니다.

    확인: 메시지 프로세서에서 시간 제한이 어떻게 제어되나요?

    • 메시지 프로세서에서 제한 시간을 제어하는 방법 메시지 프로세서는 일반적으로 HTTPTransport.io.timeout.millis 속성을 통해 기본 시간 제한 값(55초)으로 설정됩니다. 이 제한 시간 값은 이 메시지 프로세서에서 제공하는 조직에 속한 모든 API 프록시에 적용됩니다.
      • 백엔드 서버가 55초 내에 응답하지 않으면 메시지 프로세서의 시간이 초과되고 504 Gateway Timeout 오류를 클라이언트에 보냅니다.
    • 메시지 프로세서에 지정된 제한 시간 값은 API 프록시 내에 지정된 io.timeout.millis 속성으로 재정의할 수 있습니다. 이 제한 시간 값은 위에 언급된 속성이 지정된 특정 API 프록시에 적용됩니다. 예를 들어 API 프록시 내에서 io.timeout.millis가 10초로 설정되면 이 특정 API 프록시에는 10초의 제한 시간 값이 사용됩니다.
      • 백엔드 서버가 특정 API 프록시에 대해 10초 이내에 응답하지 않으면 메시지 프로세서가 시간 초과되어 클라이언트에 504 Gateway Timeout 오류를 전송합니다.

해상도

  1. 백엔드 서버가 55초 이상 걸리는 이유를 확인하고 더 빠르게 응답하도록 수정/최적화할 수 있는지 확인합니다.
  2. 백엔드 서버를 수정/최적화할 수 없거나 백엔드 서버가 구성된 제한 시간보다 오래 걸리는 것으로 알려진 경우 라우터 및 메시지 프로세서의 시간 제한 값을 적절한 값으로 늘리세요.

시나리오 #2 - 메시지 프로세서/백엔드 서버가 응답하기 전에 라우터가 타임아웃됨

메시지 프로세서/백엔드 서버가 응답하기 전에 라우터가 타임아웃되면 504 Gateway Timeout 오류가 발생할 수 있습니다. 다음과 같은 상황에서 이 문제가 발생할 수 있습니다.

  • 라우터에 설정된 제한 시간 값이 메시지 프로세서에 설정된 시간 제한 값보다 짧습니다. 예를 들어 라우터의 제한 시간은 50초이고 메시지 프로세서의 제한 시간은 55초라고 가정해 보겠습니다.
    라우터 시간 초과 메시지 프로세서 시간 초과
    50초 55초
  • 메시지 프로세서의 제한 시간 값은 API 프록시의 대상 엔드포인트 구성 내에 설정된 io.timeout.millis 속성을 사용하여 더 긴 제한 시간 값으로 재정의됩니다.

    예를 들어 다음과 같이 시간 제한 값이 설정된 경우

    라우터 시간 초과 메시지 프로세서 시간 초과 API 프록시 내 시간 초과
    57초 55초 120초

    하지만 API 프록시에서 io.timeout.millis는 120초로 설정되어 있습니다.

    <HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

    그러면 메시지 프로세서의 제한 시간 값 (55초)이 라우터의 제한 시간 값 (57초)보다 작더라도 55초 후에 제한 시간이 초과되지 않습니다. 메시지 프로세서의 제한 시간 값 55초가 API 프록시 내에 설정된 120초 값으로 재정의되기 때문입니다. 따라서 이 특정 API 프록시의 메시지 프로세서의 제한 시간 값은 120초가 됩니다.

    라우터의 제한 시간 값 (57초)은 API 프록시 내에 설정된 120초보다 낮으므로 백엔드 서버가 57초 후에 응답하지 않으면 라우터가 시간 초과됩니다.

진단

  1. NGINX 액세스 로그(/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)를 확인합니다.

  2. 메시지 프로세서보다 먼저 라우터가 시간 초과되면 특정 API 요청의 NGINX 액세스 로그에 504 상태가 표시되고 메시지 프로세서의 message id가 -로 설정됩니다. 라우터에 설정된 제한 시간 내에 라우터가 메시지 프로세서로부터 응답을 받지 못했기 때문입니다.

    라우터 타임아웃으로 인해 504가 표시되는 샘플 NGINX 로그 항목

  3. 위 예에서 NGINX의 상태는 504이고, 메시지 프로세서의 메시지 ID는 -이며, 경과한 총 시간은 57.001초입니다. 라우터가 57.001초 후에 시간 초과되었고 메시지 프로세서로부터 응답을 받지 못했기 때문입니다.
  4. 이 경우 메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log). 
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>
    )에 Broken Pipe 예외가 표시됩니다.

이 오류는 라우터의 시간 초과로 인해 메시지 프로세서와의 연결이 닫히기 때문에 표시됩니다. 메시지 프로세서가 처리를 완료하면 응답을 라우터에 쓰려고 시도합니다. 라우터에 대한 연결이 이미 닫혔으므로 메시지 프로세서에서 Broken Pipe exception이 발생합니다.

이 예외는 위에 설명된 상황에서 표시될 것으로 예상됩니다. 따라서 504 Gateway Timeout 오류의 실제 원인은 백엔드 서버가 응답하는 데 시간이 더 오래 걸리는 것이므로 이 문제를 해결해야 합니다.

해상도

  1. 맞춤 백엔드 서버인 경우 다음을 실행합니다.
    1. 백엔드 서버가 응답하는 데 시간이 오래 걸리는 이유를 확인하고 더 빠르게 응답하도록 고정/최적화할 수 있는지 확인합니다.
    2. 백엔드 서버를 수정/최적화할 수 없거나 백엔드 서버가 오래 걸리는 것으로 알려진 경우 라우터 및 메시지 프로세서의 제한 시간 값을 늘립니다.

      아이디어: 다음 순서대로 여러 구성요소의 제한 시간 값을 설정합니다.

      클라이언트 시간 제한 > 라우터 시간 제한 > 메시지 프로세서 시간 제한 > API 프록시 내 시간 제한
  2. NodeJS 백엔드 서버인 경우 다음을 실행합니다.
    1. NodeJS 코드가 다른 백엔드 서버를 호출하는지, 응답을 반환하는 데 시간이 오래 걸리는지 확인합니다. 백엔드 서버에 시간이 더 오래 걸리는 이유를 확인하고 적절하게 문제를 해결합니다.
    2. 메시지 프로세서에서 CPU 또는 메모리 사용량이 높은지 확인합니다.
      1. 메시지 프로세서에서 CPU 사용량이 높은 경우 다음 명령어를 사용하여 30초마다 스레드 덤프 3개를 생성합니다. 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. 메시지 프로세서의 메모리 사용량이 많은 경우 다음 명령어를 사용하여 힙 덤프를 생성하세요. 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. 아래 명령어를 사용하여 메시지 프로세서를 다시 시작합니다. 다음과 같이 CPU와 메모리가 중단됩니다. 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. API 호출을 모니터링하여 문제가 계속 발생하는지 확인합니다.
      5. Apigee Edge 지원팀에 문의하여 스레드 덤프, 힙 덤프, 메시지 프로세서 로그(/opt/apigee/var/log/edge-message-processor/logs/system.log))를 제공합니다. 이는 높은 CPU/메모리 사용량의 원인을 조사하는 데 도움이 됩니다.

확인 사항: 메시지 프로세서에서 NodeJS 백엔드 서버의 제한 시간을 제어하는 방법

  • NodeJS 백엔드 서버는 메시지 프로세서의 JVM 프로세스 내에서 실행됩니다. NodeJS 백엔드 서버의 제한 시간 값은 nodejs.properties 파일의 http.request.timeout.seconds 속성을 통해 제어됩니다. 이 속성은 기본적으로 0으로 설정됩니다. 즉, 이 메시지 프로세서에서 제공하는 조직에 속한 모든 API 프록시의 시간 제한은 기본적으로 사용 중지됩니다. 따라서 NodeJS 백엔드 서버에 시간이 오래 걸리더라도 메시지 프로세서는 시간이 초과되지 않습니다.
  • 그러나 NodeJS 백엔드 서버가 오래 걸리고 API 요청에 걸리는 시간이 57초를 초과하면 라우터가 시간 초과되어 클라이언트에 504 Gateway Timeout 오류를 전송합니다.

시나리오 #3 - 라우터/메시지 프로세서/백엔드 서버가 응답하기 전에 클라이언트 애플리케이션 타임아웃

백엔드 서버가 응답하기 전에 클라이언트 애플리케이션이 타임아웃되면 504 Gateway Timeout 오류가 발생할 수 있습니다. 이러한 상황은 다음과 같은 경우에 발생할 수 있습니다.

  1. 클라이언트 애플리케이션에 설정된 시간 제한 값이 라우터와 메시지 프로세서에 설정된 시간 제한 값보다 작습니다.

    예를 들어 제한 시간 값이 다음과 같이 설정된 경우입니다.

    클라이언트 시간 초과 라우터의 시간 제한 메시지 프로세서 시간 초과
    50초 57초 55초

    이 경우 Edge를 통해 API 요청에 대한 응답을 가져오는 데 사용할 수 있는 총 시간은 50초 미만입니다. 여기에는 API 요청을 실행하는 데 걸린 시간, 에지 (라우터, 메시지 프로세서)에서 처리되는 요청, 백엔드 서버로 전송되는 요청(해당하는 경우), 백엔드에서 요청을 처리하고 응답을 전송하는 시간, 에지에서 응답을 처리하고 최종적으로 클라이언트로 다시 전송하는 시간이 포함됩니다.

    라우터가 50초 이내에 클라이언트에 응답하지 않으면 클라이언트가 시간 초과되어 라우터와의 연결을 닫습니다. 클라이언트는 504 응답 코드를 받습니다.

    그러면 NGINX에서 클라이언트가 연결을 닫았음을 나타내는 499 상태 코드를 설정합니다.

진단

  1. 클라이언트 애플리케이션이 라우터로부터 응답을 받기 전에 제한 시간이 초과되면 라우터와의 연결이 닫힙니다. 이 경우 특정 API 요청의 NGINX 액세스 로그에 상태 코드 499가 표시됩니다.

    상태 코드 499를 보여주는 샘플 NGINX 로그 항목

  2. 위의 예시에서 NGINX의 499 상태와 총 경과 시간은 50.001초입니다. 이는 클라이언트가 50.001초 후에 시간 초과되었음을 나타냅니다.
  3. 이 경우 메시지 프로세서 로그에 Broken Pipe 예외가 표시됩니다 (/opt/apigee/var/log/edge-message-processor/logs/system.log).
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>
  4. 라우터의 제한 시간이 지나면 메시지 프로세서와의 연결이 닫힙니다. 메시지 프로세서가 처리를 완료하면 라우터에 응답을 쓰려고 시도합니다. 라우터에 대한 연결이 이미 닫혔으므로 메시지 프로세서에서 Broken Pipe exception이 발생합니다.
  5. 위에 설명된 상황에서는 이 예외가 발생할 수 있습니다. 따라서 504 Gateway Timeout 오류의 실제 원인은 백엔드 서버가 응답하는 데 시간이 오래 걸리는 것이므로 이 문제를 해결해야 합니다.

해상도

  1. 커스텀 백엔드 서버인 경우:
    1. 백엔드 서버를 확인하여 57초가 넘게 걸리는 이유를 파악하고 더 빠르게 응답하도록 수정/최적화할 수 있는지 확인합니다.
    2. 백엔드 서버를 수정/최적화할 수 없거나 백엔드 서버가 오래 걸릴 것으로 예상되는 경우 라우터 및 메시지 프로세서의 제한 시간 값을 늘립니다.

      아이디어: 다음 순서대로 여러 구성요소의 제한 시간 값을 설정합니다.

      클라이언트 시간 제한 > 라우터 시간 제한 > 메시지 프로세서 시간 제한 > API 프록시 내 시간 제한
  2. NodeJS 백엔드인 경우 다음을 실행합니다.
    1. NodeJS 코드가 다른 백엔드 서버를 호출하는지, 반환하는 데 시간이 오래 걸리는지 확인합니다. 백엔드 서버가 더 오래 걸리는 이유를 확인합니다.
    2. 메시지 프로세서에서 CPU 또는 메모리 사용량이 높은지 확인합니다.
      1. 메시지 프로세서의 CPU 사용량이 많으면 다음 명령어를 사용하여 30초마다 스레드 덤프를 3개 생성합니다. 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. 메시지 프로세서에서 메모리 사용량이 많으면 다음 명령어를 사용하여 힙 덤프를 생성합니다. 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. 아래 명령어를 사용하여 메시지 프로세서를 다시 시작합니다. 이렇게 하면 CPU와 메모리가 줄어듭니다. 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. API 호출을 모니터링하여 문제가 계속 발생하는지 확인합니다.
      5. Apigee Edge 지원팀에 문의하여 스레드 덤프, 힙 덤프, 메시지 프로세서 로그(/opt/apigee/var/log/edge-message-processor/logs/system.log))를 제공합니다. 이를 통해 높은 CPU/메모리 사용량의 원인을 조사할 수 있습니다.

라우터 및 메시지 프로세서의 제한 시간 값 늘리기

요구사항에 따라 라우터 및 메시지 프로세서에 설정할 제한 시간 값을 신중하게 선택합니다. 임의로 큰 시간 제한 값을 설정하지 마세요. 도움이 필요하면 Apigee Edge 지원팀에 문의하세요.

라우터

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. /opt/apigee/customer/application/router.properties 파일이 아직 없다면 라우터 머신에서 이 파일을 만듭니다.
  2. 이 파일에 다음 줄을 추가합니다. 
    conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

    예를 들어 제한 시간 값을 120초로 설정하려면 다음과 같이 설정합니다.

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. 이 파일의 소유자가 apigee인지 확인합니다.
  4. 라우터를 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  5. 라우터가 2대 이상인 경우 모든 라우터에서 위 단계를 반복합니다.

메시지 프로세서

  1. 메시지 프로세서 머신에 /opt/apigee/customer/application/message-processor.properties 파일이 없는 경우 이 파일을 만듭니다.
  2. 이 파일에 다음 줄을 추가합니다. 
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

    예를 들어 제한 시간 값을 120초로 설정하려면 다음과 같이 설정합니다.

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. 이 파일( 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
    )이 Apigee의 소유인지 확인하세요.
  4. 메시지 프로세서를 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. 메시지 프로세서가 두 개 이상인 경우 모든 메시지 프로세서에서 위 단계를 반복합니다.

아이디어: 다음 순서대로 여러 구성요소의 제한 시간 값을 설정합니다.

클라이언트의 제한 시간 > 라우터의 제한 시간 > 메시지 프로세서의 제한 시간 > API 프록시 내 제한 시간

Edge의 느린 API 요청 처리

Edge가 매우 느리거나 API 요청을 처리하는 데 시간이 오래 걸리면 504 Gateway Timeout 오류가 발생합니다.

진단

  1. Edge UI에서 영향을 받는 API를 추적합니다.
  2. 오류가 발생할 때까지 기다리거나 API를 호출한 다음 API를 호출하고 504 Gateway Timeout 오류를 재현합니다.
  3. 이 경우 트레이스에 성공 응답이 표시될 수 있습니다.
    1. 메시지 프로세서가 라우터/클라이언트에서 지정된 제한 시간 내에 다시 응답하지 않으므로 라우터/클라이언트가 타임아웃됩니다. 하지만 메시지 프로세서는 요청을 계속 처리하며 성공적으로 완료될 수 있습니다.
    2. 또한 메시지 프로세서에 설정된 HTTPTransport.io.timeout.millis 값은 메시지 프로세서가 HTTP/HTTPS 백엔드 서버와 통신하는 경우에만 트리거됩니다. 즉, API 프록시 내의 정책 (ServiceCallout 정책 제외)이 오래 걸리는 경우 이 제한 시간은 트리거되지 않습니다.
  4. 오류가 발생한 후 경과 시간이 가장 긴 특정 요청을 검사합니다.
  5. 각 단계에서 경과된 시간을 확인하고 시간이 가장 많이 소비된 단계를 기록합니다.
  6. Service Callout 정책 이외의 정책에서 가장 긴 경과 시간이 관찰되면 Edge에서 요청을 처리하는 데 시간이 오래 걸린다는 의미입니다.
  7. 다음은 JavaScript 정책에서 경과 시간이 매우 긴 샘플 UI 트레이스입니다.

  8. 위 예시에서 JavaScript 정책이 약 245초라는 비정상적으로 긴 시간이 걸리는 것을 확인할 수 있습니다.

해상도

  1. 응답하는 데 시간이 오래 걸린 정책이 있는지, 처리하는 데 시간이 오래 걸릴 수 있는 맞춤 코드가 있는지 확인합니다. 이러한 코드가 있는 경우 식별된 코드를 수정/최적화할 수 있는지 확인합니다.
  2. 처리 시간이 길어질 수 있는 맞춤 코드가 없는 경우 메시지 프로세서에서 CPU 또는 메모리 사용량이 높은지 확인합니다.
    1. 메시지 프로세서에서 CPU 사용량이 높은 경우 다음 명령어를 사용하여 30초마다 스레드 덤프 3개를 생성합니다. 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. 메시지 프로세서에서 메모리 사용량이 많은 경우 다음 명령어를 사용하여 힙 덤프를 생성합니다. 
      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
    3. 아래 명령어를 사용하여 메시지 프로세서를 다시 시작합니다. 이렇게 하면 CPU 및 메모리가 줄어듭니다. 
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. API 호출을 모니터링하고 문제가 계속 발생하는지 확인합니다.
    5. Apigee Edge 지원팀에 문의하여 스레드 덤프, 힙 덤프, 메시지 프로세서 로그(/opt/apigee/var/log/edge-message-processor/logs/system.log))를 제공합니다. 이를 통해 높은 CPU/메모리 사용량의 원인을 조사할 수 있습니다.

API 모니터링을 사용하여 문제 진단

API 모니터링을 사용하면 문제 영역을 빠르게 격리하여 오류, 성능, 지연 시간 문제와 그 소스(예: 개발자 앱, API 프록시, 백엔드 대상, API 플랫폼)를 진단할 수 있습니다.

API Monitoring을 사용하여 API의 5xx 문제를 해결하는 방법을 보여주는 샘플 시나리오를 살펴봅니다. 예를 들어 504 상태 코드 수가 특정 기준을 초과하면 알림을 받도록 알림을 설정할 수 있습니다.