lander.log

AWS ALB Timeouts

5 min read

AWS ALB Timeouts

1. 정의 (Definition)

AWS ALB Timeouts는 로드 밸런서(ALB)가 클라이언트 및 타겟(백엔드)과의 연결을 유지하거나 끊는 시점을 결정하는 시간 제한 설정입니다. 크게 Connection Timeout과 Idle Timeout으로 나뉩니다.

2. 등장 배경 (Problem Context)

  • 문제: 네트워크 연결은 무한히 유지될 수 없습니다. 불필요하게 열려 있는 연결은 리소스(포트, 메모리)를 낭비하며, 응답 없는 서버를 무작정 기다리는 것은 사용자 경험을 해칩니다.
  • 해결: ALB는 명시적인 타이머를 두어, “이 시간 동안 아무 일도 없으면 끊겠다(Idle)” 또는 “이 시간 안에 연결이 안 되면 포기하겠다(Connection)“는 규칙을 적용합니다.

3. 핵심 메커니즘 (How it Works)

3.1. Connection Timeout (연결 타임아웃)

  • 값: 10초 (고정값, 변경 불가)
  • 동작: ALB가 백엔드 타겟(EC2, Pod)과 TCP 3-way handshake를 시도할 때, 10초 안에 완료되지 않으면 포기하고 504 Gateway Timeout을 반환합니다.
  • 주원인: Security Group 차단, NACL 차단, 백엔드 서버 부하로 인한 Accept 지연.

3.2. Idle Timeout (유휴 타임아웃)

  • 값: 기본 60초 (1~4000초 변경 가능)
  • 동작: 연결이 맺어진 후, 요청이나 응답 데이터가 오고 가지 않는 상태(Idle) 가 설정된 시간을 초과하면 ALB가 연결을 끊습니다.
    • 클라이언트가 요청을 다 보내고 응답을 기다리는 시간도 Idle로 간주됩니다. (백엔드 처리 시간 포함)
  • 주원인: 백엔드의 느린 쿼리, 긴 파일 업로드, 애플리케이션 데드락.

4. 불변 조건과 보장 범위 (Invariants & Guarantees)

  • Connection Timeout 불변: 사용자가 Connection Timeout을 늘릴 수 없습니다. 10초 안에 연결이 안 되면 무조건 실패입니다.
  • Keep-Alive 의존성: Idle Timeout 내에 트래픽이 있으면 연결은 유지됩니다. 단, 백엔드 애플리케이션의 Keep-Alive Timeout이 ALB보다 짧으면, 백엔드가 먼저 연결을 끊어버려 502 Bad Gateway가 발생할 수 있습니다.

5. 비유 (Analogy)

전화 통화에 비유할 수 있습니다.

  • Connection Timeout (10초): 전화를 걸었는데 상대방이 10초 동안 신호만 가고 받지 않으면 “연결 실패”로 간주하고 끊습니다.
  • Idle Timeout (60초): 통화가 연결되었습니다. 하지만 둘 다 60초 동안 아무 말도 안 하고 침묵하면, 통신사가 “통화 끝난 건가?” 하고 전화를 끊어버립니다.

6. 실무적 함의 (Operational Implications)

  • 504 발생 시 구분:
    • 즉시(혹은 10초 내) 발생? → 네트워크/방화벽(Connection Timeout) 문제일 가능성 높음.
    • 60초(설정값) 꽉 채우고 발생? → 애플리케이션 처리 지연(Idle Timeout) 문제일 가능성 높음.
  • 설정 원칙: 백엔드(Node.js/Nginx)의 Keep-Alive Timeout은 항상 ALB Idle Timeout보다 길게 설정해야 합니다. (ALB가 살아있다고 생각한 연결을 백엔드가 끊는 것을 방지)

7. 주의사항 / 오해 (Pitfalls & Misconceptions)

  • “Timeout 늘리면 해결된다?”: Idle Timeout을 4000초로 늘리면 504는 줄겠지만, 클라이언트는 하염없이 기다려야 합니다. 근본적인 성능 튜닝이 우선입니다.
  • “Connection Timeout을 늘리고 싶어요”: 불가능합니다. 네트워크 경로와 보안 그룹을 점검해야 합니다.

8. References

References

Recent Posts