웹 콘텐츠에 대한 트래픽이 잘못된 CloudFront 엣지 로케이션으로 라우팅되는 이유는 무엇입니까?

최종 업데이트 날짜: 2019년 10월 29일

Amazon CloudFront를 사용하여 웹 콘텐츠를 배포하고 있습니다. 하지만 내 웹 사이트에 대한 트래픽이 잘못된 엣지 로케이션으로 라우팅됩니다. 이 문제를 해결하려면 어떻게 해야 합니까? 

간략한 설명

CloudFront는 배포의 가격 등급, 연결된 지리적 위치 데이터베이스 및 EDNS0-Client-Subnet 지원을 기반으로 트래픽을 라우팅합니다. 이러한 요소의 조합에 따라 웹 사이트의 최종 사용자가 예기치 않은 엣지 로케이션으로 라우팅될 수 있습니다. 이렇게 하면 CloudFront 엣지 로케이션에서 객체를 검색할 때 전반적인 지연 시간이 증가할 수 있습니다.

예기치 않은 엣지 로케이션으로 라우팅되는 문제를 해결하려면 다음을 확인하십시오.

  • 가격 등급은 예상되는 엣지 로케이션을 지원합니다.
  • DNS 해석기는 애니캐스트 라우팅을 지원합니다.
  • DNS 해석기는 EDNS0-Client-Subnet을 지원합니다.

해결 방법

가격 등급은 예상되는 엣지 로케이션을 지원합니다.

CloudFront 배포의 가격 등급에 포함된 엣지 로케이션을 확인합니다. 다른 엣지 로케이션을 포함하려는 경우 배포의 가격 등급을 업데이트할 수 있습니다.

DNS 해석기는 애니캐스트 라우팅을 지원합니다.

DNS 해석기가 애니캐스트 라우팅을 지원하는 경우 DNS 해석기가 사용하는 엣지 로케이션이 여러 개 있습니다. 즉, 요청자의 엣지 로케이션은 최적의 지연 시간을 기반으로 하므로 해석기의 IP 주소에 예기치 않은 위치가 발생할 수 있습니다.

DNS 해석기가 애니캐스트를 지원하는지 확인하려면 다음 명령 중 하나를 여러 번 실행합니다.

참고: 이 예제 명령에서 example.com을 사용 중인 DNS 해석기 도메인 이름으로 바꿔야 합니다.

Linux 또는 macOS에서는 다음과 비슷한 dig 명령을 실행합니다.

dig +nocl TXT o-o.myaddr.l.example.com 

Windows에서는 다음과 유사한 nslookup 명령을 실행합니다.

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

명령을 실행할 때마다 동일한 IP 주소가 출력에 포함되어 있으면 DNS 해석기가 애니캐스트를 지원하지 않습니다. 명령을 실행할 때마다 출력에 다른 IP 주소가 포함되어 있으면 DNS 해석기가 애니캐스트를 지원하므로 예기치 않은 엣지 로케이션을 설명할 수 있습니다.

DNS 해석기는 EDNS0-Client-Subnet 지원

잘못된 라우팅을 방지할 수 있는 방법을 알아보려면 먼저 다음 명령 중 하나를 실행하여 DNS 해석기가 EDNS0-Client-Subnet을 지원하는지 확인하십시오.

참고: 이 예제 명령에서 example.com을 사용 중인 DNS 해석기 도메인 이름으로 바꿔야 합니다.

Linux 또는 macOS에서는 다음과 비슷한 dig 명령을 실행합니다.

dig +nocl TXT o-o.myaddr.l.example.com

Windows에서는 다음과 유사한 nslookup 명령을 실행합니다.

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

참고: TTL 값을 확인하고 TTL이 만료되면 명령을 실행해야 합니다. 그렇지 않으면 재귀 해석기에서 캐시된 응답을 받을 수 있습니다.

DNS 해석기가 EDNS0-Client-Subnet을 지원하지 않는 경우 다음과 비슷한 출력이 표시됩니다.

$ dig +nocl TXT o-o.myaddr.l.example.com  +short
"192.0.2.1"

이전 예제에서 192.0.2.1은 애니캐스트를 사용하는 가장 가까운 DNS 서버의 IP 주소입니다. 이 DNS 해석기는 EDNS0-Client-Subnet을 지원하지 않습니다. 잘못된 라우팅을 방지하기 위해 다음 중 하나를 수행할 수 있습니다.

  • DNS 해석기를 웹 사이트의 클라이언트에 지리적으로 더 가까운 재귀 DNS 확인으로 변경합니다.
  • EDNS0-Client-Subnet을 지원하는 DNS 해석기로 변경합니다.

DNS 해석기가 EDNS0-Client-Subnet을 지원하는 경우 출력에 다음과 유사한 CloudFront 권한 이름 서버에 대한 잘린 클라이언트 서브넷(/24 또는 /32)이 포함됩니다.

$ dig +nocl TXT o-o.myaddr.l.example.com @8.8.8.8 +short
"192.0.2.1"
"edns0-client-subnet 198.51.100.0/24"

이전 예제에서 192.0.2.1은 가장 가까운 DNS 해석기 IP 주소입니다. 또한 클라이언트-서브넷 범위는 DNS 쿼리에 응답하는 데 사용되는 198.51.100.0/24입니다. DNS 해석기가 EDNS0-Client-Subnet을 지원할 때 잘못된 라우팅을 방지하려면 퍼블릭 지리 위치 데이터베이스가 DNS 해석기로 쿼리를 전송하는 클라이언트-서브넷 범위와 연결되어 있는지 확인합니다. DNS 해석기가 잘린 버전의 클라이언트 IP 주소를 CloudFront 이름 서버에 전달하는 경우 CloudFront는 여러 퍼블릭 지리적 위치 데이터베이스를 기반으로 하는 데이터베이스를 확인합니다. IP 주소는 지리적 위치 데이터베이스에서 올바르게 매핑되어야 요청이 올바르게 라우팅됩니다.

DNS 해석기가 EDNS0-Client-Subnet을 지원하는 경우, 먼저 dig와 같은 DNS 조회 명령을 실행하고 CloudFront CNAME을 확인하여 트래픽이 라우팅되는 엣지 로케이션을 확인할 수 있습니다. 

$ dig dftex7example.cloudfront.net. +short
13.224.77.109
13.224.77.62
13.224.77.65
13.224.77.75

그런 다음 이전 명령에서 반환된 IP 주소에 대해 역방향 DNS 조회를 실행합니다.

$ dig -x 13.224.77.62 +short
server-13-224-77-62.man50.r.cloudfront.net.

이전 예제에서는 트래픽이 맨체스터 엣지 로케이션으로 라우팅됩니다.

팁: 추가 테스트를 위해 EDNS0-client-subnet을 지원하는 퍼블릭 DNS 해석기를 사용할 수 있습니다(예: 8.8.8.8 또는 8.8.4.4). 엣지 로케이션 IP 주소가 포함된 쿼리를 퍼블릭 DNS 해석기로 전송합니다. 그런 다음 DNS 쿼리 결과를 확인하여 CloudFront에 EDNS0-client-subnet에 대한 올바른 정보가 있는지 확인합니다.


이 문서가 도움이 되었습니까?

AWS에서 개선해야 할 부분이 있습니까?


도움이 필요하십니까?