AWS ALB 502 Bad Gateway 에러 완벽 해결: 타임아웃 최적화 아키텍처
[Troubleshooting] AWS ALB 502 Bad Gateway 에러 완벽 해결: 타임아웃 최적화 아키텍처
"트래픽 분산을 위해 AWS ALB(Application Load Balancer)를 Node.js 백엔드 앞에 붙여두었습니다. 그런데 평소엔 잘 되다가 유저가 늘어날 때 간헐적으로 502 Bad Gateway 에러가 터지며, 백엔드 서버에는 아예 에러 로그조차 찍히지 않습니다."
클라우드 환경에서 로드밸런서를 도입한 백엔드 및 인프라 엔지니어들이 지옥을 맛보게 되는 미스터리한 간헐적 에러입니다. 분명 서버는 쌩쌩하게 살아있고 리소스도 여유로운데 502 에러가 사용자 화면을 덮칩니다.
초보자들은 502 에러를 보면 서버 사양을 높이거나 컨테이너를 재시작하는 헛수고를 반복합니다. 이 에러는 서버가 죽은 것이 아니라, ALB와 백엔드 서버 간의 '연결 유지 시간(Keep-Alive Timeout)' 설정이 엇갈려 발생한 끔찍한 오해입니다. 본 가이드에서는 AWS의 물리적 네트워크 시간 개념을 해체하고, 무결점 통신을 보장하는 타임아웃 동기화 아키텍처를 단호하게 제시합니다.
📌 이 글의 핵심 포인트
- 에러의 본질: ALB가 연결된 파이프(TCP)로 데이터를 보내려는 찰나, 백엔드 서버가 먼저 파이프를 끊어버려 발생하는 통신 충돌
- Idle Timeout의 불균형: ALB의 기본 유휴 타임아웃(60초)과 Node.js/Spring Boot의 기본 Keep-Alive 타임아웃(5초)의 치명적 차이
- 완벽한 아키텍처: 타겟 그룹 서버의 Keep-Alive 유지 시간을 ALB 설정 시간보다 무조건 길게 세팅하는 역전 방어 로직
1단계: 핵심 원인 분석 - 먼저 전화를 끊어버린 백엔드
ALB는 트래픽 효율을 높이기 위해 클라이언트의 요청이 끝났다고 매번 네트워크 선을 자르지 않고, 다음 요청을 위해 선을 60초(기본값) 동안 열어둡니다(Idle Timeout).
그런데 ALB 뒤에 있는 Node.js 서버는 기본적으로 5초(버전에 따라 상이) 동안만 요청이 없으면 냉정하게 스스로 네트워크 선을 끊어버립니다(Keep-Alive Timeout).
자, 5초 동안 요청이 없어서 Node.js가 방금 막 선을 뽑으려는 찰나에, ALB가 새로운 유저의 요청을 받아 이 선을 통해 데이터를 쐈다고 가정해 봅시다. 데이터는 허공으로 튕겨 나가고, 당황한 ALB는 클라이언트에게 "백엔드 놈이 갑자기 문을 닫아버렸어! (502 Bad Gateway)"라고 에러를 던지게 되는 것입니다.
2단계: 완벽한 트러블슈팅 - 타임아웃 역전 아키텍처
해결책은 수학적으로 매우 명확합니다. [백엔드의 Keep-Alive 타임아웃 시간 > ALB의 Idle 타임아웃 시간] 공식을 무조건 성립시켜야 합니다.
AWS ALB의 기본 유휴 제한 시간이 60초이므로, 백엔드 애플리케이션 코드를 수정하여 타임아웃 시간을 여유롭게 65초 이상으로 늘려주어야 ALB가 안전하게 트래픽을 중계할 수 있습니다.
// 🛠️ Node.js (Express) 기반 완벽한 타임아웃 동기화 아키텍처
const express = require('express');
const app = express();
const server = app.listen(8080, () => {
console.log("Server running on port 8080");
});
// 핵심 트러블슈팅: 백엔드의 Keep-Alive 타임아웃을 65초(65000ms)로 연장
// ALB의 기본 60초 설정보다 길게 설정하여 502 에러 원천 차단
server.keepAliveTimeout = 65000;
server.headersTimeout = 66000;
(만약 Spring Boot(Tomcat)를 사용한다면 application.yml 파일에 server.tomcat.keep-alive-timeout: 65000을 추가하십시오.)
🙋♂️ 자주 묻는 질문 (FAQ)
Q. 백엔드 타임아웃을 건드리지 않고, AWS ALB의 Idle Timeout 시간을 4초로 확 줄여버리면 안 되나요?
A. 가능은 하지만 추천하지 않습니다. ALB의 타임아웃을 4초로 줄이면, 유저가 무거운 파일을 업로드하거나 다운로드하느라 5초 이상 틈이 생겼을 때 ALB가 가차 없이 연결을 끊어버려서 서비스 품질(UX)이 심각하게 망가집니다. 로드밸런서의 여유 시간은 넉넉하게 두고 애플리케이션이 이에 맞추는 것이 인프라 엔지니어링의 정석입니다.
💡 핵심 정리 및 마무리
502 Bad Gateway는 코드가 틀렸다는 경고가 아니라, 인프라 계층(L7)의 컴포넌트들이 서로 다른 '시간의 시계'를 가지고 있다는 네트워크의 아우성입니다. 로드밸런서와 백엔드 서버 간의 물리적 TCP 연결 메커니즘을 꿰뚫어 보고, 타임아웃의 엇갈림을 동기화하여 그 어떤 스파이크 트래픽 앞에서도 에러 없이 굴러가는 견고한 클라우드 아키텍처를 완성하시기 바랍니다.
댓글
댓글 쓰기