Как выбрать облачного провайдера

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

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

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

Тестирование, тестирование

Чтобы заглянуть под прикрытие трех крупнейших провайдеров, мы провели небольшое тестирование. Мы установили демонстрационную систему SaaS CRM в северо-западной точке присутствия (точное местоположение зависит от поставщика) для трех крупнейших поставщиков общедоступного облака:AWS, Azure и Google Cloud. Затем мы ждали результатов, и они, безусловно, были интересными.

Тестирование из Лос-Анджелеса

На приведенном ниже рисунке показан сетевой трафик от Лос-Анджелеса до ближайшего местоположения от основных провайдеров в северо-западном регионе. С нашей системой CRM, расположенной на северо-западе, действительно нет явного победителя. Google и AWS расположены в соседнем Орегоне, а Azure находится недалеко от них в Северной Калифорнии. Здесь AWS может просто выиграть, но все они демонстрируют крайнюю изменчивость в течение одного месяца (здесь чем ниже, тем лучше). Разница в физическом расстоянии не проявляется полностью как дополнительное сетевое время для веб-запросов (для справки, это занимает 40 мс для межстранового трафика). Скорее всего, происходит изменение маршрутов.

Лос-Анджелес → Северо-Западный регион | AWS | Azure | Google

Тестирование в Атланте

В следующем примере показаны сетевые маршруты трех провайдеров от нашего монитора в Атланте до северо-западных точек присутствия или зон доступности. AWS - самый медленный облачный провайдер, хотя все три подвержены колебаниям в течение месячного окна. Благодаря гораздо большему физическому разделению между синтетическим пользователем и сервером мы можем игнорировать небольшие различия в скорости сети. Однако очевидно, что AWS страдает от дополнительной задержки в среднем на 1,5 секунды. Причина может быть различной, но если для веб-запросов потребуется до двух секунд дополнительного времени, это может привести к более высокому уровню разочарования пользователей. Мы также можем видеть некоторую последовательность в наблюдаемых пиках, что указывает на то, что трафик может разделять маршруты и ежедневные проблемы с перегрузкой.

Важно помнить, что наше развертывание в Сиэтле, вероятно, не является ни идеальным, ни распространенным выбором для компании из Атланты. Но с учетом того, что из Кремниевой долины выходит так много стартапов, высока вероятность того, что многие приложения SaaS, которые вы используете каждый день, совершают этот дальний путь туда и обратно.

Атланта → Северо-Западный регион | AWS | Azure | Google

Тестирование из Нью-Йорка

В нашем последнем примере ниже показана производительность сети на всем пути от зоны Нью-Йорка до нашей системы CRM, расположенной на северо-западе. AWS по-прежнему показывает самое медленное время отклика среди трех поставщиков. Google и Azure постоянно работают быстрее, за исключением одной проблемы с перегрузкой, которая наблюдалась в конце января. Поскольку мы можем предположить, что со временем Интернет будет маршрутизировать большую часть этого трафика по всей стране, есть хороший признак того, что маршрутизация за брандмауэром AWS может быть причиной дополнительной задержки.

Нью-Йорк → Северо-Западный регион | AWS | Azure | Google

Что обнаружило наше облачное тестирование

У нас нет большой выборки, и наше тестовое развертывание не адаптировано к сложности большинства современных приложений, но наши результаты напомнили нам, насколько важно проводить исследование местоположения при планировании развертывания в облаке. Достаньте карту, чтобы увидеть, где будут расположены ваши сервисы и приложения, когда они находятся в облаке. Затем сопоставьте их с тем, где находятся пользователи этих приложений и сервисов.

Существует ряд причин, которые могут способствовать тому, что выглядит как неспособность AWS предоставлять быстрые ответы, например, соглашения о пиринге в центре страны или дополнительная маршрутизация за их брандмауэром. Ясно одно:производительность зависит от того, где находятся ваши конечные пользователи. Осознание этого факта приведет к принятию более эффективных решений, когда дело доходит до производительности.

Наша цель - не только тестирование поставщиков облачных услуг, но вы можете получить ту прозрачность, которую мы сделали (и которая вам нужна), с помощью инструментов AppNeta для любого из ваших облачных приложений. Такое понимание сети может спасти ситуацию, когда пользователи жалуются на замедление или сбои в работе, и вам необходимо определить основную причину снижения производительности.