Сверхнизкая задержка в тех местах, где она нужна больше всего
Представьте себе: вы только что закончили настройку нового инстанса EC2. Все шло нормально, пока вы не начали тестировать сеть. Перед вами стояла одна большая проблема: задержка.
Исторически AWS предлагала только несколько регионов и зон доступности для развертывания. Если вы или ваши клиенты застряли где-то между зонами, то вам не повезло с задержкой.
В большинстве случаев это не проблема, если вы размещаете некоторые данные или обслуживаете базовый веб-сайт. Однако все становится серьезно, если вы пытаетесь доставлять потоковые данные, такие как видео или аудио. Для таких чувствительных приложений вам нужно гораздо более быстрое время доставки и более стабильная сеть.
Именно здесь вступают в игру локальные зоны AWS. Это набор недавно созданных периферийных местоположений, которые AWS предоставляет в разных городских районах. Используя эти зоны, вы можете снизить задержку и более точно контролировать место развертывания.
Прежде чем мы углубимся в новые зоны, давайте освежим в памяти некоторые основы AWS.
Регионы и зоны доступности
Крупнейшей географической единицей измерения в мире AWS является регион. Регион — это большая территория, содержащая несколько центров обработки данных. Внутри каждого региона центр обработки данных считается зоной доступности. Для обеспечения отказоустойчивости по региону разбросано несколько зон доступности.
Когда вы запускаете новый экземпляр, вы можете выбрать нужную зону доступности, после чего все готово. Хотя Amazon предоставляет список периферийных местоположений, каждая зона доступности не была явно привязана к определенному местоположению (по крайней мере, так, чтобы вы могли быстро различить). Например, вы не могли явно развернуться в определенном городе, таком как Лос-Анджелес.
Когда вы выполняете развертывание в этих зонах, вы в значительной степени зависите от вас, чтобы оценить, какая из них имеет наилучшую задержку для вашего приложения.
Новые зоны
С введением локальных зон AWS теперь предоставляет определенные зоны доступности в крупных городах. Самое приятное то, что каждая зона явно помечена в соответствии с городом, в котором она находится. Теперь вы действительно можете развернуть экземпляр в определенном городе по своему желанию.
Ниже приведены доступные в настоящее время локальные зоны для Восточного региона США:
Есть также несколько локальных зон, доступных в Западном регионе США:
Как видите, это открывает совершенно новый мир возможностей для развертывания инстансов как можно ближе к городам, которые они будут обслуживать. Если вы предоставляете видео клиентам в Портленде или Денвере, создание конечной точки в этих локальных зонах, скорее всего, будет намного быстрее, чем в обычной зоне доступности.
Конечно, у локальных зон есть несколько ограничений.
Локальные зоны пока не поддерживают весь каталог сервисов AWS. Они также не поддерживают все типы инстансов EC2 (для некоторых это может быть большой проблемой). Чтобы проверить каталог услуг, перейдите на следующую страницу:
Несмотря на то, что поддержка типов экземпляров указана на этой странице, все еще есть некоторые конкретные экземпляры, которые не разрешены в некоторых зонах. Чтобы узнать, какие экземпляры разрешены в локальной зоне, используйте следующую команду aws-cli (заменив <zone> и <region> на свои):
aws ec2 describe-instance-type-offerings --location-type "availability-zone" --filters Name=location,Values=<zone> --region <region>
Это должно вывести доступные типы экземпляров для этой конкретной зоны.
Цифры
Это все хорошо и весело, но как насчет показателей задержки? Насколько лучше?
Ну, на этот вопрос не так просто ответить, потому что настоящий ответ таков: это зависит. Измерение задержки — это не статическая вещь. Ссылки меняются, и значения не всегда одинаковы. Другой важной переменной является то, откуда клиент получает доступ к серверу. Если вы запустите новый инстанс в Нью-Йорке, и они доберутся до него по ухудшенному пути или далеко за пределами города, вы можете вообще не увидеть особых улучшений.
По данным Amazon, если вы находитесь в том же городе, что и инстанс, развернутый в локальной зоне, вы можете ожидать «задержку, равную одной цифре в миллисекундах».
В тестах, которые я выполнял для экземпляра локальной зоны в Нью-Йорке (us-east-1-nyc-1a), я увидел среднее время отклика 3.5ms от сервера, расположенного в той же географической области ( северный Нью-Джерси). Для экземпляра, размещенного в облаке, это отличное время отклика.
Для того же теста, выполненного для экземпляра, расположенного в стандартной зоне Востока США (us-east-1c), результаты составили около 8.5ms. Использование локальной зоны сокращает задержку более чем вдвое.
Использование этих новых локальных зон кажется одним из самых быстрых и простых способов переместить службы ближе к крупным мегаполисам и обслуживать приложения быстрее, чем когда-либо прежде.
Всегда имейте в виду, что ваш пробег может варьироваться при развертывании в новых локальных зонах в зависимости от их местоположения и текущего состояния ссылок. Всегда рекомендуется выполнять собственные тесты задержки, чтобы определить наилучшую зону для развертывания.
Спасибо за прочтение! Если вас интересуют еще статьи, связанные с облачными технологиями и DevOps, ознакомьтесь со следующими статьями:
