GSLB - Route53으로 여러 라우팅정책 구현해보기

GSLB란?

GSLB는 Global Server Load Balancing으로
로드밸런서가 아니라 전세계 어디에서든지 빠르고 신뢰성 있는 응답을 제공하기 위한 지능적인 DNS이다.

대부분으로 글로벌 DNS 브랜드는 GSLB를 제공하고있다.

통상적으로 아래와 같은 기능들을 제공한다.

1. Performance : 클라이언트의 요청을 네트워크상 가까운 서버로 연결할 수 있다. 트래픽을 지역에 맞게 분산해서 연결할 수 있다.
2. Customized Content : 지역/언어별로 커스텀한 콘텐츠를 자동으로 제공할 수 있다.
3. Disaster Recovery : 장애가 발생했을 때 다른 지역의 서버로 redirect해서 HA(고가용성) 구성이 가능하다.
4. Maintenance : 연결 규칙이나 구성이 변경 가능해야한다.
5. Compliance : 국가나 지역의 규제에 맞게 요청을 전다할 수 있다.

AWS Route53에서 Routing 설정하기

Failover로 이중화하기

Failover는 연결 대상인 서비스(DNS,IP,Server 등)로 연결이 안될때 대체 서비스로 연결되도록 하는 것이다.

이를 통해 예상치 못한 장애를 대비하여 서비스를 안정적으로 제공할 수 있다.

하지만 여분의 인프라가 필요하다.

Failover 설정해보기

우선 2개의 Ec2서버를 준비한다.

1. 서버 띄우기

하나의 서버에 간단하게 2000포트로 netcat으로 띄워본다.

nc -l -p 2000 -k

자신의 컴퓨터에서 해당 서버로 요청으로 보내보고 제대로 Echo가 이루어지는지 확인한다.

echo hi | nc $ec2_public_ip 2000

잘 되면 2대의 서버 모두 띄워놓는다.

2. Health Check 생성

서버의 정상/비정상이 판단되어야 Failover를 확이할 수 있기에
AWS에서 2대의 ec2 서버 모두 Health Check를 생성한다.

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 에서 자신의 서비스에 필요한 것을 설정한다.
8. Alarm 연동이 필요한 경우(cloudwatch등) 설정한다.

3. Record 생성

다음 record를 생성한다.

1. Record 1에 대해서
   1. Record name: failover
   2. Record type: A
   3. Value: 첫번째 서버의 IP주소
   4. TTL: 1m
   5. Routing Policy: Failover
   6. Failover record type: Primary
      health check 가 정상이라면, 이 연결로만 라우팅한다.
   7. Health check ID: 첫번째 서버에 해당하는 healthcheck
   8. Record ID: failover-primary
      같은 record name에 대해서 구분하기 위해서 사용
2. Add another record 버튼을 눌러서 Record 2를 만든다.
   1. 아래 설정 외에는 Record 1과 동일하다.
   2. Failover record type: Secondary
      Primary 가 unhealthy 상태라면 이 연결로 라우팅한다.
   3. Health check ID: 두번째 서버에 해당하는 healthcheck
   4. Record ID: failover-secondary
      같은 record name에 대해서 구분하기 위해서 사용

4. 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로 변경한다.

 

가중치 기반(Weighted) 라우팅

Failover의 경우 Secondary 서버가 아무것도 안했다면
이번에는 가중치 값에 따라 트래픽을 분산시킬 수 있다.

이렇게 하면 장애 대비와 함께 구축 후에도 지속적으로 사용할 수 있다.
Canary Deployment(카나리 배포 : 미리 조금만 배포 해보는 것)로 활용할 수 있다.
부하 분산도 가능하다.

Failover 방식과 Health Check까지는 같으며
Record 생성시 설정값이 다르다.

Routing Policy : Weighted
Weight: {원하는 정수 값}

위에 부분과 Record ID만 다르게 설정해주면 된다.

확인해볼때도 굳이 하나의 서버에서 프로세스를 종료 안해도
가중치 비율에 근사하게 접속되는 것을 확인할 수 있다.

지역 기반(Geo) 라우팅

지역 기반 라우팅은
해당 지역에서 들어온 IP로 판단되면 해당 지역에 매칭되도록 설정한 DNS/IP/Server로 라우팅해준다.

이렇게해서 지역별로 서로 다른 서비스를 제공할 수 있으며 응답시간도 빠르게 할 수 있다.
하지만 빠른 latency를 제공하지 않을 수도 있다. (해당 지역이 그 국가의 땅이라고 해서 그 국가의 서버와 가장 가깝다는 보장은 없음)

지역기반 라우팅에서는 Health Chekc의 등록도 선택할 수 있다. 해당 지역의 모든 Record가 unhealthy면 클라이언트는 host를 못찾는다.

Routing Policy : Geolocation
Location : 원하는 지역 선택
Health check ID : 설정 안함

이번에도 이 설정들과 Record ID만 바꿔서 Record 2도 똑같이 진행한다.

확인할 때는 2개의 서버의 region을 다르게 해서 접속해본다.

 

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

지리 근접 라우팅은
접속한 클라이언트의 지리적으로 근접한 지역으로 라우팅하는 것이다.
지리 근접의 규칙도 변경가능하다.

클라이언트의 접속량의 변화에 따라서 규칙을 변경하며 유연하게 대처할 수 있다.
하지만 Traffic-flow의 추가과금이 있다.

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

접속한 클라이언트가 가장 빠른 응답을 받을 것으로 기대되는 곳으로 라우팅하는 것이다.

빠른 응답을 받을 수 있다는 큰 장점이 있지만
AWS의 자체 로직으로 결정되기에 튜닝이 불가하며 100% 확률로 가장 낮은 Latency를 제공할 수는 없다.

이 밖에도 여러 라우팅 정책들이 있다.