AWS Route 53에서 여러가지 Routing 정책

Sonar0·2022년 12월 17일
DNSawsrouting
0

Failover(장애 극복)로 이중화하기

Failover의 특징

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

  • 장점

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

  • 단점

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

사용 예시

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

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

Failover Routing 테스트

Health Check 생성

AWS에서 DNS 설정과 TCP 연결 이을 한 후에 Failover 서버 설정을 위해 Health Check를 생성한다.

HealthCheck를 통해서 정상/비정상 판단이 되어야, Failover 전략을 수행할 수 있다.
HealthCheck 의 종류마다 비정상으로 판단하는 방법이 다르다. 구체적인 기준은 문서를 확인한다.
이번엔 endpoint 모니터링 → 프로토콜 → TCP 연결을 확인한다.

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 에서 자신의 서비스에 필요한 것을 설정한다.
	a. 빠른 확인을 위해 interval=10s (Default는 30 권장), failure threshold=1(Default 는 3 권장)로 설정한다.
8. Alarm 연동이 필요한 경우(cloudwatch등) 설정한다.

HealthCheck로도 포트의 연결이 정상임을 확인할 수 있다.

Failover record 생성

  • 호스팅 영역 → 내가 설정한 DNS 주소 클릭 → 레코드 생성(Create Record)

  • 옵션 설정

    	Record name : free (failover로 기입)
	value : IPv4 주소 (13.209.3.228)
	TTL : 60s
	Routing policy : Failover
	Failover record type : Primary(기본)
	Health check ID : 해당 서버의 Health check 입력
	Record ID : free (failover-primary로 기입)

  • failover를 위해서 위와 동일한 과정으로 또 하나의 인스턴스를 열고 Record와 Health check 를 해준다.

  • add another record

    	Record name : free (failover로 기입, 위와 동일한 이름으로 설정)
	value : IPv4 주소 (15.164.97.16)
	TTL : 60s
	Routing policy : Failover
	Failover record type : Secondary(보조)
	Health check ID : 해당 서버의 Health check 입력
	Record ID : free (failover-Secondary로 기입)

먼저 만든 failover DNS의 IP주소를 확인하고 echo 메세지를 날려본다.

MacBookPro ~ % host failover.de-dns.link
failover.de-dns.link has address 13.209.3.228
MacBookPro ~ % echo failovercheck | nc failover.de-dns.link 2000

두 서버 모두 정상일 경우 (이미지 오류)

결과

// primary server에 메세지가 출력
ubuntu@ip-172-31-38-250:~$ nc -l -p 2000 -k
failovercheck

Primary server가 연결이 끊겼을 경우

결과 2

// secondary server에 메세지가 출력
ubuntu@ip-172-31-46-109:~$ nc -l -p 2000 -k
failovercheck

가중치 기반(Weighted) 라우팅

가중치 기반 라우팅의 특징

두 개 이상의 대상에게 가중치 값에 비례해서 트래픽을 분산할 수 있다.

  • 장점

    	활용도가 다양하다.

  • 단점

    	분산의 설정을 Dynamic하게 할 수는 없다. (실시간 변경 x)

사용 예시

  • 장애 대비용으로 미리 구축후 지속적인 사용 ( multi AZ 또는 multi Region을 대상으로 한 경우에 해당 )

  • 새 버전의 Canary Deployment ( 카나리 배포 = 일부만 우선 배포 → 문제가 없으면 전체적으로 배포 ) 로 활용

  • 인프라 규모에 따른 부하 분산

Weighted Routing 테스트

  • Weighted Routing 테스트 위해 EC2 서버 두개를 구동하고 2000번 포트를 연다. 참고
ubuntu@ip-172-31-38-250:~$ nc -l -p 2000 -k
server1 check
ubuntu@ip-172-31-46-109:~$ nc -l -p 2000 -k
server2 check

