답변:
TurnKey Linux 의 현명하고 혁신적인 사람들은 최근 문제에 대한 솔루션을 오픈 소스로 제공했습니다 . GitHub에서 AWS 지역 데이터 센터 매핑 을 참조하십시오 .
이 프로젝트는 TurnKey Hub 가 사용자에게 가장 가까운 AWS 데이터 센터 를 찾는 데 사용 하는 인덱스 (및 참조 용 시각적 맵) 를 생성하는 데 사용됩니다 . [내 강조]
사용중인 알고리즘은 GeoIP 및 인덱싱 을 사용하여 가장 가까운 데이터 센터 찾기 및 GeoIP 및 인덱싱을 사용하여 가장 가까운 APT 패키지 아카이브 찾기 후속 게시물에 자세히 설명되어 있습니다.
약간의 속임수이지만 시각화 는 매우 멋지고 resp를 확인합니다. 조쉬가 이미 언급 한 놀라운 사실에 대한 이유를 보여줍니다. 즉, 호주 사용자는 현재 아시아 태평양 (싱가포르 / ap-southeast)이 아닌 미국 서부 (캘리포니아 북부 / us-west-1)를 통해 지연 시간이 더 길어지는 경향이 있습니다. -1) 지역. ( 팁 : 오른쪽 하단에있는 Future Cables 를 확인 하면 이것이 변경 될 가능성이 있음을 보여줍니다. 이는 Greg의 Cable Map에 자세히 설명되어 있습니다. 이는 오스트레일리아가 앞으로 몇 년 동안 두 AWS 위치간에 지연 시간이 현명하게 이동할 수 있음을 나타냅니다.)
한편 AWS는 가용 영역 수 및 API 엔드 포인트와 같은 각 세부 정보와 함께 빠른 평가를 위해 글로벌 인프라 를 보여주는 유용한지도를 제공 합니다.
더 중요하지만, AWS 그냥 Jahufar는 지리적 DNS 지원을 발표했다 언급 이미를 소개 포스트를 참조 AWS 멀티 - 지역 대기 시간 기반 라우팅 지금 가능한 , 힘이 같은 지연 시간 기반 라우팅 기술을 사용할 수 있도록되어 아마존 CloudFront를 사용자에게 아마존 EC2 , Elastic Load Balancing 등.
따라서 환경이 이미 Auto Scaling EC2 인스턴스 아키텍처로 구성된 경우이 지연 시간 기반 라우팅을 적용하기 만하면 문제가 자동으로 해결됩니다.
사용 사례는 분명히 여러 AWS 리전을 생성하는 오퍼링을 대상으로하지만 지연 시간 기반 라우팅 및 가중치 기반 라운드 로빈 레코드 세트와 관련된 정교한 기능 을 사용하면 원하는 정보를 직접 쉽게 결정할 수 있습니다.
cloudping.info를 시도 하면 브라우저에서 각 AWS 리전으로 HTTPS 핑을 수행합니다.
Region Latency
US-East (Virginia) 28 ms
US-West (California) 100 ms
US-West (Oregon) 110 ms
Europe (Ireland) 100 ms
Europe (Frankfurt) 119 ms
Asia Pacific (Singapore) 269 ms
Asia Pacific (Sydney) 239 ms
Asia Pacific (Japan) 209 ms
South America (Brazil) 147 ms
속도 테스트를위한 웹 사이트도 있습니다 : https://cloudharmony.com/speedtest 어느 지역이 가장 적합한 지 쉽게 확인하고 싶다면.
다음은 가장 가까운 aws 리전을 보여주는 콘솔 도구입니다.
golang으로 작성되었으며 사용하기 매우 쉽습니다.
➥ ./awsping --verbose 1
Code Region Latency
0 eu-central-1 Europe (Frankfurt) 36.97 ms
1 eu-west-1 Europe (Ireland) 63.18 ms
2 us-east-1 US-East (Virginia) 126.52 ms
3 ap-south-1 Asia Pacific (Mumbai) 156.98 ms
4 us-west-1 US-West (California) 192.92 ms
5 us-west-2 US-West (Oregon) 226.23 ms
6 sa-east-1 South America (São Paulo) 247.74 ms
7 ap-northeast-1 Asia Pacific (Tokyo) 312.22 ms
8 ap-northeast-2 Asia Pacific (Seoul) 329.54 ms
9 ap-southeast-2 Asia Pacific (Sydney) 337.84 ms
10 ap-southeast-1 Asia Pacific (Singapore) 395.73 ms
지역은 지연 시간에 따라 정렬됩니다.
모든 서버에서 실행하고 가장 가까운 지역을 결정할 수 있습니다.
다른 지역에 대한 지연 시간을 테스트하는 것은 당연히 권장됩니다! 저는 호주에 있으며 여기에있는 많은 사용자들이 싱가포르보다 미국 서부에서 더 나은 대기 시간을 얻습니다. 부분적으로는 로컬 ISP 피어링 및 국제 연결로 귀결됩니다. 대상 지역에 사용자가 있는지 테스트하는 것은 비교적 간단합니다.
AWS 측의 안정성 (즉, 사용자 네트워크 문제가 아님)은 대부분 여러 가용 영역에 배포 한 결과입니다. 단순히 해당 시장에 더 오래 서비스를 제공했기 때문에 APAC 지역보다 미국 지역에 더 많은 선택권이 있습니다. 이로 인한 부작용은 기능이 싱가포르 / 도쿄에 비교적 늦게 배포된다는 것입니다. 일반적으로 새로운 기능은 미국 동부에서 출시되기 시작합니다.
이미 S3 및 EC2를 사용하려는 서비스로 염두에두고 있으며 둘 다 가까운 리전에서 사용할 수 있으므로 AWS의 최신 웹 서비스가 즉시 중요한지 평가하십시오.
Amazon은 이제 가장 낮은 최종 사용자 지연 시간을 기반으로 데이터 센터로 라우팅하는 기능을 제공합니다. Route53의 새로운 "지연 기반 라우팅"입니다!
http://docs.amazonwebservices.com/Route53/latest/DeveloperGuide/CreatingLatencyRRSets.html
편집 : Mark Tsai의 대답을보십시오. 그게 갈 길입니다 (Route 53은 내가 이것을 작성할 때 존재하지 않았습니다)
이것은 아마도 ServerFault에 속하지만 여기에 있습니다.
기본적으로 요구하는 것은 Geo DNS입니다.
지금은 AWS에서 직접 지원되지 않습니다. 일부 AWS 포럼 게시물 에서 구현되는 이야기를 보았지만 대부분의 경우 Route 53 서비스에서 가능합니다.
그때까지는 Geo DNS 기능을 제공하는 Zerigo 와 같은 타사 솔루션을 살펴볼 수 있습니다.
또는 하드 코어라면 IP2Location으로 BIND를 구성하여 직접 롤링 할 수 있습니다.
편집 : Geo DNS 공급자에 대해 이야기하는 ServerFault에 대한 게시물이 있습니다.
성능 및 AWS 안정성에 관한 질문 : 가장 가까운 AZ에서 사용자에게 사이트를 제공하는 것을 고려해야합니다. 속도 측면에서 모든 인스턴스를 단일 AZ에 두지 않는 것이 좋습니다. 당신은 확인할 수 있습니다 AWS 서비스 상태 대시 보드를 아마존의 서비스가 다른 AZS에 얼마나 신뢰할 수있는 일반적인 아이디어를 얻을. 이 데이터는 Amazon에서 직접 가져온 것입니다. 다른 곳에서는 독립적 인 통계를 본 적이 없습니다.
http://blog.datapath.io/aws-network-latency-map 에서는이 정보를 얻을 수있는 상업용 제품에 대해 설명합니다. 지정한 위치에서 지정한 AWS 서비스까지의 지연 시간을지도에 표시합니다.
