지연 시간 기반 리소스 레코드와 Route 53의 문제를 해결하려면 어떻게 해야 합니까?

최종 업데이트 날짜: 2021년 5월 20일

Amazon Route 53의 지연 시간 기반 라우팅이 클라이언트로부터 지리적으로 멀리 떨어진 AWS 리전에 있는 서버를 반환합니다. 예를 들어, 미국에 있는 사용자가 내 웹 사이트에 액세스하려고 하면 Route 53은 유럽에 있는 서버의 IP 주소를 반환합니다. 클라이언트가 먼 곳의 리전으로 라우팅되지 않게 하려면 어떻게 해야 합니까?

간략한 설명

다음 조건이 충족될 경우, Route 53은 DNS 쿼리 위치를 기준으로 지연 시간이 가장 짧은 리전을 선택합니다.

Route 53는 다음에 따라 지연 시간 기반 라우팅을 만듭니다.

  • 쿼리를 Route 53 권한 이름 서버에 전송하는 재귀 DNS 확인자의 소스 IP 주소
  • 클라이언트 IP 주소의 잘린 버전(DNS 확인자가 확장 EDNS0-Client-Subnet을 지원하는 경우)

Route 53 네임 서버는 기본적으로 EDNS0-Client-Subnet을 지원합니다. EDNS0-Client-Subnet을 지원하는 재귀 DNS 확인자는 잘린 버전의 클라이언트 IP 주소를 Route 53으로 보냅니다. 그러면 Route 53은 그 잘린 IP 주소를 사용하여 지연 시간이 가장 짧은 리전을 결정합니다.

지연 시간이 가장 짧은 리전이 DNS 확인자와 물리적으로 가장 가까운 리전이 아닐 수 있습니다. 클라이언트가 DNS 확인자와 동일한 위치에 있지 않으면 원치 않는 라우팅 동작이 발생할 수 있습니다. 확인자의 IP 주소에 다른 위치 정보가 있으면 원치 않는 라우팅 동작이 발생할 수도 있습니다.

시나리오 예

한 회사가 버지니아(us-east-1) 및 다른 한 회사가 아일랜드(eu-west-1)에 있는 두 개의 Elastic Load Balancer에 대한 지연 시간 기반 라우팅 레코드를 가지고 있습니다. 미국에 있는 사용자는 유럽에 있는 회사 DNS 확인자를 사용하거나, VPN을 통해 유럽에 있는 회사 사무실에 연결합니다.

회사 DNS 확인자가 권한 이름 서버에 EDNS0-Client-Subnet 데이터를 보낼 수 없는 경우 Route 53은 유럽에 있는 DNS 확인자 IP 주소를 쿼리 소스로 간주합니다. 그런 다음 Route 53는 지연 시간 데이터베이스에서 조회를 수행하고 아일랜드에 있는 로드 밸런서의 지연 시간이 가장 짧다고 잘못 결정합니다.

하지만 회사 DNS 확인자가 EDNS0-Client-Subnet 데이터를 전송할 수 있는 경우 Route 53은 미국에서 잘린 클라이언트 IP 주소를 쿼리 소스로 간주합니다. Route 53는 지연 시간 데이터베이스에서 조회를 수행하고 버지니아에 있는 로드 밸런서의 지연 시간이 가장 짧다고 올바르게 결정합니다.

해결 방법

다음 단계에 따라 원치 않는 지연 시간 기반의 라우팅 동작 문제를 해결하십시오.

1.    DNS 확인자가 사용하는 IP 주소 범위를 확인합니다. Linux/macOS의 경우 루프에서 dig 명령을 실행합니다. Windows에서는 nslookup 명령을 여러 번 실행하고 매번 출력을 기록해야 합니다.

Linux 또는 macOS에서는 dig를 사용합니다.
for i in {1..10}; do dig TXT o-o.myaddr.l.google.com +short; sleep 61; done;

Windows에서는 nslookup을 사용합니다.

nslookup -type=txt o-o.myaddr.l.google.com

2.    DNS 확인자가 애니캐스트를 지원하는지 출력을 통해 확인합니다. 출력에 항상 동일한 단일 IP 주소가 포함되는 경우 DNS 확인자는 애니캐스트를 지원하지 않습니다. 명령을 여러 번 실행할 때 IP 주소가 변경되는 경우 DNS 확인자는 애니캐스트를 지원합니다.

