Route53 LBR에 대해서 질문 드려 봅니다. (Latency Based Routing -…

Route53 LBR에 대해서 질문 드려 봅니다. (Latency Based Routing – aka LBR)
LBR은 client에서 시작한 DNS look up 요청에 대해서, client와 가까이 있는 서버의 주소를 return하는 서비스로 알고 있습니다.

통상적으로 DNS 서비스는 계층형 구조로, 사내 서버 –> ISP 서버 –> Route 53 등의 DNS Hierachy를 가지고 있고, 각 DNS 서버들이 DNS 레코드를 캐슁 하는 것으로 알고 있습니다.

질문을 LBR을 사용할 시, 사용자 A가 가까운 서버의 위치를 받았을때, 그 서버 위치 레코드가 사내 서버나 ISP 서버등 Route 53의 하위 서버에 캐슁이 될것으로 생각되는데.

만약 이 상황에서 사용자 B가 다른 region에서 같은 DNS 서버를 사용해서 look up을 할 경우, 캐쉬되어 있는 레코드를 리턴하기 때문에, 사용자 B에 최적화된 주소가 오지 않을 것으로 생각됩니다.

즉 LBR은 이론적으로만 봤을때는 사용자단 DNS 서버의 위치를 기반으로 LBR이 될 것 같은데, AWS 메뉴얼에서는 사용자의 위치를 기반으로 하는 것 처럼 설명하고 있습니다.

or example, suppose you have Elastic Load Balancing load balancers in the US West (Oregon) region and in the Asia Pacific (Singapore) region and that you’ve created a latency resource record set in Route 53 for each load balancer. An end user in London enters the name of your domain in a browser, and the Domain Name System routes your request to a Route 53 name server. Route 53 refers to its data on latency between London and the Singapore region and between London and the Oregon region. If latency is lower between London and the Oregon region, Route 53 responds to the end user’s request with the IP address of your load balancer in the Amazon EC2 data c

http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/CreatingLatencyRRSets.html

제 생각에는 사용자의 위치를 기반으로 할려면 Route53과 사용자 사이의 DNS 서버들이 레코드를 caching하지 말아야 할텐데. 좀 애매하네요.

어떤 원리로 작동 하는 건지 혹시 아시는분이나 경험하신분 공유 부탁드립니다.

6 thoughts on “Route53 LBR에 대해서 질문 드려 봅니다. (Latency Based Routing -…

  1. 해당 레코드의 TTL 값을 확인 해보시면 아시겠죠 …

    매우 낮은 값의 TTL 을 가지고 있을텐데 설마 수 분 사이에 사용자나 서비스 위치가 바뀌진 않겠지요?…

  2. 보통 유의한 수준의( 60초 혹은 그 이하 의 수준) TTL 값을 가져도 충분하리라 보여집니다.

    설사 많은 수의 요청이 온다고 해도 최악의 시나리오가 발생하여 레코드 정보가 캐슁 된다고 하여도 (아주 크게 잡지 않았다면 ) 수 분내에 갱신이 될 테니 우려하실 만한 문제는 생기지 않겠지요.

    물론 그 만큼 DNS query 가 많이 들어오겠지만 그것은 AWS 의 성능을 믿어 볼 수 밖에 없겠죠.

  3. 한국에 있는 DNS 서버를 쓰는 시나리오에서 사용자 A가 한국에서 look up을 하고, 동시에 다른 사용자 B가 일본에서 look up 했을때, DNS local cache가 한국 사용자에 의해서 한국쪽 서비스로 update 되었다면, 일본 사용자는 캐쉬에 의해서 한국 서비스로 붙게 되겠지요. DNS 캐쉬는 여러 사용자를 위한 것이 아니니까요.

  4. http://www.netmanias.com/bbs/view.php?id=blog&no=348

    역자 주 1: 정확한 Network Proximity 측정을 위해서는 측정 구간이 “SLB ~ Local DNS 서버”가 아닌 “SLB ~ 사용자 단말”이어야 하겠으나, 현 DNS 프로토콜 표준은 사용자의 IP 주소를 상위 DNS 서버(여기서는 GSLB)로 전달하지 않습니다. 따라서 GSLB가 사용자 단말의 IP 주소를 알 수 없어 Local DNS 서버로 대신합니다. 하지만 보통 DHCP를 통해 IP 주소를 할당 받는 사용자 단말 환경에서는 사용자와 인접한 DNS 서버가 설정되기 때문에 Network Proximity 측면에서 큰 문제는 없습니다. (예. 한국 KT망 사용자는 DHCP에 의해서 KT DNS 서버가 Local DNS로 자동 설정이 되고, 미국 AT&T 사용자는 AT&T DNS 서버가 Local DNS로 자동 설정됨)


    홍성진 그래서 DNS 프로토콜 표준을 개선하려고 몇년전부터 구글을 포함한 CDN업체들이 edns-client-subnet 기능을 구현하고 있습니다. ISP등의 중간 DNS 요청시 클라이언트의 IP subnet을 같이 전송하도록 하는것이죠. http://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/#cdns

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.