beautifulsoups.dev
Published on

AWS VPC Reachability Analyzer로 502 추적하기

Authors

서버/앱 로그만 파다 보면 502는 끝이 없습니다. 특히 로드밸런서(ALB/NLB) → 타겟(EC2/ECS/EKS Pod) 구간에서 뜨는 502는, 애플리케이션이 아니라 VPC 네트워크 경로 단절로도 쉽게 발생합니다. 이 글에서는 AWS VPC Reachability Analyzer를 이용해 “진짜로 패킷이 도달 가능한가?”를 증명하고, 502 원인을 네트워크 레이어에서 빠르게 좁히는 실전 흐름을 정리합니다.

> 참고: ALB Ingress 환경에서의 502(타겟 리셋/헬스체크/타임아웃) 케이스는 아래 글도 함께 보면 좋습니다. > - EKS ALB Ingress 502 Target reset 원인과 해결

502를 네트워크로 의심해야 하는 시그널

다음 중 하나라도 해당하면 Reachability Analyzer가 특히 유효합니다.

  • 헬스체크는 가끔 실패하고, 재시도하면 살아남는다(간헐적)
  • 같은 서비스인데 AZ/서브넷에 따라 502 빈도가 다르다
  • 배포/인프라 변경(보안그룹, NACL, 라우팅, 엔드포인트, TG 포트 변경) 이후 발생
  • 애플리케이션 로그에는 뚜렷한 에러가 없고, LB 액세스 로그에 502/TargetConnectionError/Target.ResponseCodeMismatch 류가 보인다
  • 특정 경로(예: 프라이빗 서브넷→NAT→외부, 또는 VPC Endpoint)에서만 터진다

핵심은 이겁니다.

  • **502는 “LB가 타겟으로부터 정상 응답을 못 받았다”**는 결과일 뿐
  • 원인은 앱/OS/네트워크/보안정책 어디든 가능
  • Reachability Analyzer는 그중 **네트워크 경로(라우팅·SG·NACL·TGW·Endpoint)**를 “가능/불가능”으로 명확히 갈라줍니다

Reachability Analyzer가 해주는 것/못 해주는 것

해주는 것(강력)

  • 소스에서 목적지까지 네트워크 도달성을 분석
  • 다음을 종합해 “어디에서 막히는지”를 보여줌
    • Route Table
    • Security Group
    • NACL
    • IGW/NATGW
    • VPC Endpoint(Interface/Gateway)
    • Transit Gateway, Peering 등(구성에 따라)

못 해주는 것(오해 방지)

  • 애플리케이션 레벨(HTTP 502의 실제 응답 바디/예외) 분석
  • 커널/프로세스 레벨(리스닝 여부, conntrack 고갈, 파일 디스크립터 부족 등)
  • LB 자체의 타임아웃/재시도 정책으로 인한 502 판단

즉, Reachability Analyzer는 **“패킷이 갈 수 있나?”**를 증명하는 도구입니다. 502 원인을 좁히는 데 결정적이지만, 마지막 한 방은 로그/메트릭과 결합해야 합니다.

502 추적을 위한 표준 시나리오 3가지

Reachability Analyzer는 “소스/대상/프로토콜/포트”를 정해서 분석합니다. 502를 추적할 때는 보통 아래 3가지를 번갈아 확인합니다.

시나리오 A: ALB → 타겟(EC2/ECS/EKS 노드/Pod) 경로

  • 목적: LB가 타겟 포트로 붙을 수 있는지 검증
  • 체크 포인트: 타겟 보안그룹 인바운드, NACL, 서브넷 라우팅, 타겟 포트

시나리오 B: 타겟 → 외부 의존성(예: 결제 API, OAuth, S3)

  • 목적: 타겟이 외부로 나갈 때 막혀서 타임아웃→502로 번지는지 확인
  • 체크 포인트: NATGW 라우팅, NACL egress, VPC Endpoint 정책

시나리오 C: 타겟 → 내부 의존성(예: RDS/ElastiCache/내부 API)

  • 목적: 내부 호출 실패가 상위 요청 실패로 번지는지 확인
  • 체크 포인트: SG 상호 참조, 서브넷 간 라우팅, TGW/피어링

