Как я могу определить, какое местоположение AWS лучше всего подходит для обслуживания клиентов из определенного региона?

У AWS есть несколько мест для хранения и экземпляры EC2 для работы с разными ценами. Как я могу определить, какое местоположение лучше всего подходит для определенного региона. Является ли он интуитивным (ближе к вашему обслуживающему региону лучше) или есть какие-либо проблемы с надежностью (конкретное местоположение AWS больше подвержено перебоям, чем другие). Существуют ли какие-либо данные для принятия такого решения?

Я разрабатываю приложение, которое в основном предназначено для индийских клиентов. Поэтому я рассматриваю Сингапур или Токио как вариант.

Ответ 1

Определение местоположения AWS с наименьшей задержкой для пользовательского использования

Умные и новаторские люди из TurnKey Linux недавно открыли свое решение своей проблемы, см. Отображение региональных центров данных AWS на GitHub:

Этот проект используется для создания индексов (и визуальная карта для ссылка), используемая TurnKey Hub для найти ближайший центр обработки данных AWS для пользователя. [акцент мой]

Используемый алгоритм подробно описан в Поиск ближайшего центра обработки данных с использованием GeoIP и индексации, а также последующее сообщение Поиск ближайшего архива пакетов APT с использованием GeoIP и индексации.

Пока немного трюк, визуализация , упомянутого уже, а именно, что пользователи в Австралии в настоящее время имеют тенденцию улучшать латентность через Запад США (Северная Калифорния/США-Запад -1), а не в Азиатско-Тихоокеанском регионе (Сингапур/ап-юго-восток-1). ( Совет: проверка будущих кабелей в нижнем правом углу показывает, что это, вероятно, изменится, что более подробно описано в Greg Cable Map, что указывает на то, что Австралия может перепрыгнуть между местами временного охвата AWS в ближайшие годы;)

Автоматическое использование местоположения AWS с наименьшей задержкой через Amazon Route 53

В то же время AWS предоставляет полезную карту, иллюстрирующую их Глобальную инфраструктуру для быстрой оценки наряду с соответствующими подробностями, например, количество зон доступности и конечная точка API.

Более того, AWS только что анонсировала уже существующую географическую DNS-поддержку Jahufar , см. вводный пост Маршрутизация с несколькими регионами на основе латентности теперь доступна для AWS, которая предоставляет ту же технологию маршрутизации на основе латентности, которая обеспечивает Amazon CloudFront пользователям Amazon EC2, Эластичная балансировка нагрузки и многое другое.

Итак, в случае, если ваша среда состоит из архитектуры экземпляров ECS, просто применяя эту маршрутизацию на основе задержки, вы должны решить вашу проблему автоматически.

В то время как использование прецедента явно нацелено на предложения, порождающие несколько областей AWS, сложные функции, связанные с маршрутами на основе латентности и взвешенными круглыми наборами записей Robin, могут также легче определить вашу желаемую информацию.

Ответ 2

Существует также веб-сайт для теста скорости: https://cloudharmony.com/speedtest, если вы легко хотите проверить, какой регион лучше всего подходит вам.

Ответ 3

Попробуйте cloudping.info

Он будет выполнять HTTP-запрос из вашего браузера в каждый регион AWS.

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

ПРИМЕЧАНИЕ для админов SO: я не связан с этой службой. Я нашел его при подготовке к сертификации AWS.

Ответ 4

Желательно проверить задержку в разных регионах! Я нахожусь в Австралии, и многие пользователи здесь получают более высокую задержку для США, чем в Сингапуре, - отчасти это сводится к местным интернет-провайдерам и международным связям. Это относительно просто проверить, если у вас есть пользователи в регионе, на который вы нацелились.

Надежность на стороне AWS (т.е. проблемы с сетью пользователя) в основном является следствием развертывания в нескольких зонах доступности. В регионах США больше выбора, чем в APAC, потому что они больше обслуживают эти рынки. Побочным эффектом этого является то, что функции развертываются относительно поздно в Сингапур/Токио - обычно новые функции начинают развертываться на Востоке США.

Поскольку у вас уже есть S3 и EC2 в качестве сервисов, которые вы хотели бы использовать, и они оба доступны в более близких регионах, оцените, важны ли новые веб-сервисы от AWS - если нет, отстрелитесь за что-то (задержка) рядом.

Ответ 5

Amazon теперь предлагает возможность маршрутизации в центр обработки данных, основанный на низкой задержке для конечных пользователей. Это Route53 новая "Маршрутизация на основе латентности"!

http://docs.amazonwebservices.com/Route53/latest/DeveloperGuide/CreatingLatencyRRSets.html

Ответ 6

Здесь консольный инструмент, который показывает ближайшую область aws:

https://github.com/ekalinin/awsping

Он написан в 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

Регионы упорядочиваются по задержке.

Вы можете запустить его на любом сервере и определить для себя ближайший регион.

Ответ 7

РЕДАКТИРОВАТЬ: Посмотрите на ответ Марка Цай. Это способ пойти (маршрут 53 не существовал, когда я написал это)

Вероятно, это относится к ServerFault, но здесь:

В основном вы запрашиваете Geo DNS.

Прямо сейчас он не поддерживается непосредственно в AWS - хотя я видел некоторые разговоры о том, что он реализован в некоторых сообщениях форума AWS - большинство вероятно, в службе Route 53.

До тех пор вы могли бы изучить сторонние решения, такие как Zerigo, которые предоставят вам средство Geo DNS.

Или, если вы хардкор, вы можете катиться самостоятельно, настроив BIND с IP2Location

EDIT: есть сообщение на ServerFault, в котором рассказывается о поставщиках Geo DNS

Что касается вашего вопроса относительно производительности и надежности AWS: вы должны рассмотреть возможность обслуживания своего сайта от ближайшего AZ до вашего пользователя - это имеет смысл с точки зрения скорости и отсутствия всех ваших экземпляров в одном AZ. Вы можете проверить AWS Service Health Dashboard, чтобы получить общее представление о том, насколько надежны службы Amazon в разных AZ. Обратите внимание, что эти данные прямо из Amazon - я не видел никакой независимой статистики где-либо еще.

Ответ 8

Хороший инструмент/сайт для проверки задержки из нашего местоположения

http://www.cloudwatch.in/

Ответ 9

http://blog.datapath.io/aws-network-latency-map обсуждает коммерческое предложение, чтобы получить эту информацию. Он показывает время ожидания от указанного вами местоположения, к заданию AWS, которое вы указываете, на карте.