AWS Route 53의
라우팅 정책

안녕하세요. 보통 도메인을 구입하고 DNS를 설정할 때, 우리는 "www.example.com = 1.2.3.4" 처럼 단순한 1:1 매핑을 생각합니다.

‍

하지만 AWS Route 53은 단순한 전화번호부(DNS)가 아닙니다. 들어오는 트래픽을 아주 똑똑하게 분배해 주는 GSLB(Global Server Load Balancing) 역할을 수행할 수 있습니다.

‍

오늘은 Route 53이 제공하는 강력한 4가지 라우팅 정책(Routing Policy)을 통해, 어떻게 하면 무중단 배포(Canary)를 구현하고 전 세계에서 가장 빠른 응답 속도를 제공할 수 있는지 알아보겠습니다.

‍

1. 단순 라우팅 (Simple Routing) : "기본 중의 기본"

가장 일반적인 형태입니다. 도메인 하나에 IP 주소 하나(혹은 여러 개)를 연결합니다.

‍

동작: www.mysite.com으로 요청이 오면 지정된 IP(예: ELB 주소)를 반환합니다.

특징:

IP를 여러 개 등록하면 라운드 로빈(Round Robin) 방식으로 무작위로 반환하여 간단한 부하 분산 효과를 낼 수 있습니다.

하지만 헬스 체크(Health Check) 기능이 제한적이라, 서버가 죽어도 그 IP를 줄 수 있다는 단점이 있습니다.

‍

2. 가중치 기반 라우팅 (Weighted Routing) : "카나리 배포의 핵심"

트래픽을 지정한 비율(%)만큼 쪼개서 보냅니다. 개발자들이 가장 좋아하는 기능 중 하나입니다.

‍

시나리오: 신기능을 배포할 때 전체 사용자에게 바로 오픈하기 무섭다면?

활용법 (카나리 배포):

기존 버전(V1): 가중치 90 설정

새 버전(V2): 가중치 10 설정

‍

이렇게 하면 전체 트래픽의 10%만 새 버전으로 들어갑니다. 로그를 모니터링하다가 문제가 없으면 V2의 비중을 50 → 100으로 점진적으로 늘립니다.

‍

장점: 배포 리스크를 획기적으로 줄일 수 있습니다. (Blue/Green 배포에도 활용 가능)

‍

3. 지연 시간 기반 라우팅 (Latency Routing) : "가장 빠른 길 안내"

글로벌 서비스를 운영한다면 필수입니다. 물리적인 거리가 아니라, **네트워크 지연 시간(Latency)**이 가장 짧은 리전으로 안내합니다.

‍

시나리오: 서버가 서울(Seoul)과 버지니아(US-East) 두 곳에 있고, 사용자는 일본에 있습니다.

동작:

AWS는 전 세계 네트워크 상황을 실시간으로 알고 있습니다.

일본 사용자에게는 물리적으로 가까운 서울 리전의 IP를 반환합니다.

만약 미국 사용자가 접속하면? 자동으로 버지니아 리전 IP를 줍니다.

장점: 별도의 로드밸런서 없이 DNS 설정만으로 **글로벌 사용자 경험(UX)**을 극대화할 수 있습니다.

‍

4. 장애 조치 라우팅 (Failover Routing) : "최후의 보루 (DR)"

서비스가 죽었을 때를 대비한 Active-Passive 구성입니다. **Route 53 헬스 체크(Health Check)**와 결합하여 동작합니다.

‍

시나리오: 메인 서버(Primary)가 있는 서울 리전이 지진이나 화재로 셧다운 되었다면?

동작:

Route 53이 주기적으로 메인 서버의 상태를 찌릅니다(Health Check).

메인 서버가 응답하지 않으면(Unhealthy), 자동으로 트래픽을 미리 준비된 **백업 서버(Secondary, 예: 오사카 리전)**나 **점검 중 페이지(S3 정적 호스팅)**로 돌립니다.

장점: 재해 복구(DR) 시스템을 DNS 레벨에서 자동화할 수 있습니다.

‍

요약: 언제 무엇을 쓸까?

마치며

Route 53을 단순히 도메인 등록 대행업체로만 생각했다면, 여러분은 AWS가 제공하는 강력한 트래픽 제어 도구를 썩히고 있는 것입니다.

지금 운영 중인 서비스가 글로벌 진출을 앞두고 있거나, 배포 때마다 식은땀을 흘리고 있다면 Route 53의 라우팅 정책 탭을 한번 눌러보세요. 인프라 구조를 바꾸지 않고도 서비스의 품질을 높일 수 있습니다.