ALB(로드밸런서) 502/504 오류 실전 대응법

작성자:

AWS Application Load Balancer(ALB)에서 발생하는 502 Bad Gateway와 504 Gateway Timeout 오류는 사용자가 서버에 정상적으로 접속하지 못하고 있음을 나타내는 대표적인 장애 코드입니다.
이 두 오류는 단순한 HTTP 상태 코드 이상으로, ALB와 백엔드 서버(타겟) 간의 통신 상태를 직접적으로 반영하므로, 서비스 가용성(SLA)에 심각한 영향을 미칩니다.

1. 오류 정의 및 의미

오류 코드의미주요 발생 지점
502 Bad GatewayALB가 백엔드 서버로부터 유효하지 않은 응답을 받았거나, 연결 자체가 실패한 경우ALB ↔ 타겟 간 프로토콜 오류, 타겟 다운, 잘못된 응답 형식
504 Gateway TimeoutALB가 설정된 타임아웃 시간 내에 타겟으로부터 응답을 받지 못한 경우타겟 처리 지연, 네트워크 지연, 타겟 다운, 과부하

공통점: 둘 다 ALB는 정상이지만, 타겟 측에 문제가 있음을 의미합니다.
차이점: 502는 “응답은 왔지만 비정상”, 504는 “응답이 아예 안 옴”.

2. 체계적인 점검 순서 (실무 체크리스트)

신속한 원인 파악을 위해 다음 순서로 점검하세요.
각 단계는 콘솔 → 로그 → 메트릭 → 테스트 순으로 진행합니다.

Step 1: ALB 상태 확인 (콘솔)
  • ALB → Target Groups → Health Check
  • 타겟 상태: Healthy / Unhealthy / Draining
  • Unhealthy 비율이 높으면 즉시 타겟 문제 의심
  • Health Check 설정 확인
  • Path, Port, Protocol, Threshold, Interval, Timeout
  • 예: /health 엔드포인트가 200 OK를 반환하는지?

실전 팁: Health Check가 실패하면 502/504의 1차 원인입니다.

Step 2: 타겟 인스턴스 상태 확인
  • EC2 / ECS / Lambda 상태
  • 인스턴스 중지/재부팅 여부
  • CPU, 메모리, 디스크 사용률 (CloudWatch)
  • ECS 태스크 실패 로그, Lambda 타임아웃
  • 보안 그룹 / 네트워크 ACL
  • ALB → 타겟 포트 (예: 8080) 인바운드 허용 여부
  • VPC Flow Logs
  • REJECT 로그가 있는지 확인 (보안 그룹 차단)
Step 3: 로그 분석
로그 위치확인 포인트
ALB Access Logs (S3)elb_status_code=502, target_status_code, target_processing_time
타겟 애플리케이션 로그500 에러, 예외, DB 연결 실패, 무한 루프
CloudWatch LogsECS/Fargate: 컨테이너 로그, Lambda: REPORT Duration

핵심 지표

  • target_processing_time > timeout → 504
  • target_status_code=5xx 또는 - → 502
Step 4: 네트워크 & 타임아웃 설정 점검
  • ALB 타임아웃 설정
  • Idle Timeout: 기본 60초 (클라이언트 ↔ ALB)
  • Target Response Timeout: 기본 60초 (ALB ↔ 타겟)
    • 필요 시 aws elbv2 modify-load-balancer-attributes로 조정
  • Keep-Alive 설정
  • 타겟이 HTTP Keep-Alive를 끊고 있으면 502 유발 가능
Step 5: 직접 테스트 (curl / Postman)
# ALB DNS 직접 호출
curl -v https://your-alb-dns.com/health

# 타겟 IP 직접 호출 (보안 그룹 허용 필요)
curl -v http://10.0.1.100:8080/health
  • ALB 호출 → 502/504
  • 타겟 직접 호출 → 200 OK
    → ALB-타겟 간 연결 문제 (보안 그룹, 라우팅, 타겟 다운)

