4. AWS Route53에서 Routing 설정하기

AWS에서는 GSLB라고 따로 정의한 상품이 있지는 않지만, Route53의 라우팅 정책을 통해서 GSLB의 기능적인 목표를 달성할 수 있다.

4.1 Failover 로 이중화 하기

공식 문서

4.1.1 Failover 특징

연결 대상인 서비스(DNS/IP/Server)로 연결이 되지 않을 때, 설정한 대체 서비스로 연결하도록 한다.

장점

• 예상치 못한 장애 상황에 대비해서, 서비스를 안정적으로 제공할 수 있다.

단점

• 사용하지 않는 인프라를 여분으로 둬야한다.
  • 사용하지 않는 동안 관리되지 않아서(최신버전 배포를 하지 않는 등) Failover가 발생했지만, 사용자 입장에서 버그가 발생할 수 있다.

4.1.2 언제 사용하는가?

• 장애 방지를 위해 이중화가 필요한 모든 경우

• 대안: 사용되고 있는 Failover 구성을 하고 싶으면 weighted를 사용해서 이중화와 리소
  스 사용률을 다 잡을 수 있다. 배포가 누락되어 버그가 발생하는 것도 방지할 수 있다.

4.1.3 Failover 실습 - nc command 로 TCP 연결 받기

nc(netcat) 명령어로 간단하게 echo 서버를 띄울 수 있다.
다음 명령어를 자신의 EC2 서버에서 수행하자.

nc -l -p 2000 -k

• -l : localhost
• -p : 2000 해당 포트로 listen 한다.
• -k : 응답 후에도 계속 살아있다.

다른 클라이언트(서버 또는 자신의 컴퓨터)에서 해당 EC2 서버에 요청을 보내고, EC2서버의 nc 에서 echo가 이루어지는지 확인한다.

echo hi | nc $ec2_public_ip 2000

4.1.4 Failover 실습 - Health Check 생성

Route 53에서는 HealthCheck를 통해 지정된 엔드포인트의 상태를 모니터링하고, 그 결과에 따라 페일오버(Failover) 전략을 실행한다.

HealthCheck은 크게 다음과 같은 유형으로 나뉜다.

• 엔드포인트 상태 확인 (Endpoint Monitoring)
  지정된 IP 주소나 도메인 이름으로 구성된 엔드포인트에 주기적으로 요청을 보내 응답 여부를 확인한다. 애플리케이션, 서버 등 실제 리소스가 정상 동작 중인지 점검하는 데 사용된다.

• 계산된 상태 확인 (Calculated Health Check)
  다른 HealthCheck의 상태를 종합해 하나의 상태로 판단한다. 예를 들어, 동일한 기능을 수행하는 여러 웹 서버가 있을 때, 그 중 일정 수 이상의 서버만 정상이어도 전체를 정상으로 판단하도록 구성할 수 있다.

• CloudWatch 기반 상태 확인
  CloudWatch 경보의 상태를 기반으로 엔드포인트의 상태를 판단한다. 예를 들어 특정 DynamoDB 지표나 ELB 인스턴스 수가 기준 이하로 떨어졌을 때 비정상으로 간주할 수 있다.

각 유형별로 ‘정상/비정상’을 판단하는 기준이 다르므로, 사용하려는 옵션의 공식 문서를 반드시 확인해야 한다. 예를 들어 TCP 연결 방식에서는 10초 이내에 연결이 성립되지 않으면 비정상으로 간주된다.

---

실습에서는 무엇을 사용할 것인가?

실습에서는 endpoint 모니터링 > 프로토콜 > TCP 연결을 확인한다.

가장 기본적인 형태인 엔드포인트 상태 확인을 선택하고, 프로토콜은 TCP 연결 방식으로 설정한다. 즉, 특정 포트로 TCP 세션이 열리는지를 기반으로 상태를 판별한다.

이 방식은 다음과 같은 특성을 가진다:

• HTTP/HTTPS보다 설정이 간단하고, 서버에 특별한 웹 애플리케이션이 없어도 된다.
• Netcat(nc)으로 손쉽게 포트를 열어 테스트할 수 있다.
• 단순한 연결 확인만 수행하므로, 서비스 품질까지는 측정하지 않는다.

