Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

504 게이트웨이 시간 초과

Apigee Edge 문서를 보고 있습니다.
Apigee X 문서로 이동하세요. info

증상

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

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

오류 메시지

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

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 백엔드 서버가 응답하기 전에 메시지 프로세서가 제한 시간 초과됨

진단

다음 절차를 사용하여 백엔드 서버가 느려서 504 Gateway Timeout 오류가 발생했는지 진단할 수 있습니다.

절차 1: Trace 사용

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

Edge UI에서 영향을 받는 API를 추적합니다. 오류가 발생할 때까지 기다리거나 API 호출이 있는 경우 API를 몇 번 호출하여 504 Gateway Timeout 오류를 재현합니다.
오류가 발생하면 응답 코드가 504로 표시되는 특정 요청을 검사합니다.
각 단계에서 경과된 시간을 확인하고 시간이 가장 많이 소요된 단계를 기록합니다.
다음 단계 중 하나 직후에 경과 시간이 가장 긴 오류가 관찰되면 백엔드 서버가 느리거나 요청을 처리하는 데 시간이 오래 걸린다는 의미입니다.
- 요청이 타겟 서버로 전송됨
- ServiceCallout 정책

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

위 추적에서 백엔드 서버가 응답하지 않으므로 메시지 프로세서의 제한 시간이 55002ms 후에 만료됩니다.

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

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

특정 시간에 특정 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 오류를 전송합니다.

해상도

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

시나리오 2 - 메시지 프로세서/백엔드 서버가 응답하기 전에 라우터가 제한 시간을 초과함

메시지 프로세서/백엔드 서버가 응답하기 전에 라우터의 시간이 초과되면 504 Gateway Timeout 오류가 발생할 수 있습니다. 이 문제는 다음 중 한 가지 상황에서 발생할 수 있습니다.

라우터에 설정된 제한 시간 값이 메시지 프로세서에 설정된 제한 시간 값보다 짧습니다. 예를 들어 라우터의 제한 시간은 50초이고 메시지 프로세서는 55초라고 가정해 보겠습니다.

라우터에서 시간 초과 메시지 프로세서 시간 초과

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초 후에 응답하지 않으면 라우터가 제한 시간 초과됩니다.

진단

