Answer

A1 . 서비스 구동 중인 리전의 LB의 서비스가 중단되면 가까운 리전으로 라우팅 되는 정책

시드니 리전의 LB의 서비스가 중단 되면 가까운 리전으로 라우팅 되는 정책은 지연 시간 라우팅 정책이 아닌 장애조치 라우팅 정책으로 판단됩니다.

장애 조치 라우팅 정책은 첫 번째, 두 번째 리소스를 정해두고 첫 번째 리소스가 비정상일 경우 두 번째 리소스로 라우팅합니다.

하지만 첫번째 리소스가 비정상인 경우에만 두번째 리소스로 라우팅 하기 때문에 로드밸런싱 용도로 사용하기에는 어려움이 있습니다.

레코드를 정의할 때 특이한 점은, Failover record type을 'Primary'로 지정할 때 Health check 부분은 정상여부를 확인하기 위해 필수로 기입해야 한다는 점입니다. ('Secondary' 는 Health check 옵션입니다.)

A2. 지연시간 라우팅 정책 동작원리

지연 시간 라우팅 정책은 지연 시간이 가장 낮은 AWS 리전의 리소스로 요청을 라우팅합니다. 여러 AWS 리전에서 서비스를 하고 있다면, 사용자에게 가장 최적의 성능의 서비스를 제공할 수 있는 정책입니다.

예를 들어 Route53은 해당 서비스의 DNS로 요청 했을 때, Seoul과 Virginia region 중 고객 입장에서 보다 낮은 지연 속도(Latency)를 가질 수 있는지 판단하여 지연이 낮은 리전의 주소를 반환합니다.

이해를 돕기 위해 지연시간 라우팅 정책을 사용하여 웹서비스에 접근해 보았습니다.

버지니아 북부 리전과 서울리전에 각각 EC2를 생성 후 index.html 을 생성해 리전명을 넣어주었습니다.

Route53 > 호스팅 영역 > 레코드 생성

저는 현재 한국에 있고 정해준 레코드로 브라우저에 접속했을 때 서울리전의 서비스가 보입니다.

하지만 VPN으로 IP를 우회하여 미국에서 같은 레코드로 접속시 버지니아 북부의 서비스가 보이는걸 확인할 수 있었습니다.

마찬가지로 레코드 이름, 레코드 타입, TTL을 기입하면 레코드에 대한 리전과 라우팅할 AWS 리소스를 지정할 수 있습니다.

[1] 지연 시간 기반 라우팅

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/routing-policy-latency.html

베스핀글로벌 고객지원센터