504 Gateway TimeOut시 호출된 로직은?

개요

최근 작업을 하면서 504 Gateway TimeOut이 발생했고, 이에 따라 처음에는 서버 로직이 중단되었을 것이라 생각했으나 실제로는 그렇지 않았다. 어찌 보면 504는 서버(자세히는 WAS)에서 뱉은 오류가 아니기 때문에 당연한 말이지만 무심코 5xx 에러라 요청된 서버 로직도 중단될 줄 알았다. 그래서 504 Gateway TimeOut에 대해 다시 알아볼 겸 정리하게 되었다.

브라우저에서의 504 오류 화면

Postman에서의 504 오류 화면

 
 
 

게이트웨이란 무엇인가?

게이트웨이는 통신 분야에서 서로 다른 네트워크를 연결을 하는 중개자 역할을 한다. 이를 통해 다른 통신 프로토콜이나 데이터 형식을 가진 네트워크 간의 소통이 가능해진다.

아래는 Nginx를 사용한 Gateway 구성에 대한 설명이다. Nginx는 웹 서버로 널리 알려져 있지만, 리버스 프록시 또는 게이트웨이로도 널리 사용된다. 리버스 프록시는 클라이언트의 요청을 받아 원본 서버로 전달하고, 원본 서버의 응답을 클라이언트에게 다시 전달하는 역할을 한다.(Nginx 예시를 가져온 이유는 대부분이 리버스 프록시로 Nginx를 사용하기 때문이다.)

Nginx를 사용한 Gateway 구성도

일반적으로 'upstream'은 원본 서버, 즉 WAS(Web Application Server)를 지칭한다. 위 이미지에서 Nginx는 'downstream'으로 분류될 수 있으며, 리버스 프록시 역할을 한다.

504 Gateway Time-out 오류는 이 리버스 프록시와 원본 서버(upstream) 간의 통신 시간이 지정된 한계를 초과했을 때 발생한다. 
 
 

504 오류의 주요 원인

• connetct_timeout(default: 60s)
  • 주로 upstream 연결 지연으로 발생한다. 대부분의 upstream은 가까운 위치에 있어 자주 발생하지 않으나, 방화벽에 의해 proxy 연결이 차단될 경우 발생할 수 있다.
  • 연결은 TCP/IP의 3-way handshake로 이루어지며, 지정된 시간 내에 SYN+ACK 응답을 받지 못하면 오류가 발생한다.
• send_timeout(default: 60s)
  • 데이터 전송 지연 시 발생한다. 대표적으로, 사용자가 대용량 파일 업로드 중 속도 저하로 인해 발생할 수 있다.
• read_timeout(default: 60s)
  • upstream에서의 응답이 지연되면 이 오류가 발생한다. 백엔드 서버에서 복잡한 작업을 수행하거나, 다른 이유로 인해 응답이 지연되는 경우가 대부분이다.
  • 참고로 여기서 중요한 점은 클라이언트가 504 오류를 반환받더라도 요청은 이미 전송된 상태이므로, 리버스 프록시가 연결을 끊어도 upstream 작업은 계속 수행된다.

public class BackendProcess {
    public static void main(String[] args) {
        for (int i = 1; i <= 10; i++) {
            try {
                System.out.println("Processing: " + i);
                Thread.sleep(1000);  // 1초 대기
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        System.out.println("Processing completed.");
    }
}

위 코드는 반복마다 1초 동안 대기하며, 10번 반복문이 수행되고, 이론상 여러 변수를 제외하고 전체 작업 시간이 10초가 걸리는 코드이다. 만약 리버스 프록시의 read_timeout 설정이 5초라고 가정했을 때, 5초가 지나면서 클라이언트는 504 Gateway Timeout 오류를 받게 되며 연결이 끊기지만, 백엔드 작업은 중단되지 않고 계속해서 진행되며 10번의 "Processing" 메시지가 출력되고 마지막으로 "Processing completed." 메시지가 출력된다.
 
 

알아두면 좋은 내용

서비스 앞단에 AWS ELB나 CloudFlare와 같은 서비스가 위치했을 수도 있다.

• CloudFlare
  • Connection_timeout은 15초로 설정되어 있으며, 이를 초과하면 Error 522: connection timed out이 발생한다.
  • read_timeout은 기본적으로 100초로 설정되어 있으나, Enterprise Plan에서는 최대 600초까지 설정할 수 있다.
• AWS ELB(Elastic Load Balancer)
  • AWS ELB에서는 send_timeout과 read_timeout이 기본적으로 60초로 설정되어 있다.
  • 하지만 사용자가 원한다면 1~3600초 사이에서 원하는 값으로 설정할 수 있다.

https://aws.amazon.com/ko/blogs/aws/elb-idle-timeout-control/

https://aws.amazon.com/ko/blogs/aws/elb-idle-timeout-control/