1. HealthCheck Home 에서 Create HealthCheck
2. What to monitor: Endpoint
3. Specify endpoint by: IP address
4. Protocol: TCP
5. IP address: 자신의 EC2 public IP
6. port: 자신이 띄운 nc process의 port
7. Advanced Configuration 에서 자신의 서비스에 필요한 것을 설정한다.
   • 실습에서는 빠른 확인을 위해 interval=10s, failure threshold=1로 설정한다.
8. Alarm 연동이 필요한 경우(cloudwatch등) 설정한다.

위의 과정을 두 개의 EC2 인스턴스에 각각 수행하여 두 개의 HealthCheck를 생성한다.
이후 이 HealthCheck들을 Route 53의 Failover 레코드 설정에 연결하면, 한 인스턴스가 비정상 상태로 전환될 경우 자동으로 다른 인스턴스로 트래픽이 전환되는 장애 조치(Failover) 동작을 실습할 수 있다.

위의 방식으로 두대의 EC2 서버에 대해서 각각 health check 를 생성한다.

• 두대의 EC2 서버에 접속해서 4.1.3 의 nc 커맨드로 port를 listen 해둔다.

4.1.5 Failover 실습 - record 생성

Hosted zones > 자신의 record > Create Record 를 선택한 후 다음 설정으로 레코드르 생성한다.

1. Record 1에 대해서

• Record name: failover
• Record type: A
• Value: 첫번째 서버의 IP주소
• TTL: 1m
• Routing Policy: Failover
• Failover record type: Primary
  • health check 가 정상이라면, 이 연결로만 라우팅한다.
• Health check ID: 첫번째 서버에 해당하는 healthcheck
• Record ID: failover-primary
  • 같은 record name에 대해서 구분하기 위해서 사용

2. Add another record 버튼을 눌러서 Record 2를 만든다.

• 아래 설정 외에는 Record 1과 동일하다.
• Failover record type: Secondary
  • Primary 가 unhealthy 상태라면 이 연결로 라우팅한다.
• Health check ID: 두번째 서버에 해당하는 healthcheck
• Record ID: failover-secondary
  • 같은 record name에 대해서 구분하기 위해서 사용

4.1.6 Failover 확인

1. HealthChecks에서 생성한 두개의 health check 가 모두 healthy인지 확인한다.
2. host(또는 nslookup) 명령어로 failover.$yourdomain 으로 domain에 해당하는 IP address를 확인한다.
   • Primary 에 해당하는 IP address 가 나와야 정상이다.
3. Primary 에 해당하는 EC2 서버에서 ns 프로세스를 종료한다.
4. HealthChecks에서 Primary에 해당하는 EC2서버의 health check 가 unhealthy인지 확인한다.
5. 다시 host 명령어로 도메인에 해당하는 IP address 를 확인한다.
   • Secondary 에 해당하는 IP address 가 나와야 정상이다.
6. Secondary 에 해당하는 EC2 서버에서 ns 프로세스를 종료한다.
7. HealthChecks에서 모든 EC2서버의 health check 가 unhealthy인지 확인한다.
8. 다시 host 명령어로 도메인에 해당하는 IP address 를 확인한다.
   • 모든 health check 가 unhealthy일때, route53의 failover 전략은 라우팅을 Primary로 변경한다.

4.2 가중치 기반(Weighted) 라우팅

공식 문서

4.2.1 특징

가중치 기반 라우팅은 두 개 이상의 대상 리소스에 대해 트래픽을 가중치 비율에 따라 분산시키는 방식이다.

이 방식은 다음과 같은 상황에서 유용하다:

• 장애 대비용 예비 인프라에 일부 트래픽을 미리 유입시켜 최소한의 상태 점검이 되도록 운영하고 싶은 경우
• 기능 실험이나 A/B 테스트, Canary 배포 등에서 사용자 트래픽을 비율에 따라 분할하고자 할 때
• 복잡한 라우팅 로직 없이 DNS 수준에서 간단히 트래픽 분산을 시도하고자 할 때
  • 예를 들어, 신규 기능이 탑재된 서비스를 10% 사용자에게만 우선 제공하려는 경우, 두 서버 간의 가중치를 9:1로 설정하면 된다.