NGINX 액세스 로그 확인(/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
메시지 프로세서보다 먼저 라우터의 시간이 초과되면 특정 API 요청에 대한 NGINX 액세스 로그에 504 상태가 표시되고 메시지 프로세서의 message id이 -로 설정됩니다. 이는 라우터에 설정된 제한 시간 내에 라우터가 메시지 프로세서로부터 응답을 받지 못했기 때문입니다.

라우터 시간 초과로 인해 504를 보여주는 샘플 NGINX 로그 항목
위의 예에서 NGINX의 504 상태를 확인하세요. 메시지 프로세서의 메시지 ID는 -이고 경과된 총 시간은 57.001초입니다. 이는 라우터가 57.001초 후에 제한 시간이 초과되었고 메시지 프로세서로부터 응답을 받지 못했기 때문입니다.

이 경우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-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 exception가 표시됩니다.

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

해상도

커스텀 백엔드 서버인 경우

백엔드 서버가 응답하는 데 시간이 오래 걸리는 이유를 확인하고 더 빠르게 응답하도록 수정/최적화할 수 있는지 확인합니다.

백엔드 서버를 수정/최적화할 수 없거나 백엔드 서버에 시간이 오래 걸린다는 사실을 알고 있는 경우 라우터 및 메시지 프로세서에서 제한 시간 값을 늘리세요.

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

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

NodeJS 백엔드 서버인 경우 다음을 실행합니다.
1. NodeJS 코드가 다른 백엔드 서버를 호출하는지, 응답을 반환하는 데 시간이 오래 걸리는지 확인합니다. 백엔드 서버에 시간이 오래 걸리는 이유를 확인하고 적절하게 문제를 해결합니다.
2. 메시지 프로세서의 CPU 또는 메모리 사용량이 높은지 확인합니다.
  1. 메시지 프로세서의 CPU 사용량이 높은 경우 다음 명령어를 사용하여 30초마다 스레드 덤프를 세 개 생성합니다.
```
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 지원팀에 문의하여 높은 CPU/메모리 사용량의 원인을 조사하는 데 도움이 되도록 스레드 덤프, 힙 덤프, 메시지 프로세서 로그(/opt/apigee/var/log/edge-message-processor/logs/system.log))를 제공하세요.

확인: 메시지 프로세서에서 NodeJS 백엔드 서버의 제한 시간은 어떻게 제어되나요?

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

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

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

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

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

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

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

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

이렇게 하면 클라이언트가 연결을 닫았음을 나타내는 499 상태 코드가 NGINX에 설정됩니다.

진단

클라이언트 애플리케이션이 라우터로부터 응답을 받기 전에 제한 시간이 초과되면 라우터와의 연결이 닫힙니다. 이 경우 특정 API 요청에 대한 NGINX 액세스 로그에 상태 코드 499가 표시됩니다.
상태 코드 499를 보여주는 샘플 NGINX 로그 항목
위 예시에서 NGINX의 499 상태와 경과된 총 시간은 50.001초입니다. 이는 클라이언트가 50.001초 후에 타임아웃되었음을 나타냅니다.

이 경우 메시지 프로세서 로그 (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>

라우터가 제한 시간을 초과하면 메시지 프로세서와의 연결을 닫습니다. 메시지 프로세서가 처리를 완료하면 라우터에 응답을 쓰려고 시도합니다. 라우터와의 연결이 이미 닫혀 있으므로 메시지 프로세서에서 Broken Pipe exception가 표시됩니다.
위에서 설명한 상황에서는 이 예외가 예상됩니다. 따라서 504 Gateway Timeout 오류의 실제 원인은 백엔드 서버가 응답하는 데 시간이 오래 걸리는 것이며 이 문제를 해결해야 합니다.

해상도

커스텀 백엔드 서버인 경우 다음을 수행합니다.

백엔드 서버를 확인하여 57초 이상 걸리는 이유를 파악하고 더 빠르게 응답하도록 수정/최적화할 수 있는지 확인합니다.

백엔드 서버를 수정/최적화할 수 없거나 백엔드 서버에 시간이 오래 걸릴 것으로 예상되는 경우 라우터 및 메시지 프로세서에서 제한 시간 값을 늘리세요.

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

클라이언트의 타임아웃 > 라우터의 타임아웃 > 메시지 프로세서의 타임아웃 > API 프록시 내 타임아웃

NodeJS 백엔드인 경우 다음을 실행합니다.
1. NodeJS 코드가 다른 백엔드 서버를 호출하는지, 반환하는 데 시간이 오래 걸리는지 확인합니다. 백엔드 서버에 시간이 오래 걸리는 이유를 확인합니다.
2. 메시지 프로세서의 CPU 또는 메모리 사용량이 높은지 확인합니다.
  1. 메시지 프로세서의 CPU 사용량이 높은 경우 다음 명령어를 사용하여 30초마다 스레드 덤프를 세 개 생성합니다.
```
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

라우터 머신에 /opt/apigee/customer/application/router.properties 파일이 아직 없으면 이 파일을 만듭니다.

이 파일에 다음 줄을 추가합니다.

conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

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

conf_load_balancing_load.balancing.driver.proxy.read.timeout=120

이 파일이 apigee 소유인지 확인합니다.

라우터를 다시 시작합니다.

/opt/apigee/apigee-service/bin/apigee-service edge-router restart

라우터가 두 대 이상인 경우 모든 라우터에서 위 단계를 반복합니다.

메시지 프로세서

메시지 프로세서 머신에 /opt/apigee/customer/application/message-processor.properties 파일을 만듭니다(아직 없는 경우).
이 파일에 다음 줄을 추가합니다.
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
예를 들어 제한 시간 값을 120초로 설정하려면 다음과 같이 설정합니다.
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

이 파일이 apigee에 의해 소유되는지 확인합니다.

chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

메시지 프로세서를 다시 시작합니다.

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

메시지 프로세서가 두 개 이상인 경우 모든 메시지 프로세서에서 위의 단계를 반복합니다.

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

클라이언트의 타임아웃 > 라우터의 타임아웃 > 메시지 프로세서의 타임아웃 > API 프록시 내 타임아웃

Edge에 의한 느린 API 요청 처리

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

진단

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

해상도

응답하는 데 시간이 오래 걸린 정책이 있는지, 처리하는 데 시간이 오래 걸릴 수 있는 맞춤 코드가 있는지 확인합니다. 이러한 코드가 있는 경우 식별된 코드를 수정/최적화할 수 있는지 확인합니다.
처리 시간을 늘릴 수 있는 맞춤 코드가 없다면 메시지 프로세서의 CPU 또는 메모리 사용량이 높은지 확인합니다.
1. 메시지 프로세서의 CPU 사용량이 높은 경우 다음 명령어를 사용하여 30초마다 스레드 덤프를 세 개 생성합니다.
```
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 모니터링을 사용하여 API의 5xx 문제를 해결하는 방법을 보여주는 샘플 시나리오를 단계별로 살펴봅니다. 예를 들어 504 상태 코드 수가 특정 기준을 초과할 때 알림을 받도록 설정할 수 있습니다.