3. 실전 대응 예시

상황대응
Health Check 실패/health 엔드포인트 응답 확인 → 코드 수정 → 재배포
CPU 100%Auto Scaling 트리거 확인 → 스케일 아웃
DB 연결 풀 고갈Connection Pool 사이즈 조정, Slow Query 점검
504 지속타겟 타임아웃 증가 + 애플리케이션 최적화

4. 예방 조치 (장기적 안정화)

  1. Health Check 최적화
  • 간단한 정적 엔드포인트 (/health) 사용
  • DB 의존성 제거 (가능하면)
  1. CloudWatch 알람 설정
  • HTTPCode_Target_5XX_Count > 0
  • TargetResponseTime > 30s
  • UnHealthyHostCount > 0
  1. Auto Scaling + ALB 연동
  • 최소 Healthy 타겟 수 유지
  1. Circuit Breaker 패턴 도입 (선택)
  • 타겟 장애 시 빠른 503 반환
  1. WAF + Rate Limiting
  • DDoS 유사 공격으로 인한 타겟 과부하 방지

5. 요약: 502/504 대응 플로우차트 (텍스트 버전)

[502/504 발생]
     ↓
[ALB Health Check 확인] → Unhealthy?
     ↓ Yes                    ↓ No
[타겟 상태 점검]         [ALB Access Log 분석]
     ↓                       ↓
[EC2/ECS/Lambda]       [target_status_code?]
     ↓                       ↓
[로그/메트릭]           [5xx? → 애플리케이션 오류]
     ↓                   [ - ? → 네트워크/타임아웃]
[네트워크 테스트]             ↓
     ↓                  [타임아웃 증가 or 코드 최적화]
[직접 curl 테스트]
     ↓
[원인 특정 → 조치 → 모니터링]

ENA 드라이버의 역할과 문제 발생 원리

ENA(Elastic Network Adapter)는 AWS가 개발한 고성능 네트워크 인터페이스로, EC2 인스턴스에서 낮은 지연 시간과 높은 처리량(Throughput)을 제공하는 핵심 기술입니다. ENA가 제대로 작동하지 않으면, 인스턴스의 CPU는 작업을 처리할 준비가 되어 있지만 네트워크 패킷이 지연되거나 손실되어 애플리케이션 지연이 발생합니다.

1. 드라이버 버그로 인한 패킷 처리 지연

특정 운영체제(주로 오래된 Linux 커널 버전 또는 일부 윈도우 서버 버전)에서 사용되는 ENA 드라이버 버전에 메모리 관리 또는 패킷 큐 처리 로직 버그가 존재할 수 있습니다.

  • 증상: 인스턴스가 네트워크로부터 패킷을 수신할 때, 드라이버가 패킷을 처리하는 과정(인터럽트 처리, 커널로 데이터 복사 등)에서 불필요한 지연이 발생합니다.
  • 결과: 애플리케이션은 정상적으로 실행되지만, 외부와의 데이터 통신(DB 쿼리 응답, API 요청 응답 등)이 지연되어 전체적인 응답 시간(RTT)이 길어집니다. vmstat이나 top을 확인하면 CPU는 놀고 있지만, 실제 서비스는 느려지는 현상이 관찰됩니다.

2. 특정 인스턴스 타입과의 비호환성 사례

ENA 드라이버 버그는 특히 새로운 인스턴스 패밀리나 특정 고성능 인스턴스 타입에서 발견되는 경우가 있었습니다. 예를 들어, 메모리 최적화 인스턴스(R 시리즈)나 컴퓨팅 최적화 인스턴스(C 시리즈)의 최신 세대(예: R6i, C6i)는 기존 ENA 드라이버가 예상하지 못한 하드웨어 특성(PCIe 밴드위스, NUMA 구조 등)을 가질 수 있습니다.

  • 사례: 구형 ENA 드라이버를 탑재한 인스턴스를 새로운 세대의 하드웨어로 마이그레이션했을 때, 드라이버가 해당 인스턴스 타입의 네트워크 인터페이스를 효율적으로 활용하지 못하고 네트워크 인터럽트(IRQ) 처리 병목 현상을 유발하는 경우가 있었습니다.

