Route 53에 대해 알아보자 (4)

 

 

☑️ Route53 - 라우팅 정책 종류 살펴보기 (3)

#0 Failover(장애조치 기반 라우팅 정책) 

아래 그림을 빌려

이 정책이 어떻게 동작하는지 알아보자

여기 중간에 Route 53이 있고 EC2 인스턴스가 있다.

하나는 기본 EC2 인스턴스이고 두 번째 보조 EC2 인스턴스 혹은 재해 복구 EC2 인스턴스인데, 이 경우에는 Health Check과 기본 레코드를 필수적으로 연결한다. Health Check가 비정상이면 자동으로 Route53은 두 번째의 EC2 인스턴스로 failover(장애조치)를 하고 결과를 보내기 시작한다!

그리고 보조 EC2 인스턴스도 Health Check를 연결할 수 있지만 기본이랑 보조 각각 하나씩만 있을 수 있다.

클라리언트의 DNS 요청은 정상으로 생각되는 리소스를 자동으로 얻는다. 기본 인스턴스가 정상이면 Route 53도 기본 레코드로 응답한다. 그런데 Health Check가 비정상이면 failover에 도움이 되는 두 번째 레코드의 응답을 자동으로 얻게 되는 흐름이라고 보면 충분하다.

 

#1 Gelolcation (지리 위치 기반 라우팅 정책)

Latency-based(지연 시간 기반) 정책과는 많이 다르게 사용자의 실제 위치를 기반으로 한 라우팅 정책이다.

예를 들어 사용자가 특정 국가, 미국의 경우에는 어떤 주에 있는지 지정하는 것이고 가장 정확한 위치가 선택돼서 그 IP로 하우팅 되는 것이다.

(일치하는 위치가 없는 경우에는 기본 레코드를 생성해야 하는 부분)

 

➕) 사용 사례 :

콘텐츠 분산을 제한하고 로드 밸런싱 등을 실행하는 웹사이트를 현지화시킬 때

-> 이런 레코드는 Health Check와 연결할 수 있다!

 

독일의 유저가 독일어 버전의 앱을 포함한 IP로 접속되도록 독일의 지리 레코드를 정의할 수도 있다. 그리고 만약 프랑스의 경우라면 프랑스어 버전의 앱을 가진 IP로 가야한다.

 

#2 Geoproximity (지리 근접 기반 라우팅 정책) 

Geoproximity는 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅하도록 한다.

이 정책으로 편향값(Bias)을 사용해서 특정 위치를 기반으로 리소스를 더 많은 트래픽으로 이동하는 것이다! 

=> 그래서 지리적 위치를 변경하려면 편향값을 지정해줘야 하는데 특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜서 확장하면 된다. (반대로 리소스에 트래픽을 줄이려면 편향값을 음수로 축소)

여기서 말하는 리소스는 AWS 리소스인데 속한 특정 region을 지정하면 목록에서 자동으로 올바른 라우팅을 계산하거나 AWS 리소스가 아닌 온프레미스 데이터 센터인 경우에 위도와 경도를 지정해서 AWS가 위치를 파악하도록 해야 한다. 그리고 기능을 선택하는데 편향 활용을 위해 고급 Route 53 트래픽 플로우를 사용한다.

...

그림으로 좀 더 설명해보려고 한다. 왼쪽 그림을 먼저 같이 살펴보자

us-west-1의 리소스와 us-east-1의 리소스를 예로 각 리전의 편향값(Bias)은 0으로 설정됐다고 했을 때, 이는 미국 전역의 사용자가 이 리소스에 액세스를 시도하며 미국을 둘로 나눈다는 뜻이다. (왼쪽의 사용자는 us-west-1로 이동하고 오른쪽 사용자는 us-east-1로 이동)

그런데 오른쪽 그림같이 us-east-1에 50이라는 양수의 편향값을 가지면 해당 리소스에 더 많은 사용자와 트래픽이 발생하는 것이니 이런 개념으로 가져가면 좋다..! 

 

#3 IP based Routing (IP 기반 라우팅 정책) 

이름에서 알 수 있듯이 클라이언트 IP 주소를 기반으로 라우팅을 정의한다.

Route53에서 CIDR에 따라 트래픽을 어느 location으로 보내야할지를 정한다.

=> 이걸 사용하면 IP를 미리 알고 있으니 성능을 최적화할 수 있다! 그리고 어디서 오는지 아니까 네트워크 비용도 ↓

=> 예를 들어 특정 인터넷 제공업체가 특정 IP 주소 셋을 사용하는 걸 안다면 특정 엔드포인트로 라우팅할 수 있다.

그림으로 더 설명해보자면 Route53에서 두 로케이션을 서로 다른 두 CIDR 블록으로 가정해본다.

하나는 203으로 시작하고 다른 하나는 200으로 시작한다.

=> 그러면 IP범위도 정의된다.

그리고 이제 로케이션을 레코드에 연결시킬건데 첫 번째 CIDR 블록을 값 1,2,3,4로 보내고 두 번째 로케이션에서는 두 번째 CIDR 블록을 5,6,7,8로 보낸다. 이 값들은 두 개의 EC2 인스턴스의 공용IP를 나타낸다.

사용자 A가 로케이션 1 CIDR블록에 속하는 특정 IP로 들어오면 첫 번째 EC2 인스턴스인 IP 1,2,3,4로 보내진다. 두 번째 로케이션에 속하는 IP 주소로 들어오면 5,6,7,8로..! => 이렇게 되면 EC2 인스턴스에 대한 DNS 쿼리 응답을 받게 된다.

 

#4 Multi - Value (다중 값 기반 라우팅 정책)

트래픽을 다중 리소스로 라우팅할 때 사용하는데 Route53은 다중 값과 리소스를 반환한다.

그리고 Health Check와 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 Health Check와 관련이 있다.

각각의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환된다.

ELB와 유사해보이지만 이걸로 대체할순 없고 클라이언트 측면의 로드 밸런싱인 것이다.

example.com에서 다중 A 레코드를 설정하고 Health Check와 연결하겠다.

클라이언트에서 다중 값 쿼리를 실행하면 반환되는 8개 레코드 중 1개 혹은 푀대 8개의 레코드가 정상일 것을 알고 있다. 그래서 클라이언트는 안전한 쿼리를 가질 수 있다. 그러나 이 위의 예시 사진은 조금 다르다. 다중 값이 있는 단순한 라우팅의 경우에는 simple 라우팅 정책의 쿼리가 반환하는 리소스 중 하나는 비정상일 가능성이 있다🤧

=> 그래서 다중 값이 조금 더 강력한 레코드 유형인 이유이다.