В последние лет пять про облачные технологии слышно все чаще. Microsoft и Amazon отчитываются о высоком росте доли облачных сервисов в отчетах о прибыли. Российский Яндекс относительно давно продвигает свое Облако. К этому подключился и Сбер со своим облачным продуктом. Часто можно услышать и о других, менее крупных игроках.

Смотря на все это многообразие я подумал, что происходит какая-то вечеринка, а меня не пригласили. Ну что же, давайте присоединимся к этой вечеринке сами разместив сайт на Azure и сравнив тарифы службы приложений и службы БД.

Цель этой статьи можно выразить в 2х пунктах:

1. С одной стороны мы познакомимся с тарифными планами службы веб-приложений и службы хостинга баз данных

2. С другой стороны мы проведем нагрузочное тестирование тремя стратегиями тестирования в разрезе разных тарифных планов

Чтобы добиться нашей цели мы сделаем следующее: 

1. Разместим на Azure сайт 

2. Подадим на него нагрузку и проверим, как инфраструктура Azure с ней справляется

3. Будем менять разные тарифы и разные стратегии нагрузочного тестирования и снова подавать нагрузку

4. Зафиксируем результаты и сравним их 

Ограничение: из-за большого числа моделей использования БД, ограничимся только оплатой при использовании модели приобретения DTU. Подробнее здесь.

Что такое облачный хостинг MS Azure?

Аудитория читателей может и не знать, что такое MS Azure, поэтому несколько слов о том, что такое облачный хостинг Azure

MS Azure - это облачная платформа, которая включает более 600 продуктов и облачных служб.  Цифра актуальна на сентябрь 2021 года. Мне нравится эта иллюстрация личного кабинета. Она показывает богатство выбора.

Кроме того платформа Azure обладает такими свойствами. Я выбрал не книжный список, а тот, на который обратил внимания сам:  

1. Распределенная. Про это немного ниже

2. Вертикально масштабируема. Служба базы данных и служба хостинга веб-приложений могут масштабировать свои мощности движением одного ползунка. В рамках моего эксперимента изменения применяются в течении нескольких секунд. Эта возможность вызывала очень отрадное чувство. Круто!

3. Горизонтально масштабируема. В целом горизонтальное масштабирование предполагает, что вместо 1 машины вы используете 2 и более машины. И это действительно оправданно, когда вы уперлись в потолок вертикального масштабирования. В MS Azure есть эта возможность, но мы пока ограничимся вертикальным масштабированием

4. Легкая в использовании. С одной стороны Azure предполагает еще один слой абстракции. И это скорей минус, а не плюс. С другой стороны знакомство с этим новым слоем абстракции происходит довольно легко. А сайт и база данных после настройки летят в облако по нажатию одной кнопки. Так же легко настроить панель мониторинга. И при этом не нужен отдельный специалист по девопсии

5. Дружелюбна к другим вендорам. Евангелисты Майкрософта очень стараются донести, что Майкрософт повернулся лицом к Unix OC. И это действительно видно при выборе служб Azure.

6. Предоставляет службы базирующиеся не сторонних вендорах. Например ElasticSearch, Redis, Kafka

В то же время:

1. Не подходит для хостинга персональных данных из-за 152-ФЗ, т.к. в России нет физических серверов Azure

2. Дорого. В сравнении тарифов я затронул этот аспект

Говоря про Azure нужно отметить географию присутствия сервиса

География важна по следующим причинам: 1)от нее зависит цена 2) вы наверняка захотите, чтобы физические сервера находились ближе к вашим пользователям. Т.к. большое расстояние передачи данных влияет как на пропускную способность канала, так и на отклик. 3) есть риск попасть под 152ФЗ. И к сожалению для России он срабатывает в негативную сторону. В России нет официального присутствия MS Azure. Зато есть вендоры

Например: 

• МТС

• lancloud.ru

• 1cloud.ru

Однако и тут есть нюансы.Так на сайте MTS Облака в разделе Azure Stack представлены лишь 7 служб,  только виртуальные машины и диски. Как писал выше у Azure от Microsoft более 600 служб

1cloud.ru служит только для того, чтобы финансовые взаиморасчеты происходили с российской компанией. Технически это тот же Microsoft Azure, тот же личный кабинет от Microsoft, та же локация серверов не в России 

Сайт, на котором будем проводить тест