장점

• 설정이 단순하고, 다양한 용도로 활용할 수 있음

• Canary 배포, A/B 테스트, 장애 대비 예비 인프라 운영 등에 적합

단점

• 가중치 값은 정적으로만 설정 가능하며, 자동 조정이 불가능

• 실시간 트래픽 변화에 유동적으로 반응하지 않음

4.2.2 언제 사용하는가?

장애 대비용으로 미리 구축 후 지속적으로 사용하는 경우

Weighted Routing은 장애 발생 시를 대비해 여분의 인프라를 구성한 뒤, 평상시에도 일부 트래픽을 분산시켜 운영할 수 있는 방법이다. 특히 Multi-AZ 또는 Multi-Region 환경에서 사용한다.

• AZ (Availability Zone)란?
  동일한 리전(Region)에 속하지만 물리적으로 독립된 데이터 센터 그룹을 의미한다. 하나의 AZ에서 장애가 발생해도, 다른 AZ는 영향을 받지 않기 때문에 고가용성 확보에 유리하다.

새 버전의 Canary Deployment(카나리 배포) 전략에 활용하는 경우

전체 배포 전에 일부 사용자만 새로운 버전의 서비스를 사용하도록 하여, 문제가 발생하는지 여부를 사전에 확인하는 전략이다. 이때 Weighted Routing을 통해 전체 트래픽의 일부(예: 10%)만 새 버전으로 라우팅하는 방식으로 적용한다.

• 카나리 배포란
  블루-그린 배포 방식처럼 두 가지 버전을 동시에 유지하지만, 한쪽에 소량의 트래픽만 전달하여 안정성을 확인한 뒤 전체로 확장하는 방식이다. 이 방식은 위험을 최소화하며 점진적으로 배포를 진행할 수 있다는 장점이 있다.

인프라 규모 확장에 따른 부하 분산이 필요한 경우

트래픽이 많아 로드 밸런서 하나로 처리하기 어려운 상황에서는 DNS 수준에서 트래픽을 여러 인프라로 분산해야 한다. Weighted Routing은 이러한 경우 각 서버나 리전에 비례적으로 트래픽을 분산하는 데 효과적이다.

• 인프라 규모에 따른 부하 분산이란
  로드 밸런서를 여러 개 운영하거나, 리전 단위로 트래픽을 분산시키는 등 물리적인 인프라 확장에 따라 네트워크 트래픽을 적절히 나누는 것을 의미한다. 이때 DNS 레벨에서 가중치를 적용하여 간단하게 분산을 설정할 수 있다.

4.2.3 Weighted 실습 - Health Check 생성

HealthCheck를 통해서 정상인 레코드에 대해서만, weighted 규칙에 맞는 트래픽을 라우팅한다. HealthCheck 설정 방법은 4.1.4 Failover 실습 - Health Check 생성 과 같다.

실습에서는 endpoint 모니터링 > 프로토콜 > TCP 연결을 확인한다.

4.2.4 Failover 실습 - record 생성

Hosted zones > 자신의 record > Create Record 를 선택한 후 다음 설정으로 레코드르 생
성한다.

1. Record 1에 대해서

• Record name: weighted
• Record type: A
• Value: 첫번째 서버의 IP주소
• TTL: 1m
• Routing Policy: Weighted
• Weight: 0~255 사이의 정수를 입력한다. 같은 subdomain에 대해서 weight의 총합에 대해 해당 숫자만큼의 비례해서 트래픽이 라우팅된다.
  • unhealthy 상태인 것은 계산에서 뺀다.
  • 실습에서는 8
• Health check ID: 첫번째 서버에 해당하는 healthcheck
• Record ID: weight-8
  • 같은 record name에 대해서 구분하기 위해서 사용

2. Add another record 버튼을 눌러서 Record 2를 만든다.

