nginx 504 Gateway Timeout Error

개요

한참전에 해결한 이슈이지만 정리할 시간이 없어 오랜만에 정리하게 됐다.

문제 상황은 다음과 같았다.

 

1. 특정 작업을 수행하는 A서버 API로 POST request

2. 비즈니스 로직 이후 AWS SQS를 활용해 배치 작업을 수행하는 Message를 전송

3. Worker(SQS Consumer)가 해당 Message를 수신받은 후 전처리 과정을 거친 이후 로직을 처리해야 할 B서버로 요청 전송

4. B서버로 요청을 보낸 Worker에서 axios에서 504 Gateway Timeout Error를 발생시키며 error response를 수신받음

5. 그러나 B서버에서는 해당 로직이 정상 수행됨

 

 

문제해결

우선 Timeout error를 뱉어내는 것을 확인한 후에 적용해 본 방법은 다음과 같았다.

 

 

1. axios request timeout 변경

추론해봤을 때 timeout은 관계없을 거 같았으나 우선 아주 간단한 수정만으로도 테스트 할 수 있었기 때문에 수정 적용 -> 실패

 

2. nginx 설정 변경

위에서 언급한 B서버 는 리버스 프록시로 구성돼있다. 따라서 네트워크 구조상 nginx에 문제가 있을 가능성이 존재했다.

의문스러웠던 것은 평소에 이상없이 동작하다가 갑자기 발생한 에러라는 것인데 이것도 역시 이유가 존재했다.

최근 운영 서버에 반영된 로직으로 인해 B서버에 수행해야 할 작업 시간이 늘어나다 보니 nginx의 default 시간을 초과한 것이다.

공식문서에 따르면 아래와 같다.

 

https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_send_timeout

Module ngx_http_proxy_module

 

따라서 nginx가 참조하고 있는 nginx.conf 파일을 수정하였다.

#nginx.conf

  server {
    listen 80;
    listen [::]:80;
    server_name ...

    location / {
	  ... # 이외의 설정들
      proxy_send_timeout 300s;
      proxy_read_timeout 300s;
      proxy_connect_timeout 300s;
      send_timeout 300s;
    }
  }

timout과 관련하여 비슷한 옵션이 많은데 이들 모두 작업의 최대 예상 시간인 5분 아래로 설정하였다.

공식 문서에 따르면 해당 timeout 정의 시간은 프록시 서버와 원본 요청의 중간 과정에서의 시간은 포함하지 않는다고 한다.
즉 예를 들면 위 상황에서 Worker가 SQS로 부터 소켓을 통해 메시지를 수신받은 것이 아닌 A서버로부터 요청을 받은 것이라고 가정한다면 request/response의 전송 순서는 A서버 -> Worker -> B서버 -> Worker -> A서버 의 순으로 진행될 것이다.

여기서 프록시 서버인 B서버와 Worker사이에만 해당 timeout이 적용되는 것이지 A서버와 B서버 전체의 요청에 대한 제한시간이 아님을 뜻한다.