Route53 가중치 기반 라우팅 변경 시 트래픽 손실 문제

가중치 기반 라우팅

가중치 기반 라우팅을 사용하면 다수의 리소스를 단일 도메인 이름(example.com) 또는 하위 도메인 이름(api.example.com)과 연결하고 각 리소스로 라우팅되는 트래픽 비율을 선택할 수 있습니다. 이러한 방식은 로드 밸런싱, 새 버전의 소프트웨어 테스트 등을 비롯한 다양한 목적에 활용될 수 있습니다.
가중치 기반 라우팅을 구성하려면 각 리소스에 대해 동일한 이름의 레코드를 생성합니다. 각 리소스에 보낼 트래픽 양에 해당하는 상대적 가중치를 각 레코드에 할당합니다. Amazon Route 53는 그룹 내 전체 레코드의 총 가중치에 대한 비율에 따라 레코드에 할당된 가중치를 기반으로 트래픽을 리소스에 전송합니다.

- AWS 개발자 가이드 | https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/routing-policy-weighted.html

 

가중치는 상대적인 개념으로 1 : 2 : 3 이렇게 설정하든, 10 : 20 : 30 이렇게 설정하든 비율은 똑같다.

가중치 기반 라우팅에서 가중치를 0으로 설정하면 해당 리소스로의 트래픽을 중단하는 의미이다.

하지만 만약에 모든 리소스의 가중치를 0으로 설정하면, Route 53은 모든 리소스에 동일한 가중치를 할당하여 트래픽을 균등하게 분배한다.

 

라우팅 변경 시 트래픽 손실 가능성

1. 이론적으로는 손실이 없어야 한다.

라우터나 로드 밸런서가 상태를 유지하며 설정 변경을 적용하면, 변경 전 요청은 기존 경로로, 변경 후 요청은 새 경로로 안전하게 전달된다. AWS Route 53, Google Cloud Load Balancer 등 많은 시스템은 이를 보장하도록 설계되어 있다.

 

2. 하지만 가능성 존재

DNS 기반 가중치 라우팅에서는 TTL(Time-To-Live)로 인한 지연 반영과 캐싱 문제로 인한 일시적 경로 불일치 → 일부 요청 손실 또는 실패 가능

 

 

트래픽 손실이 발생하는 라우팅 전환 시나리오

- 조건

장애 상황 인지 시점을 라우팅 서비스의 Health Check 실패 시

 

- 상황

운영 환경 (서울 리전)

DR 환경 (도쿄 리전)

 

- 트래픽 손실 상황

운영 리전 장애 발생 → health check 실패 감지(지연 발생 ex 90초) → DNS 또는 라우팅 업데이트 → client 쪽 DNS 캐시 만료 → DR 리전으로 트래픽 전환

이 과정에서 사용자의 요청은 운영 리전(장애 리전)에 계속 전송 → 응답 없음(손실) 또는 5xx 오류 발생

 

# Health Check

*이 health check(health status : 1)의 실패는 요청이 30초마다 3번 이상씩 실패할 때, 3개 중 2개의 리전에서 이 상황이 감지될 때 실패 상태(health status : 0)가 된다. 요청 주기를 더 짧게 설정할 수도 있다. 그러면 health 상태를 인지하는 시간이 짧아질 것이다. 하지만 이 요청 시간이 너무 짧게 되면 이 자체로도 문제가 있다. 어떤 문제? false positive (오탐) 발생 가능성 증가

 

네트워크 지연, 순간적인 서비스 latency 등으로 정상 서비스도 일시적으로 health check 실패로 판단될 수 있다.

특히 짧은 주기 + 적은 횟수 → 빠르게 잘못된 장애 판단 → 불필요한 failover → 서비스 불안정

적당한 주기 설정 필요

 

 

 

그렇다면 이 문제를  방지하는 방법은?

원래 트래픽 손실 최소화의 근본적인 방법은 Multi-Region Active-Active 방식이다.

서울 + DR 리전을 항상 활성화(Active-Active)하여 운영 → 장애 시 failover가 아닌 부하 분산만 조정 → 손실 최소화

하지만 내가 가정한 상황인 일반 DNS Health Check 기반 Active-Active는 단일 요청 Failure에는 대응하지 않는다.

 

그렇다면??

가장 안전한 방법은 기본적으로 멀티 라우팅이 가능하게 구성하는 것이다.

 

Network Failover + Client Failover 전략

Network Failover	글로벌 Anycast IP 기반으로가까운 리전으로 빠르고 자동으로 라우팅 (AWS Global Accelerator, Cloudflare 등)
Client Failover	특정 리전 요청 실패 시 client가 자동으로 backup 리전으로 재시도 (primary endpoint 실패 시 secondary endpoint로 자동 재시도)

 

 

Network Failover

• Region 장애 또는 severe latency 상황 시 네트워크 레벨에서 자동으로 다른 리전으로 전환
• 예를 들어 AWS Global Accelerator는 health check와 routing decision을 초 단위로 수행하여 장애 감지 후 즉시 사용자를 도쿄 리전으로 라우팅

Client Failover

• 단일 요청에서 장애 발생(HTTP 5xx, timeout) 시 Application 또는 SDK 단에서 자동으로 secondary endpoint로 요청을 재전송
• DNS 캐시 또는 Health Check 지연으로 인한 blind time에서도 요청 성공률을 유지

 

운영 리전(서울) 장애 시 DR 리전(도쿄)으로의 라우팅 전환 과정에서 발생할 수 있는 트래픽 손실 문제를 최소화하려면 단순한 DNS Health check 기반 구조를 넘어 Network Failover + Client Failover의 다중 보호 계층을 설계해야 한다. 무중단 서비스의 필수적인 부분이라고도 볼 수 있다.