Junggi Kim

Junggi Kim

3 minute read

배경 및 상황

운영 서버 마이그레이션 작업 직후

  • Wi-Fi로 접속 시 화면 데이터 정상 노출
  • 동일 화면을 모바일 데이터(LTE/5G)로 호출하면 데이터 미노출 또는 오류
    • 일부 사용자는 Wi-Fi/모바일 데이터 모두 정상
    • 일부 사용자는 Wi-Fi에서만 정상, 모바일 데이터에서는 항상 실패
    • 개발/스테이징 환경에서는 같은 문제가 재현되지 않음
    • 최근에 대규모 인프라 구조 변경이나 네트워크 정책 변경은 없음

즉, 특정 네트워크 환경(모바일 데이터)에서만 발생하는 API 장애였고,

증상이 사용자별·환경별로 섞여 있어 초기 파악이 어려운 상태였다.

증상 정리

문제 도메인을 예시로 api.myservice.com이라고 하면, 증상은 다음과 같았다.

구분 Wi-Fi 모바일 데이터(LTE/5G)
API 응답 정상 일부 계정/단말에서 실패

서버 쪽 모니터링 지표를 확인했을 때:

  • ECS 컨테이너 상태: 모두 healthy
  • ALB 타깃 그룹 헬스 체크: 정상
  • 애플리케이션 로그: 서버 내부에서 발생한 에러 로그 없음
  • VPC, 서브넷, 라우팅, 보안 그룹: 최근 변경 사항 없음

인프라 전반은 정상으로 보였고,

문제는 클라이언트 네트워크 종류에 따라 다르게 나타난다는 점이 특징이었다.

1차 점검 – 인프라 레이어

먼저 확인한 항목들은 다음과 같다.

  • VPC 설정
    • CIDR, 라우팅 테이블, 서브넷 구성에 이상 없음
  • ALB 보안 그룹
    • 80/443 포트에 대해 0.0.0.0/0 허용
  • NACL
    • Inbound/Outbound 기본 허용 상태
  • ECS 서비스
    • 연결된 타깃 그룹 헬스 체크 정상
    • 컨테이너 리소스 상태 정상

이 단계까지의 결론:

VPC -> ALB -> ECS로 이어지는 기본 인프라에는 명확한 문제를 찾지 못했다.

따라서 DNS/네트워크 경로 혹은 L7 레벨 라우팅 쪽을 확인해봐야겠다는 생각이 들었다.

DNS 레코드 확인 – A vs AAAA

문제 도메인 api.myservice.com의 DNS 레코드를 확인했다.

api.myservice.com.  A     -> myservice-prod-alb-123456.ap-northeast-2.elb.amazonaws.com
api.myservice.com.  AAAA  -> d1abcd2xyz3w.cloudfront.net
  • A 레코드 (IPv4)
    • 대상: ALB 도메인 (예: myservice-prod-alb-…elb.amazonaws.com)
    • 효과: 클라이언트가 IPv4로 접속하는 경우 ALB에 직접 연결
  • AAAA 레코드 (IPv6)
    • 대상: CloudFront 도메인 (예: d1abcd2xyz3w.cloudfront.net)
    • 효과: 클라이언트가 IPv6를 사용할 때 CloudFront를 경유

즉, 같은 도메인(api.myservice.com)이라도:

  • IPv4 경로: 클라이언트 → ALB → ECS
  • IPv6 경로: 클라이언트 → CloudFront → ALB → ECS

완전히 다른 라우팅 경로를 가지는 상태였습니다.

원인 분석 결과, A/AAAA 분기 정책이 경로에 반영된 상태였습니다.

IPv4/IPv6와 A/AAAA 레코드 간단 정리

IPv4 vs IPv6

  • IPv4
    • 예: 192.168.0.1
    • 대부분의 기존 시스템, 사내망, 많은 Wi-Fi 환경에서 기본으로 사용
  • IPv6
    • 예: 2001:db8:abcd:0012::1
    • 주소 공간이 매우 넓음
    • 국내외 모바일 통신사(특히 LTE/5G)에서 적극 도입/운영 중

클라이언트(스마트폰 OS, 네트워크 스택)는 보통 다음과 같이 동작한다.

DNS에서 A, AAAA 레코드를 모두 조회 네트워크와 OS에 따라 A/AAAA 응답을 받은 뒤 Happy Eyeballs 같은 알고리즘으로 IPv6을 약간 우대하면서도, 둘 중 더 빨리 연결되는 쪽을 선택한다.