Weighted Record 생성

  • 호스팅 영역 → 내가 설정한 DNS 주소 클릭 → 레코드 생성(Create Record)

  • 옵션 설정

    	Record name : free (weighted로 기입)
	value : IPv4 주소 (13.209.3.228)
	TTL : 60s
	Routing policy : Weighted (가중치 기반)
	Weight : 8 (10을 총합으로 8만큼 할당)
	Health check ID : 해당 서버의 Health check 입력
	Record ID : free (weighted-8로 기입)

  • Weighted Routing을 위해서 위와 동일한 과정으로 또 하나의 인스턴스를 열고 Record와 Health check 를 해준다.

  • add another record

    	Record name : free (weighted로 기입)
	value : IPv4 주소 (15.164.97.16)
	TTL : 60s
	Routing policy : Weighted (가중치 기반)
	Weight : 2 (10을 총합으로 2만큼 할당)
	Health check ID : 해당 서버의 Health check 입력
	Record ID : free (weighted-2로 기입)

Health Check ( 상태 검사 ) 정상임을 확인

host [DNS] 명령어로 IP 주소를 여러번 호출해 본다.

결과

가중치에 따라 트래픽이 분산 됨을 확인할 수 있다.
13.209.3.228 : 17
15.164.97.16 : 3

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 15.164.97.16

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 15.164.97.16

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 15.164.97.16

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 15.164.97.16

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

MacBookPro ~ % host weighted.de-dns.link
weighted.de-dns.link has address 13.209.3.228

  • 한쪽 서버에 이상이 생긴다면? → 다른 한쪽에 트래픽이 몰린다.

  • 여러대의 가중치 기반 라우팅 중 한대만 이상이 생긴다면? → 나머지 서버의 가중치의 합을 기반으로 트래픽이 분산된다.

지역 기반(Geo) 라우팅

지역 기반 라우팅의 특징

지역을 직접 설정해서, 해당 지역에서 들어온 IP로 판단되면 해당 지역에 매칭되도록 설정한 DNS/IP/server로 라우팅을 해준다.

  • 장점

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

  • 단점

    	지역을 특정할 수 없는 IP가 들어오는 경우 트래픽을 연결할 대상을 지정할 수 있다.
	서비스 구분을 지역 기반 라우팅에 맡겼다면 이런 경우에는 지역을 추론하기 위한 추가 구현이 필요하다.
	지역기반이 가장 좋은(빠른) latency를 제공하지 않을 수도 있다.
		예) 상하이에서 client가 접속을 요청하면, Beijing, Seoul, Tokyo, Singapore 리전 중 어디가 가장 가까울까? 어디가 가장 빠를까?

사용 예시

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

Geo Routing 테스트

Geo 기반은 Health Check가 필수는 아니다.

  • HealthCheck를 등록한 경우, 해당 지역의 모든 record가 unhealthy라면 client 는 host를 찾을 수 없다.

  • 호스팅 영역 → 내가 설정한 DNS 주소 클릭 → 레코드 생성(Create Record)

  • 옵션 설정

    	Record name : free (geo로 기입)
	value : IPv4 주소 (13.209.3.228)
	TTL : 60s
	Routing policy : Geolocation (지리적 위치)
	Location(위치) : Republic of Korea
	Health check ID : x
	Record ID : free (geo-korea로 기입)

  • Weighted Routing을 위해서 위와 동일한 과정으로 또 하나의 인스턴스를 열고 Record와 Health check 를 해준다.

  • add another record

    	Record name : free (geo로 기입)
	value : IPv4 주소 (15.164.97.16)
	TTL : 60s
	Routing policy : Geolocation (지리적 위치)
	Location(위치) : United States
	Health check ID : x
	Record ID : free (geo-us로 기입)

  • 같은 DNS 링크로 한국에서 요청하는 것과 미국에서 요청했을 경우 각기 다른 서버에서 받는다.

그 외 여러가지 라우팅 정책

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

특징

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

  • 장점

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

  • 단점

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

사용 예시

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

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

특징

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

  • 장점

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

  • 단점

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

사용 예시

  • 글로벌 서비스를 런칭하는데 복잡한 설정 없이 각 client에게 빠른 응답속도를 제공하고 싶은 경우.

  • 단, 지역별로 서비스의 배포 구분이 필요 없는 경우.

그 밖의 라우팅 정책

  • IP 기반 라우팅 (ip-based)

  • 다중값 응답 라우팅 (multi-value)

profile
Sonar0
초보 개발자
이전 포스트

DNS와 AWS 개요

다음 포스트

Hadoop 개요

0개의 댓글

관련 채용 정보