[Nginx Keepalive 와 ALB Idle Timeout] 역할 차이!!

아래는 개념 → 동작 흐름 → 장애 원인 → 권장 설정 순서로 정리했습니다.

1️⃣ Nginx Keepalive란 정확히 무엇인가?
한 줄 정의
Nginx가 Upstream(백엔드/ALB)과의 TCP 연결을 끊지 않고 재사용하기 위한 기능
🔹 Keepalive가 없을 때 (매 요청마다 연결)
코드 복사

Client → Nginx → (TCP 연결 생성) → ALB/WAS
                     ↑
                응답 후 연결 종료
❌ 단점
TCP Handshake 반복
SSL 사용 시 비용 큼
트래픽 많으면 CPU 급증
🔹 Keepalive가 있을 때 (연결 재사용)
코드 복사

Client → Nginx → (기존 TCP 연결 재사용) → ALB/WAS

✅ 장점
지연시간 감소
CPU/네트워크 비용 절감
고성능 처리 가능
🔹 Nginx Keepalive가 관리하는 대상
중요 포인트
👉 Client ↔ Nginx 가 아니라
👉 Nginx ↔ Upstream(ALB/WAS) 연결 관리
코드 복사
Nginx
upstream api_backend {
    server backend1:8080;
    keepalive 32;   # 유지할 커넥션 수
}

2️⃣ ALB Idle Timeout이란?
한 줄 정의
ALB가 “아무 트래픽 없는 TCP 연결을 언제까지 유지할 것인가”를 결정하는 시간
🔹 ALB 기본값
60초
코드 복사

Nginx ──────(요청 없음 60초)──────> ALB
                  ↑
             ALB가 연결 강제 종료
⚠ 문제는 ALB가 조용히 끊는다는 점입니다.

3️⃣ Keepalive + ALB Idle Timeout 충돌 구조
🔥 장애가 발생하는 정확한 흐름
코드 복사

1️⃣ Nginx가 ALB와 keepalive 연결 생성
2️⃣ 일정 시간 동안 요청 없음
3️⃣ ALB Idle Timeout(60초) 초과
   → ALB가 TCP 연결 종료
4️⃣ Nginx는 연결이 살아있다고 "착각"
5️⃣ 같은 연결로 새 요청 전송
6️⃣ ALB는 다른 연결로 응답
7️⃣ Nginx:
   "wrong ident 응답이다!"
📌 이때 나오는 로그가 바로:
코드 복사

wrong ident xxxx response ... expect yyyy

4️⃣ 왜 이게 Nginx 장애로 보일까?
요청은 정상 전송
응답은 존재
단지 “요청–응답 매칭이 깨짐”
➡ Nginx는 안전을 위해
해당 요청 실패 처리
커넥션 폐기
경우에 따라 502/504 발생

5️⃣ 핵심 원칙 (아주 중요)
✅ Nginx Keepalive Timeout < ALB Idle Timeout
이유
ALB보다 Nginx가 먼저 연결을 정리해야 안전
그래야 “죽은 연결 재사용”이 없음

6️⃣ 권장 설정 조합 (운영 표준)
🔧 ALB 설정
항목
값
Idle Timeout
60초 (또는 120초)
🔧 Nginx 설정 (권장)
코드 복사
Nginx
upstream api_backend {
    server internal-xxx-alb.amazonaws.com:80;
    keepalive 32;
}

proxy_http_version 1.1;
proxy_set_header Connection "";
keepalive_timeout 30s;   # ALB보다 반드시 짧게
추천 조합 예시
ALB
Nginx
60초
30초
120초
60초

7️⃣ 트래픽 패턴별 추천 전략
🔹 트래픽 많음 (고성능)
Keepalive ON
Timeout 엄격하게 관리
🔹 트래픽 적음 / 안정성 최우선
코드 복사
Nginx
proxy_set_header Connection "close";
➡ Keepalive OFF (가장 안전)

8️⃣ 한 줄로 정리 (면접·보고서용)
Nginx Keepalive는 백엔드와의 연결 성능을 높이기 위한 기능이지만,
ALB Idle Timeout보다 길게 유지될 경우 이미 종료된 연결을 재사용하면서
요청–응답 불일치(wrong ident) 장애가 발생할 수 있다.