진단법: 네트워크 인터페이스 문제의 격리

CPU 사용률은 낮은데 지연이 심하다면, 문제를 ENA 드라이버와 네트워크 설정으로 격리해야 합니다.

1. ENA 드라이버 버전 확인 및 업데이트

가장 먼저 취해야 할 조치는 현재 인스턴스에 설치된 ENA 드라이버의 버전을 확인하고, AWS가 권장하는 최신 버전으로 업데이트하는 것입니다.

  • 버전 확인: Linux 인스턴스에서는 ethtool -i eth0 명령어를 사용하여 드라이버 이름(driver)과 버전(version)을 확인할 수 있습니다.
  • 업데이트: AWS는 ENA 드라이버 버그를 지속적으로 패치하여 배포합니다. 최신 Amazon Linux AMI나 커널을 사용하거나, AWS의 EBS Backed AMI를 통해 인스턴스를 업데이트하는 것이 안전합니다.

2. 네트워크 지표 (CloudWatch) 심층 분석

CloudWatch를 통해 인스턴스의 기본적인 CPU 지표 외에 네트워크 관련 지표를 상세히 확인해야 합니다.

  • NetworkPacketsIn / NetworkPacketsOut: 패킷 처리량이 평소와 비슷한지 확인합니다. 처리량은 정상인데 지연만 높다면 드라이버 문제입니다.
  • NetworkInterfaceErrors: 네트워크 인터페이스에서 오류(Drop, Error)가 발생하고 있는지 확인합니다. 오류가 높다면 드라이버가 패킷을 제대로 처리하지 못하고 있음을 시사합니다.

3. 내부 시스템 로그 및 OS 튜닝 확인

인스턴스 내부에서 ENA 드라이버 관련 로그를 확인하고 네트워크 설정을 튜닝해야 합니다.

  • dmesg 로그 확인: Linux 커널 메시지(dmesg)에서 ENA 드라이버 관련 경고나 에러 메시지(예: Ring Buffer Overflow, TSO 관련 경고)가 있는지 확인합니다.
  • RSS(Receive Side Scaling) 설정: 고성능 인스턴스의 경우, ENA 드라이버가 여러 CPU 코어에 걸쳐 네트워크 인터럽트 처리를 분산(RSS)하도록 설정해야 합니다. RSS가 비활성화되어 있거나 잘못 설정되면 하나의 CPU 코어에 부하가 집중되어 지연이 발생할 수 있습니다.
  • 네트워크 버퍼 크기: OS의 네트워크 버퍼(TCP/IP 윈도우 크기)가 너무 작게 설정되어 있으면 패킷 손실 및 재전송이 발생하여 지연이 늘어날 수 있습니다.

ENA 문제 진단은 시스템의 기본으로 돌아가기

서버의 CPU는 낮은데 지연이 심한 상황은 애플리케이션 개발자가 아닌 인프라 엔지니어의 영역에 속하는 문제입니다. 이러한 문제는 대부분 네트워크 드라이버의 안정성과 하드웨어/소프트웨어 간의 비호환성에서 비롯됩니다.

가장 실질적인 해결책은 최신 ENA 드라이버를 유지하고, EC2 인스턴스 상태 검사(System/Instance Status Check) 및 CloudWatch 네트워크 지표를 상시 모니터링하는 것입니다. 특히, 인스턴스 패밀리를 변경하거나 OS 커널을 업데이트할 때마다 ENA 드라이버의 호환성 리스트를 확인하고 최신 버전으로 업데이트하는 절차를 표준 운영 절차(SOP)에 포함해야 합니다.

Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.