• 아래 설정 외에는 Record 1과 동일하다.
• Weight
  • 실습에서는 2로 세팅
• Health check ID: 두번째 서버에 해당하는 healthcheck
• Record ID: weight-2
  • 같은 record name에 대해서 구분하기 위해서 사용

4.2.5 Failover 확인

1. HealthChecks에서 생성한 두개의 health check 가 모두 healthy인지 확인한다.
2. host(또는 nslookup) 명령어로 weighted.$yourdomain 으로 domain에 해당하는 IP address를 확인한다.
   • 반복해서 10회, 20회 요청한 뒤에 8:2의 비율로 응답되는 IP address 가 나눠지는지 확인한다.
3. 둘 중 하나의 EC2 서버에서 ns 프로세스를 종료한다.
4. HealthChecks에서 중지한 EC2서버의 health check 가 unhealthy인지 확인한다.
5. 다시 host 명령어로 도메인에 해당하는 IP address 를 확인한다.
   • 8:2가 아니라, healthy 상태인 하나의 IP address 만 응답한다.
6. 나머지 EC2 서버에서도 ns 프로세스를 종료한다.
7. HealthChecks에서 모든 EC2서버의 health check 가 unhealthy인지 확인한다.
8. 다시 host 명령어로 도메인에 해당하는 IP address 를 확인한다.
   • 모든 health check 가 unhealthy일때, route53의 weighted 전략은 weighted 가
     가장 높은 record로 연결한다.

4.3 지역 기반(Geo) 라우팅

공식 문서

4.3.1 특징

지역(행정구역을 말 함)을 직접 설정해서, 해당 지역에서 들어온 IP로 판단되면 해당 지역에 매칭되도록 설정한 대상 (DNS/IP/server)으로 라우팅을 해준다.

장점

• 지역별로 다른 서비스를 제공해야할 때, 지역별로 연결할 서버나 서비스를 명확히 할 수 있다.
• 지역에 가까운 리전으로의 연결을 설정한다면, 빠른 응답시간을 기대할 수 있다.

단점

• 지역을 특정할 수 없는 IP가 들어오는 경우가 있다.

  • 이런 트래픽을 연결할 대상을 지정할 수 있다.
  • 단, 서비스 구분을 지역 기반 라우팅에 맡겼다면 이런 경우에는 지역을 추론하기 위한 추가 구현이 필요하다.

• 지역기반이 가장 좋은(빠른) latency를 제공하지 않을 수도 있다.

  • 예) 상하이에서 client가 접속을 요청하면, Beijing, Seoul, Tokyo, Singapore 리전 중 어디가 가장 가까울까? 어디가 가장 빠를까? (지도상으로 더 가까워 보이더라도 바다 밑 광케이블이나 이런 물리적 연결들이 어떻게 되어 있는지는 정확히 모르기 때문에 지역기반이 가장 빠른 latency가 아닐 수 있다)

4.3.2 언제 사용하는가?

• 지역별로 규제나 법률이 달라서, 서비스를 다르게 배포하거나 제공해야하는 경우.
• 지역별로 서비스 인프라가 갖추어져 있고, 지역 기반으로 빠르게 응답할필요가 있는 경우

4.3.3 Geo 실습 - Health Check 생성

(geo의 경우에는 헬스체크 생성이 필수는 아니다. failover 같은 경우는 필수였고. weighted 같은 경우는 웬만하면 해야 되는 것임.)

Geo 설정에서 HealthCheck도 함께 등록할지 선택할 수 있다.

• HealthCheck를 등록한 경우, 해당 지역의 모든 record가 unhealthy라면 client 는 host를 찾을 수 없다고 나온다.
  HealthCheck 설정 방법은 4.1.4 Failover 실습 - Health Check 생성 과 같다.
  실습에서는 endpoint 모니터링 > 프로토콜 > TCP 연결을 확인한다.

4.3.4 Geo 실습 - record 생성

Hosted zones > 자신의 record > Create Record 를 선택한 후 다음 설정으로 레코드를 생성한다.
1. Record 1에 대해서