Как и говорилось выше, тестировать Azure мы будем на не большом, но реальном сайте. Этот сайт несет свою бизнес ценность, а именно - показывает сколько стоят детские товары у разных ретейлеров. Сайт «Мое Молоко» собирает данные у «Перекрестка» и «Утконоса» раз в сутки и сохраняет цену в базе данных в облаке Azure. Мамы и папы, которые хотят сэкономить на детских товарах, заходят на «Мое молоко» и выбирают подгузники по самой дешевой цене. Затем переходят на сайт ретейлера и делают у него заказ

С технической точки зрения у нас есть сайт на ASP.NET Core MVC. Рендеринг происходит на серверной стороне и BackEnd сайта отдает браузеру готовый HTML. Так же на BackEnd сайта настроена служба, которая просыпается раз в сутки и стучится на сайт к ретейлерам. Utkonos отдает JSON и нужные нам поля уже разложены по строкам. Perekrestok отдает HTML, который разбирать сложно, но можно. В итоге BackEnd сопоставляет полученные позиции между собой и заносит результаты в БД MS SQL Server

Таким образом мы используем службы:

• App Service или служба приложений. Простыми словами с помощью этой службы можно хостить сайта

• SQL Database или службу баз данных

Еще из платных услуг мы применим Storage Blob. Но необходимость в этой службе вызвана тем, что нам нужно применять командную строку - Azure CLI. И стоит он по сравнению с другими двумя службами совсем не много. Служба мониторинга и сбора логов производительности применится без каких-либо сложных телодвижений. Нам нужно будет лишь добавить виджеты и настроить панель управления. Делается это очень просто, этим Azure ну очень подкупает!

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

Осталось сказать про тарифные планы

Тарифные планы службы приложений

Нашу службу я решил поднять в Западной Европе - West Europe. Наши пользователи в Москве и географически этот вариант ближе всего.

В целом есть такие варианты: 

• Australia Central

• Australia East

• Australia Southeast

• Brazil South

• Canada Central

• Canada East

• Central India

• Central US

• East Asia

• East US

• East US 2

• France Central

• Germany West Central

• Japan East

• Japan West

• Korea Central

• Korea South

• North Central US

• North Europe

• Norway East

• South Africa North

• South Central US

• South India

• Southeast Asia

• Switzerland North

• UAE North

• UK  South

• UK West

• West Central US

• West Europe

• West India

• West US

• West US 2

От географии зависит стоимость. Сам набор тарифов в зависимости от географии сильно не отличается, по крайней мере на первый взгляд. Но в долгосрочной перспективе возникает эффект экономии масштаба.

С точки зрения разделения ресурсов есть такие варианты: Общий (Shared), Выделенный (Dedicated), Изолированный (Isolated). Вот тут описана разница. На момент написания статьи для Западной Европы было доступно 17 Общих и Выделенных тарифов. Изолированные не доступны по какой-то причине на обычной учетной записи

Полный перечень тарифов для служб приложений можно посмотреть тут - https://azure.microsoft.com/ru-ru/pricing/details/app-service/windows/

Мы для своих экспериментов остановимся на этих 4х:

При этом у тарифа F1 есть одна интересная особенность - лимит по процессорному времени - 60 минут в день. При этом каждые 5 минут лимит по процессорному времени - 1.5 минуты. Получается Майкрософт привирает, когда говорит, что он ряд служб предоставляют в бесплатное пользование. А по рекламе складывается другой посыл

Тарифные планы службы БД SQL

Служба база данных поднята тоже в Восточной Европе.  Из всей массы тарифных планов выберем такие: 

Я выбрал модель оплаты основанную на DTU (Database transaction units). DTU - это метрика производительности. Пример аналога в нашей жизни - лошадиные силы. DTU собирает в себе производительность процессора, памяти и операций ввода-вывода. Система оплаты строится так, что вы платите за сервис с заданной мощностью. Даже если вы не будете расходовать ресурсы сервиса, то счет Microsoft все равно выставит. Это довольно существенный минус, а жаль.  Правда плюс в том, что количество DTU можно менять в любой момент. Да и вообще есть модель оплаты на основе виртуальных ядер. 

Подробнее про DTU можно почитать тут

А про ограничении ресурсов при использовании модели оплаты по DTU тут

Методика тестирования

Нагрузка на сервисы запущенные в продакшене не линейна. Я так же хочу приблизить наше тестирование к продкшн нагрузке. Поэтому в нашем тестировании будет заложены 3 стратегии:

1. Выявление базовой нагрузки - Baseline

2. Воздействие единичной функцией - Soak

3. Воздействие дельта-функцией - Burst

1 я стратегия позволит нам понять, после какого числа запросов наш сервис начнет отдавать запросы с Response time превышающим минимальный порог.