DNS 확인자가 애니캐스트를 지원하는 경우 DNS 확인자에 대한 엣지 로케이션이 여러 개 있습니다. 사용자의 엣지 로케이션은 최적의 지연 시간을 기반으로 선택되므로 확인자의 IP 주소에 예기치 않은 위치가 발생할 수 있습니다.

3.    클라이언트의 IP 주소를 찾습니다. 클라이언트 컴퓨터에서 인터넷 브라우저를 열고 https://checkip.amazonaws.com/으로 이동합니다.

아니면 curl을 사용합니다.

curl https://checkip.amazonaws.com/

4.    다음 명령 중 하나를 사용하여 DNS 확인자가 EDNS0-Client-Subnet을 지원하는지 점검합니다. 출력을 기록해 둡니다.

Linux 또는 macOS에서는 dig를 사용합니다.
dig +nocl TXT o-o.myaddr.l.google.com @<DNS Resolver>

Windows에서는 nslookup을 사용합니다.

nslookup -type=txt o-o.myaddr.l.google.com <DNS Resolver>

5.    출력의 Answer 섹션에 반환된 첫 번째 TXT 레코드를 점검합니다. 이 값이 애니캐스트를 광고하는 가장 가까운 DNS 서버입니다. 두 번째 TXT 레코드가 없는 경우 DNS 확인자는 EDNS0-Client-Subnet을 지원하지 않습니다. 두 번째 TXT 레코드가 있는 경우 DNS 확인자는 EDNS0-Client-Subnet을 지원합니다. 확인자는 잘린 클라이언트 서브넷(/24 또는 /32)을 Route 53 권한 이름 서버로 전송합니다.

(선택 사항) 호스팅 영역에서 Route 53 DNS 쿼리 로깅을 활성화한 경우 테스트 레코드를 생성합니다. 그런 다음 새 레코드에 대한 DNS 조회를 수행합니다. 쿼리 로그를 확인하여 Route 53 이름 서버에 표시되는 확인자 IP 주소와 EDNS0-Client-Subnet(있는 경우)을 확인합니다.

6.    응답의 TTL 값이 60초인지 확인합니다. TTL이 60초가 아닌 경우 응답은 캐시된 응답입니다. 응답 TTL 값이 60초가 될 때까지 dig 또는 nslookup 명령을 반복합니다.

7.    Route 53 DNS 확인 도구에 액세스할 수 있으면 특정 DNS 확인자 또는 클라이언트 IP 주소에서 오는 쿼리를 시뮬레이션합니다. 이러한 쿼리를 사용하여 Route 53이 반환하는 지연 시간 리소스 레코드 세트를 찾아 냅니다.

DNS 확인자가 EDNS0-Client-Subnet을 지원하지 않는 경우 도구에서 Resolver IP address(확인자 IP 주소)를 값으로 지정합니다.

DNS 확인자가 EDNS0-Client-Subnet을 지원하는 경우 도구에서 EDNS0 client subnet IP(EDNS0 클라이언트 서브넷 IP)를 값으로 지정합니다. [추가 구성(Additional configuration)]을 선택한 다음 서브넷 마스크를 지정합니다.

참고: 이 도구는 Route 53 지연 시간 측정 데이터베이스를 직접 쿼리하여 AWS 리전과 인터넷 기반 네트워크 간에 미리 계산된 지연 시간을 확인합니다. 이 도구는 인터넷을 통해 또는 DNS 확인자에 DNS 쿼리를 전송하지 않습니다. 이 도구는 DNS 확인자가 EDNS0-Client-Subnet을 지원하는지 여부를 확인하지 않습니다. 이 도구와 실제 DNS 쿼리의 결과가 다를 수 있습니다.

8.    (선택 사항) Route 53 DNS 확인 도구에 액세스할 수 없는 경우 dig를 사용합니다. dig를 사용하여 Route 53 신뢰할 수 있는 이름 서버에 EDNS0-Client-Subnet이 있는 호스팅 영역을 쿼리합니다. 이제 그 출력을 사용하여 소스 IP 주소에서 지연 시간이 가장 짧은 리전을 결정합니다.