실전: Reachability Analyzer로 “ALB→Target” 분석하기

여기서는 가장 흔한 ALB가 타겟에 붙지 못해 502가 나는 케이스를 기준으로 흐름을 잡겠습니다.

1) 먼저 502가 “어디서” 발생하는지 확정

  • ALB 액세스 로그(또는 CloudWatch 지표)에서 502가 ELB가 반환한 것인지 확인
  • 타겟 응답코드가 아니라 elb_status_code=502 같은 형태라면, 타겟 연결/응답 문제일 가능성이 큽니다

추가로 EKS 환경이라면 Ingress/TargetGroup 이벤트도 확인하세요. (관련 케이스는 위 내부 링크 참고)

2) Reachability Analyzer에서 소스/대상 모델링

ALB는 “ENI(네트워크 인터페이스)”를 통해 트래픽을 내보냅니다. Reachability Analyzer는 보통 다음처럼 잡습니다.

  • Source: ALB가 붙어있는 서브넷의 ENI(혹은 ALB 자체가 선택지로 보이면 ALB)
  • Destination: 타겟(EC2 인스턴스 ENI, 또는 EKS 노드 ENI)
  • Protocol/Port: 타겟 그룹이 사용하는 포트(예: 80, 8080, 443)

EKS에서 Pod가 IP 타겟(awsvpc)인 경우에는 Pod IP를 직접 찍고 싶겠지만, Reachability Analyzer 입력이 제한될 수 있어 보통은 노드 ENI/보안그룹/서브넷 단에서 먼저 막힘을 확인합니다.

3) 결과에서 “막힌 지점”을 읽는 법

분석 결과는 대체로 다음 중 하나로 귀결됩니다.

  • Security group rule does not allow
    • 타겟 SG 인바운드에 ALB SG(또는 CIDR) 허용이 빠졌거나 포트가 다름
  • Network ACL rule does not allow
    • NACL이 ephemeral port(반환 트래픽) 또는 특정 포트를 막음
  • No route to destination / blackhole
    • 서브넷 라우팅 테이블이 잘못 연결(예: TGW/피어링/로컬 누락)
  • Destination is not reachable due to configuration
    • ENI/서브넷/AZ 불일치, 잘못된 대상 선택 등

여기서 중요한 팁:

  • 502는 “요청”이 아니라 “연결/응답” 문제이므로, **반환 트래픽(egress/ephemeral)**도 같이 봐야 합니다.
  • 특히 NACL은 Stateless라서 인바운드만 열어도 끝이 아닙니다.

가장 흔한 원인 Top 6와 빠른 처방

1) 타겟 보안그룹 인바운드에 ALB SG 누락

  • 증상: 특정 타겟만 unhealthy, 502 간헐적
  • 처방: 타겟 SG 인바운드에 source = ALB SG, port = target port 허용

예시(개념):

Target SG inbound:
- TCP 8080 from sg-ALB

2) NACL이 ephemeral port를 막아 응답이 못 돌아옴

  • 증상: “가끔” 되는 것처럼 보이는데 특정 플로우에서 실패
  • 처방: NACL egress/ingress에 ephemeral port 범위 허용(환경 표준에 맞게)

Linux 일반 범위 예(참고): 32768-60999 또는 1024-65535(조직 정책에 따름)

3) 타겟 그룹 포트/프로토콜 불일치

  • 증상: 앱은 8080 리슨인데 TG는 80, 또는 HTTP/HTTPS 혼선
  • 처방: TG 포트/프로토콜 정합성 점검, 헬스체크 경로/포트도 함께 확인

4) 라우팅 테이블/서브넷 연결 실수(특히 멀티 AZ)

  • 증상: 특정 AZ 타겟만 502
  • 처방: AZ별 서브넷 라우팅 테이블이 동일한지(또는 의도한지) 비교