2я и 3я стратегии взяты из теории переходных процессов. Когда на систему подавали бесконечно большое воздействие, но за короткий промежуток времени - воздействие дельта функцией. А так же воздействие постоянным значением равным единице, но бесконечно долго - воздействие единичной функцией. В реальном мире дельта функция не будет бесконечно большой, но будет превышать базовую нагрузку. А единичная функция не будет бесконечно длинной, но воздействовать будет порядка 5 минут. Такое воздействие и коротким не назовешь. Хотя признаю, что в настоящей промышленной эксплуатации сайт держат под нагрузкой 24 часа, чтобы ловить возможные накопившиеся утечки памяти.

Теперь скомбинируем наши стратегии, тарифы БД, тарифы службы приложений и посмотрим на весь план тестирования:

Комбинаций получается много и в целях экономии времени оставим для тестов типа Soak и Baseline только крайние значения платных тарифов. Итого получится 20 тестов. 

Последовательность тестирования будет такой:

1. Для каждой комбинации тарифов выясним базовую линию. Вычислим RPS1 при котором Response time не будет превышать 5 секунд. Baseline test.

2. Для выбранных комбинаций тарифов сделаем нагрузку равную RPS1 в течении 5 минут. Soak test.

3. Для выбранных комбинаций тарифов сделаем нагрузку равную 2*RPS1 по 10 секунд и паузой по 10 секунд в течении 3 минут. Burst test

С точки зрения производительности нас интересуют 2 метрики:

1. Число запросов в секунду - RPS

2. Отклик - Response time

Фиксация результатов

Запускать тест и фиксировать результаты тестирования будем в программе SmartBear SoapUI. Важный нюанс. В расчетных данных tps (transaction per second. Когда в тесте один запрос TPS = RPS) я обнаружил ошибку отбрасывания знаков после запятой. Встречалась часто. Из-за этого я решил выгружать сырые данные  и считать RPS вручную.

Кроме того я воспользовался панелью мониторинга Azure. Метрики в ней можно разделить на 2 категории: 

1. Производительность

   1. Число запросов в секунду - RPS

   2. Отклик - Response time

2. Затраченные ресурсы

   1. Max CPU Percentage for App - максимальный процент использования ЦП всеми экземплярами плана 

   2. Average memory working set for App - средний объем памяти в мегабайтах (МБ), используемый приложением

   3. Max Memory Percentage for App - процент использование памяти всеми экземплярами плана

   4. Max DTU used for DB - максимально используемое DTU. О том что это, я писал выше

   5. Max CPU percentage for DB - максимальный процент использования ЦП 

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

Теперь, когда определены все начальные данные, можно начать тестирование. И вот что получилось:

Анализ результатов

Нагрузка, ответов в секунду, RPS (response per second)

Отклик, Avg Response time, миллисекунды

Max CPU Percentage for App, % (Max значение за период теста)

Max Memory Percentage for App, % (Max значение за период теста)

Max CPU percentage for DB, % (Max значение за период теста)

Стоимость, руб

Выводы из тестирования

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

1. Тариф БД для нашего сайта никак не влияет на RPS и отклик. Однако чем лучше тариф БД, тем больший запас по процессору для БД у нас есть. И это значит, что БД на хорошем тарифе имеет запас мощности и готовность к новым нагрузкам

2. Для службы БД важно следить за загрузкой жесткого диска. Однако мониторинг службы БД почему-то не показывал операции ввод/вывода и они всегда были на 0

3. Эксперимент выполнен с отключенным кэшем службы приложений. Однако судя по «загрузке процессора службы БД» и по ResponseTime запрос в БД был закэширован на уровне базы данных 

4. Тариф службы приложений B1 едва ли справляется с нагрузкой в 1 RPS.

5. Зато тариф службы приложений P2V2 выдерживает нагрузку в несколько RPS при отклике не сильно более 1 секунды. 

6. Так же говоря о загрузке процессора стоит последить не за пиковой (Max) загрузкой процессора службы приложений, а за средний (Avg). Т.к. службы приложения пиковая загрузка процессора почти всегда доходила до 100%

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

8. Но MS Azure стоит дорого и его инфраструктуры нет в России. Поэтому стоит присмотреться еще и к Яндекс.Cloud, или SberCloud, или Azure Stack от МТС и оценить их

Что дальше?

Было бы интересно запустить тот же сайт на более привычном хостинге VPS начальных уровней за 1000р в год. И сравнить производительность сайта при прочих равных условиях. Пишите, если вам тоже было бы интересно узнать о результатах.