Route 53이란?
- AWS에서 제공하는 DNS(도메인 네임 시스템) 서비스
- 사용자가 입력한 도메인(URL)을 실제 서버의 IP 주소로 변환하는 역할
- AWS 리소스(EC2, S3, CloudFront 등)와 연동하여 트래픽을 효율적으로 관리 가능
- 전 세계 어디서나 빠르고 신뢰할 수 있는 도메인 라우팅을 제공
- 헬스 체크(Health Check) 기능 제공: 일부 라우팅 정책에서 인스턴스의 정상 여부를 감지하여 트래픽을 조정할 수 있음
Route 53의 주요 라우팅 정책
AWS Route 53은 다양한 라우팅 정책을 제공하여 트래픽을 원하는 방식으로 제어할 수 있음
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
1️⃣ Simple Routing Policy (단순 라우팅 정책)
- 가장 기본적인 라우팅 방식
- 하나의 도메인 이름에 대해 단일 IP 주소 또는 단일 리소스만 연결
- 동일한 레코드를 여러 개 설정할 수 있지만, 클라이언트가 랜덤하게 하나를 선택
- Alias 설정 시, 하나의 AWS 리소스만 지정 가능
- 헬스 체크 지원 X → 장애 감지 기능 없음
✅ 예제:
example.com을 EC2 인스턴스 1대 또는 S3 정적 웹사이트에 연결할 때 사용
2️⃣ Weighted Routing Policy (가중치 기반 라우팅)
- 트래픽을 여러 리소스로 나누어 보내고, 비율(가중치)을 조절할 수 있는 방식
- 특정 서버나 지역에 더 많은 트래픽을 보내고 싶을 때 유용
- 각 레코드의 비율(가중치) 합이 100이 될 필요는 없음
- 모든 레코드의 가중치를
0으로 설정하면 모든 레코드에 동일한 비율로 트래픽을 분산 - 헬스 체크 지원 O → 특정 서버가 다운되면 트래픽을 다른 서버로 자동 전환 가능
✅ 예제:
- A 서버(70%), B 서버(30%)로 트래픽을 분산하고 싶을 때
- A 서버가 더 강력한 성능을 가지고 있다면 A 서버에 더 많은 트래픽을 보내도록 설정 가능
3️⃣ Latency-Based Routing Policy (지연 시간 기반 라우팅)
- 사용자와 가장 가까운(지연 시간이 가장 낮은) 서버로 트래픽을 보내는 방식
- 글로벌 서비스에서 빠른 응답 속도를 제공하는 데 유용
- 사용자와 AWS 리전 간의 네트워크 속도를 기반으로 결정
- 헬스 체크 지원 O → 장애가 발생한 서버가 있으면 자동으로 다른 서버로 트래픽을 보냄
✅ 예제:
- 미국, 유럽, 아시아에 서버가 각각 있음
- 미국 사용자는 미국 서버로, 유럽 사용자는 유럽 서버로 자동 연결됨
➡ 사용자가 가까운 서버로 연결되기 때문에 웹사이트 속도가 빨라짐
4️⃣ Geolocation Routing Policy (지리적 위치 기반 라우팅)
- 사용자의 실제 위치(국가, 대륙)에 따라 특정 서버로 연결하는 방식
- 특정 국가 또는 지역별로 트래픽을 제어할 수 있음
- 매칭되지 않는 지역 사용자를 위해 기본 레코드를 설정해야 함
- 헬스 체크 지원 X
✅ 예제:
- 미국 사용자 → 미국 서버, 한국 사용자 → 한국 서버로 연결
- 한국 사용자는 한국어 웹사이트, 일본 사용자는 일본어 웹사이트로 자동 연결 가능
➡ 사용자의 실제 위치를 기반으로 지역 맞춤형 서비스를 제공할 때 유용
5️⃣ Geoproximity Routing Policy (지리적 근접성 기반 라우팅)
- 사용자 위치와 가까운 리소스로 연결
- 추가적으로 Bias 값(1~99 또는 -1~-99)을 설정하여 특정 지역으로 더 많은 트래픽을 유도 가능
- 헬스 체크 지원 X
✅ 예제:
- 서울에 서버(A), 도쿄에 서버(B)가 있음
- 기본적으로 서울 사용자 → 서울 서버, 도쿄 사용자 → 도쿄 서버지만,
- 비즈니스 정책에 따라 서울 사용자도 일부 도쿄 서버를 사용할 수 있도록 조정 가능
➡ 특정 서버로 더 많은 트래픽을 보내도록 거리 조정 가능
6️⃣ Failover Routing Policy (장애 조치 라우팅)
- 기본(primary) 서버가 다운되면 보조(secondary) 서버로 트래픽을 자동 전환
- 고가용성을 유지하는 데 유용
- 헬스 체크 지원 O → 기본(primary) 서버가 정상인지 지속적으로 체크하여 장애 발생 시 백업 서버로 자동 전환
✅ 예제:
- 기본적으로 미국 서버를 사용하지만, 해당 서버가 다운되면 유럽 서버로 자동 전환
- 데이터베이스 마스터 서버가 장애가 발생하면 자동으로 슬레이브 서버로 연결 변경
➡ 서비스 장애 시 자동으로 백업 서버로 전환하여 안정성을 높일 수 있음
7️⃣ Multivalue Answer Routing Policy (다중 응답 라우팅 정책)
- 하나의 도메인에 대해 여러 개의 IP 주소를 반환하여 트래픽을 분산하는 방식
- 간단한 로드 밸런싱 효과를 가짐
- 최대 8개의 헬스 체크된 리소스를 반환할 수 있음
- ELB(Elastic Load Balancer)를 대체하는 용도로 사용하면 안 됨 (ELB는 세밀한 트래픽 제어 가능)
- 헬스 체크 지원 O → 장애가 발생한 인스턴스는 응답 목록에서 제거 가능
✅ 예제:
example.com요청 시 여러 개의 서버 IP(예: A 서버, B 서버)를 반환- 사용자의 요청이 여러 서버 중 하나로 연결되도록 설정
➡ 단순한 로드 밸런싱을 제공하지만, ELB(Elastic Load Balancer) 같은 기능은 없음
Route 53 - 헬스 체크
✅ "헬스 체크는 서버나 서비스가 정상적으로 작동하는지 확인하는 자동화된 시스템"
➡ 즉, Route 53 헬스 체크는 특정 서버(엔드포인트)의 상태를 지속적으로 점검하여, 장애 발생 시 트래픽을 다른 서버로 자동 전환하는 역할을 함.
- 퍼블릭 리소스에서만 사용 가능 (Private 네트워크 직접 체크 불가)
- 자동화된 DNS Failover 지원
- 특정 엔드포인트의 상태를 지속적으로 헬스 체크
- 다른 헬스 체크를 모니터링 가능
- CloudWatch 알람과 연동 가능
- 헬스 체크는 CloudWatch Metrics(메트릭)를 통해 모니터링 가능
헬스 체크의 엔드포인트 모니터링
- 15개의 헬스체커(Health Checker)가 엔드포인트 헬스 체크를 수행
- 기본적으로 3번 시도 후 판단
- 30초 단위로 주기적 체크
- HTTP/HTTPS/TCP 기반의 헬스 체크 가능
- 18% 이상의 헬스 체크가 통과하면 Route 53은 해당 리소스를 Healthy(정상)로 판단
- 헬스 체크 위치를 지정 가능
- 헬스 체크가 Pass(정상)로 인정되는 기준:
- 2xx, 3xx 상태 코드만 허용
- 첫 5120 바이트 이내의 응답 텍스트를 기준으로 Pass/Fail 설정 가능
- Route 53을 통해 들어오는 헬스 체크 요청을 허용하려면 라우터 또는 방화벽에서 설정 필요
Private Hosted Zone에서 헬스 체크
- Route 53 헬스 체크는 VPC(가상 네트워크) 외부에서 동작
- Private 리소스(사설 네트워크)의 헬스 체크는 직접적으로 수행할 수 없음
- CloudWatch Metrics 및 CloudWatch Alarms(알람)을 기반으로 헬스 체크 설정 가능
📌 Route 53 헬스 체크 적용 예제
1️⃣ 예제: 웹 서버 헬스 체크 & 자동 장애 조치 (Failover)
💡 상황:
example.com이 미국(AWS 버지니아 리전)의 EC2 인스턴스 A에서 실행됨.- 동일한 웹사이트가 유럽(AWS 프랑크푸르트 리전)의 EC2 인스턴스 B에서도 운영됨.
- 주 서버(A)가 정상 작동할 때는 모든 트래픽이 A로 라우팅됨.
- A가 다운되면 자동으로 B로 트래픽을 전환해야 함.
✅ 해결 방법:
1. Route 53 헬스 체크 설정
- 헬스 체크 대상: EC2 인스턴스 A (버지니아)
- 헬스 체크 방식: HTTP 요청을 30초마다 보냄 (
example.com:443/health-check) - 정상 응답 코드: 2xx 또는 3xx 상태 코드여야 함.
- Failover Routing 설정
- A 서버가 Primary (주 서버), B 서버가 Secondary (보조 서버)로 설정됨.
- A가 정상 작동 중이면, 트래픽이 A로 전달됨.
- A가 다운되면, 트래픽이 자동으로 B로 전환됨.
💡 결과:
✅ 주 서버(A) 정상 → 트래픽 A로 이동
❌ 주 서버(A) 장애 발생 → 트래픽 B로 자동 전환
2️⃣ 예제: 여러 개의 웹 서버가 있을 때 로드 밸런싱 + 헬스 체크
💡 상황:
example.com이 3개의 EC2 인스턴스(A, B, C)에서 운영됨.- 트래픽을 A, B, C 서버로 균등하게 분산해야 함.
- 하지만 어떤 서버가 다운되면 그 서버로 트래픽이 가면 안 됨.
✅ 해결 방법:
1. Multivalue Answer Routing 사용
example.com도메인에 A, B, C의 IP 주소를 모두 등록- Route 53 헬스 체크를 설정하여 각 서버(A, B, C)의 상태를 개별적으로 체크
- 헬스 체크 동작 방식
- A, B, C 중 한 서버가 다운되면, Route 53은 해당 서버의 IP를 응답에서 제외
- 남아있는 정상 서버들로만 트래픽을 보내도록 설정
💡 결과:
✅ A, B, C 모두 정상 → 트래픽이 3개 서버로 분산
❌ A 서버 장애 발생 → 트래픽이 B, C 서버로만 이동
❌ A, B 모두 장애 발생 → 트래픽이 C 서버로만 이동
📌 정리: Route 53 헬스 체크 적용 시 핵심 포인트
✅ 퍼블릭 리소스(외부에서 접근 가능한 서버)에 대해 직접 헬스 체크 가능
✅ Failover Routing과 조합하여, 장애 발생 시 트래픽을 자동으로 다른 서버로 전환 가능
✅ Multivalue Answer Routing과 함께 사용하면, 로드 밸런싱 효과도 가능
✅ Private Hosted Zone(VPC 내부 서버)은 CloudWatch와 연동하여 간접적으로 헬스 체크 가능
