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

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

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

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

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

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

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

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

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

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

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

Поэтому, если ваша среда уже состоит из архитектуры Auto Scaling EC2 Instances, простое применение этой маршрутизации на основе задержки должно автоматически решить вашу проблему.

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

Попробуйте 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.

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

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

• https://github.com/ekalinin/awsping

Он написан на голанге и очень прост в использовании:

➥ ./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

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

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

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

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

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

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

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

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

http://www.cloudwatch.in/

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

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

По сути, вы просите Geo DNS.

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

А пока вы можете изучить сторонние решения, такие как Zerigo , которые предоставят вам возможность Geo DNS.

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

РЕДАКТИРОВАТЬ: есть сообщение на ServerFault, в котором говорится о поставщиках Geo DNS

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

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