dig lbr.example.com +subnet=<Client IP>/24 @ns-xx.awsdns-xxx.com +short

참고: 인터넷에서 호스트 간의 지연 시간은 네트워크 연결 및 라우팅 변경으로 인해 시간이 지나면 바뀔 수 있습니다. 예를 들어 이번 주 오레곤 리전으로 라우팅된 요청은 다음 주에 오하이오 리전으로 라우팅될 수 있습니다.

9.    EDNS0-Client-Subnet을 지원하지 않는 확인자라면 클라이언트의 DNS 확인자를 클라이언트와 지리적으로 더 가까운 다른 재귀 DNS 확인자로 변경합니다. 확인자가 EDNS0-Client-Subnet을 지원하지 않는 경우 클라이언트 DNS 쿼리는 클라이언트와 다른 지리적 위치의 DNS 확인자를 사용할 수 있습니다. 이 시나리오에서 예기치 않은 라우팅 동작이 발생합니다.

DNS 확인자를 관리하는 경우 전달 구성을 확인합니다. 클라이언트의 지리적 위치에서 멀리 떨어진 다른 해결 프로그램으로 DNS 쿼리를 전달하지 않는지 확인합니다.

EDNS0-Client-Subnet을 지원하는 확인자의 경우 클라이언트 서브넷 IP 주소의 지리적 위치를 확인합니다. 위치를 확인하려면 MaxMind 웹 사이트의 GeoIP 데이터베이스 또는 선호하는 GeoIP 데이터베이스를 사용합니다. 클라이언트 서브넷 IP 주소의 위치가 클라이언트와 다른 지리적 위치에 있는 경우 고객에게 예기치 않은 라우팅 동작이 발생할 수 있습니다.

10.    (선택 사항) DNS 확인자가 EDNS0-Client-Subnet을 지원하지 않는 경우, EDNS0-Client-Subnet을 지원하는 퍼블릭 재귀 DNS 확인자로 변경합니다. 그런 다음, Route 53의 기존 지연 시간 라우팅 응답 결과를 새로운 결과와 비교합니다. 예를 들어 현재 EDNS0-Client-Subnet을 지원하는 두 가지 퍼블릭 DNS 확인자는 GoogleDNS(8.8.8.8 및 8.8.4.4)와 OpenDNS(208.67.222.222 및 208.67.220.220)입니다.

11.    (선택 사항) 지연 시간 기반 라우팅 레코드가 Route 53 상태 확인과 연결되어 있는지, 별칭 레코드의 경우 대상 상태 평가가 활성화되어 있는지 확인합니다. 하나 또는 둘 다 true인 경우 Route 53는 대기 시간이 가장 짧은 정상 엔드포인트를 반환합니다. 모든 상태 확인에 실패하면 라우팅 정책만 고려됩니다.

Route 53 콘솔에서 Route 53 상태 확인의 상태를 확인합니다. 대상 상태 평가(ETH)가 활성화된 경우 레코드 엔드포인트의 상태를 확인합니다. Route 53은 하나 이상의 백엔드 인스턴스가 정상인 경우 ETH가 활성화된 Classic Load Balancer의 엔드포인트를 정상으로 간주합니다. Application 및 Network Load Balancer의 경우 대상이 있는 모든 대상 그룹에는 정상으로 간주될 정상 대상이 하나 이상 포함되어야 합니다. 등록된 대상이 없는 대상 그룹은 비정상으로 간주됩니다. 비정상 대상만 포함된 대상 그룹에 있으면 로드 밸런서는 비정상으로 간주됩니다. 예외: Application Load Balancer에 정상 대상 그룹이 하나 이상 있고 나머지 모든 대상 그룹이 비어 있는 경우 Route 53은 이를 정상으로 간주합니다.

예를 들어, Route 53 상태 확인이 연결된 두 개의 지연 시간 기반 라우팅 레코드가 있다고 가정해 보겠습니다. 하나는 오레곤주에 있고 다른 하나는 버지니아 북부에 있습니다. 오레곤 엔드포인트의 상태 확인이 실패하면 클라이언트의 위치에 관계없이 모든 요청이 버지니아 북부 엔드포인트로 라우팅됩니다.