이 페이지는 Cloud Translation API를 통해 번역되었습니다.

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"
       }
    }
}

게이트웨이 시간 초과의 원인은 무엇인가요?

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

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

다음 표에는 Edge에서 시간 초과가 발생할 수 있는 경우에 대한 자세한 내용이 나와 있습니다.

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

가능한 원인

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

원인	세부정보	다음에 주어진 걸음 수
느린 백엔드 서버	API 요청을 처리하는 백엔드 서버가 과도한 부하 또는 성능 저하로 인해 너무 느립니다.	퍼블릭 및 프라이빗 클라우드 사용자
에지의 느린 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 오류가 발생하여 응답하지 않았음을 보여주는 샘플 Trace를 제공합니다.

위 추적에서는 백엔드 서버가 응답하지 않아 55, 002밀리초 후에 메시지 프로세서가 타임아웃됩니다.

절차 #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 프록시에 적용됩니다. 예를 들어 io.timeout.millis가 API 프록시 내에서 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초입니다.

API 프록시 내에 설정된 120초보다 라우터의 시간 제한 값 (57초)이 낮으므로 백엔드 서버가 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초마다 스레드 덤프 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 오류가 발생할 수 있습니다. 이러한 상황은 다음과 같은 경우에 발생할 수 있습니다.

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

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

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

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

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

이렇게 하면 NGINX에서 클라이언트가 연결을 종료했음을 나타내는 상태 코드 499를 설정합니다.

진단

클라이언트 애플리케이션이 라우터에서 응답을 받기 전에 시간 초과되면 라우터와의 연결이 끊어집니다. 이 경우에는 특정 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초마다 스레드 덤프 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

라우터 머신에 /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

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

메시지 프로세서

메시지 프로세서 머신에 /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 프록시 시간 초과

에지의 느린 API 요청 처리

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

진단

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

해상도

응답하는 데 시간이 오래 걸린 정책이 있는지, 처리하는 데 시간이 오래 걸릴 수 있는 커스텀 코드가 있는지 확인합니다. 이러한 코드가 있으면 식별된 코드를 수정/최적화할 수 있는지 확인하세요.
처리 시간을 길게 유발할 수 있는 커스텀 코드가 없는 경우 메시지 프로세서의 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 모니터링을 사용하여 API의 5xx 문제를 해결하는 방법을 보여주는 샘플 시나리오를 단계별로 살펴보세요. 예를 들어 504 상태 코드 수가 특정 기준을 초과하면 알림을 받도록 알림을 설정할 수 있습니다.