Happy Eyeballs

Happy Eyeballs는 RFC 6555(v1, 2012: IPv6 우대 조회 기본) / RFC 8305(v2, 2018: 지연+폴백 개선)에서 정의한 알고리즘으로, 현대 브라우저·모바일 OS가 IPv6을 약간 우선 시도하되 느린 IPv6 실패 시 IPv4로 빠르게 전환해 사용자 대기 시간을 최소화합니다.​

핵심 동작
DNS로 IPv6(AAAA)+IPv4(A) 주소를 모두 받은 후: IPv6을 50~300ms 먼저 시도 (우대) 병렬로 IPv4 실행, 먼저 성공한 쪽 선택 전체 대기 5초 제한으로 “느린 연결” 문제 해결​

왜 필요한가
IPv6 네트워크가 불완전할 때 IPv6만 기다리다 실패하면 사용자 불만 → Happy Eyeballs로 IPv6 장려 + IPv4 안전망.​

DNS A / AAAA 의미

  • A 레코드: 도메인 → IPv4 주소(or IPv4가 할당된 호스트)
  • AAAA 레코드: 도메인 → IPv6 주소(or IPv6가 할당된 호스트)

동일 도메인에 A/AAAA 레코드가 모두 설정되고 그 둘이 다른 경로로 연결될 경우, 네트워크 유형에 따라 IPv4 경로 또는 IPv6 경로로 요청이 분기될 수 있습니다.

실제 경로 비교 – Wi-Fi vs 모바일 데이터

Wi-Fi 환경

일반적인 Wi-Fi 환경(특히 IPv4 위주인 환경)에서는 다음 흐름이 발생했다.

  1. 스마트폰 (Wi-Fi)
  2. api.myservice.com DNS 조회
  3. A 레코드(IPv4) 우선 선택
  4. myservice-prod-alb-123456.ap-northeast-2.elb.amazonaws.com (ALB)로 접속
  5. ALB → ECS → 200 OK

Wi-Fi에서는 문제가 발생하지 않았다.

모바일 데이터(LTE/5G) 환경

모바일 데이터 환경에서는 다음 흐름이 발생했다.

  1. 스마트폰 (LTE/5G)
  2. api.myservice.com DNS 조회
  3. AAAA 레코드(IPv6) 우선 선택
  4. d1abcd2xyz3w.cloudfront.net (CloudFront)로 접속
  5. CloudFront가 Origin(ALB)으로 요청 전달
  6. ALB 리스너 규칙 및 Host 헤더 처리 방식에 따라
  7. 특정 타깃 그룹으로 라우팅
  8. 이 구간에서 라우팅 오동작 → 503 응답

즉, IPv4 경로는 정상, IPv6 경로만 문제가 있는 상태였고,

모바일 데이터가 주로 IPv6 경로를 사용하면서

문제가 특정 환경에서만 나타난 것이다.

해결 방법 AAAA 레코드 임시 제거

우선 목표는 운영 장애 해소였다.

따라서 가장 빠르고 확실한 조치로 다음을 수행했다.

  1. api.myservice.com의 AAAA 레코드 삭제
  2. 모든 클라이언트가 A 레코드(IPv4) → ALB 경로만 사용하도록 유도

이후 사내 직원들의 휴대폰을 대상으로 단말 테스트를 진행한 결과, 모든 단말에서 데이터 통신이 정상적으로 동작하는 것을 확인했다. 또한 IPv6 트래픽이 정상적으로 라우팅되도록 AAAA 레코드를 추가·설정했다.

정리

Wi-Fi에서는 문제가 없고 모바일 데이터(LTE/5G)에서만 API 호출이 실패하는 간헐적 장애의 원인은 DNS 라우팅 채널 분리(A 레코드와 AAAA 레코드의 불일치)에 있었습니다. 모바일 환경에서는 주로 IPv6(AAAA 레코드) 우선 조회를 시도하면서 CloudFront를 거치게 되었고, 이 경로상의 ALB 관련 라우팅 오동작이 503 에러를 유발했습니다. AAAA 레코드를 임시 제거하여 트래픽을 IPv4로 일원화함으로써 긴급히 상황을 수습할 수 있었습니다.

네트워크 장애 발생 시 클라이언트의 통신 환경(IPv4 vs IPv6) 단편화를 인지하고, DNS 계층의 설정까지 꼼꼼히 짚어보는 것이 매우 중요하다는 것을 배운 트러블슈팅 사례였습니다.

참고 자료

Updated:

Comments