5) PrivateLink(Interface Endpoint) 정책/SG로 내부 호출이 막혀 상위 요청이 502

  • 증상: 내부적으로 AWS API 호출/외부 호출 실패 → 앱 타임아웃 → LB에서 502
  • 처방: VPC Endpoint SG/정책, 라우팅, DNS(Private DNS) 확인

EKS에서 메타데이터(IMDS) 접근 문제가 섞여 있다면 아래 글도 맥락상 도움이 됩니다.

6) “네트워크는 통과”인데도 502면 OS/앱/타임아웃으로 이동

Reachability Analyzer가 OK인데 502가 난다면 다음으로 넘어가야 합니다.

  • 타겟 인스턴스에서 리스닝 확인 (ss -lntp)
  • 커넥션 리셋/타임아웃 로그
  • ALB idle timeout, backend keep-alive, Nginx/Envoy timeout
  • EKS라면 readiness/liveness, pod 재시작, 노드 리소스 압박

CLI로 재현 가능한 형태로 남기기(증거화)

콘솔에서 클릭으로 끝내면 다시 재현하기 어렵습니다. Reachability Analyzer는 CLI로도 경로 분석을 남길 수 있어, 변경 전/후 비교에 유용합니다.

아래는 “네트워크 인사이트 경로(Network Insights Path)”와 “분석(Network Insights Analysis)”를 만드는 예시입니다.

# 1) 경로 생성 (예: ALB ENI -> Target ENI, TCP 8080)
aws ec2 create-network-insights-path \
  --source eni-0abc1234def567890 \
  --destination eni-0123abcd4567efgh8 \
  --protocol tcp \
  --destination-port 8080 \
  --tag-specifications 'ResourceType=network-insights-path,Tags=[{Key=Name,Value=alb-to-target-8080}]'

# 출력으로 PathId를 확보했다고 가정
PATH_ID=nip-0a1b2c3d4e5f67890

# 2) 분석 실행
aws ec2 start-network-insights-analysis --network-insights-path-id $PATH_ID

# 3) 결과 조회
ANALYSIS_ID=nia-0a1b2c3d4e5f67890
aws ec2 describe-network-insights-analyses --network-insights-analysis-ids $ANALYSIS_ID

운영 팁:

  • 502가 특정 시간대/특정 AZ에서만 난다면, 그 AZ의 ALB ENI와 타겟 ENI 조합으로 각각 Path를 만들어 비교하세요.
  • 인프라 변경(PR/Change)마다 분석 결과(JSON)를 첨부하면, “네트워크는 문제 없음”을 빠르게 합의할 수 있습니다.

트러블슈팅 플레이북(체크리스트)

502가 발생했을 때, 아래 순서로 보면 보통 30분 안에 범위가 좁혀집니다.

  1. LB 로그/지표로 502의 주체 확정: ELB가 502를 만든 건지, 타겟이 502를 준 건지
  2. 타겟 헬스 상태/실패 사유 확인: unhealthy reason, health check port/path
  3. Reachability Analyzer로 ALB→타겟 경로 분석
    • SG 인바운드(타겟) / SG 아웃바운드(ALB)
    • NACL 양방향
    • 라우팅 테이블
  4. (필요 시) 타겟→의존성 경로 분석(NAT/Endpoint/내부망)
  5. Reachability OK면 OS/앱/타임아웃으로 이동

마무리: 502를 “감”이 아니라 “증명”으로 끝내기

502는 증상이 넓어서, 팀 간에 원인 공방이 생기기 쉽습니다. Reachability Analyzer의 가장 큰 가치는 “패킷이 갈 수 있냐/없냐”를 구성 기반으로 증명해준다는 점입니다.

  • Reachability에서 막히면: SG/NACL/Route/Endpoint를 고치면 된다
  • Reachability가 OK면: 이제 앱/노드/타임아웃/리소스 쪽으로 자신 있게 파고들면 된다

특히 멀티 AZ, EKS, PrivateLink, TGW처럼 네트워크 구성요소가 많아질수록 이 도구는 ‘시간 절약’ 수준이 아니라 ‘사고 방지’에 가깝습니다.

Discuss on Twitter • View on GitHub