• Record name: geo
• Record type: A
• Value: 첫번째 서버의 IP주소
• TTL: 1m
• Routing Policy: Geolocation
• Location: 원하는 지역을 선택한다. 국가를 선택할 수도 있고, 국가보다 작은 지역단위로 선택할 수도 있다.
  • 실습에서는 Republic of Korea
• Health check ID: 설정 안함
  • HealthCheck를 등록한 경우, 해당 지역의 모든 record가 unhealthy라면 client 는 host를 찾을 수 없다.
• Record ID: geo-korea
  • 같은 record name에 대해서 구분하기 위해서 사용

2. Add another record 버튼을 눌러서 Record 2를 만든다.

• 아래 설정 외에는 Record 1과 동일하다.
• Location
  • United States
• Record ID: geo-us
  • 같은 record name에 대해서 구분하기 위해서 사용

4.3.5 Failover 확인

1. 자신의 컴퓨터 또는 seoul region에 위치한 EC2에서 host(또는 nslookup) 명령어로 geo.$yourdomain 으로 domain에 해당하는 IP address를 확인한다.

• Record 1 에 설정한 IP가 응답된다.

2. United States 에 있는 Region에서 EC2 인스턴스를 생성한 뒤, 해당 인스턴스에서 host(또는 nslookup) 명령어로 geo.$yourdomain 으로 domain에 해당하는 IP address를 확인한다.

• Record 2 에 설정한 IP가 응답된다.

4.4 지리 근접(Geo-Proximity) 라우팅

4.4.1 특징

공식 문서

접속한 client의 지리적으로 근접한 지역으로 라우팅 한다. 이 지리 근접은 설정한 규칙 기반
(AWS의 traffic-flow)으로 동작하고, 변경할 수 있다.

장점

• 규칙을 변경하면서 client 접속량의 변화에 따라서 유연하게 대처할 수 있다.

단점

• Traffic-flow의 추가 과금이 있다.

4.4.2 언제 사용하는가?

• 지역별로 트래픽의 fluctuation(트래픽 변화의 패턴이나 흐름)이 있지만, 그것이 국가 또는 행정 구역으로 명확히 나눠지지는 않는 경우(또는 그럴 필요는 없는 경우).
  • 예) 넷플릭스 서비스. 기상 알림 서비스 등

4.5 지연 시간 기반(Latency) 라우팅

4.5.1 특징

공식 문서

접속한 client 가 가장 빠른 응답(낮은 latency)를 받을 것으로 기대되는 곳으로 라우팅. 측정된 값을 기반으로 한다.

장점

• 여러가지 고민하지 않아도 글로벌 client들에게 빠른 응답시간을 제공할 수 있다.

단점

• AWS의 자체 로직으로 결졍되므로 튜닝할 수 없다.
• 실제로 항상(100%) 가장 낮은 latency를 제공할 수는 없다. 늦어지는 곳으로 라우팅 하는 경우도 있다.

4.5.2 언제 사용하는가?

• 글로벌 서비스를 런칭하는데 복잡한 설정 없이 각 client에게 빠른 응답속도를 제공하고 싶은 경우.
  • 단, 지역별로 서비스의 배포 구분이 필요 없는 경우.

4.6 그 밖의 라우팅 정책

Routing Policies

• IP 기반 라우팅 (ip-based)
• 다중값 응답 라우팅 (multi-value)

나머지 라우팅 방법들은 실습으로 간단하게 확인하기 어렵다고 한다. 확인 하려 한다면 할 수 있겠지만, 실습 환경 구축하고 어플리케이션 따로 만들고 인프라 만드는 데 시간이 많이 걸리기 때문에 설정하는 방법들은 똑같이 AWS 콘솔에 들어가서 Routing polish를 다른 것으로 선택하면 그거에 맞는 옵션을 선택할 수 있도록 선택박스가 생긴다.

공식 문서에 나와있는 여러가지 정책들을 읽어보았다가 우리가 서비스에서 어떤 요구사항이 있을 때, 라우팅 정책 중에 제공하는 게 있다면 한 번 검토해 보는 식으로 접근하면 좋을 것 같다.