Автоматическое масштабирование в Windows Azure (Wasabi)

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

Масштабируемость. Ввод новых продуктов и сервисов, расширение канала продаж и количества заказчиков требуют от информационных систем организации выдерживать растущие нагрузки и обрабатывать большие объемы данных. Быстрая и надежная работа, исключающая отказы в обслуживании, задержки в ответах от системы и сбои позволяют повысить лояльность и удовлетворенность заказчиков. Масштабируемое приложение позволяет выдерживать большую нагрузку, за счет увеличения количества одновременно запущенных экземпляров. ( Облачная платформа Microsoft , А.Федоров, Д.Мартынов)

Эластичность. Гибкая реакция на изменяющиеся условия ведения бизнеса является одной из характеристик успешного бизнеса. Например, сложившаяся рыночная конъюнктура и действия конкурентов могут потребовать быстро внедрить новый продукт или услугу, проведя при этом полный цикл планирования, проектирования и разработки информационной системы. Эластичность связана с масштабируемостью приложений, так как решает задачу моментального изменения количества вычислительных ресурсов, выделяемых для работы информационной системы. ( Облачная платформа Microsoft , А.Федоров, Д.Мартынов)

Windows Azure предоставляет неограниченные возможности по масштабированию приложения или сервиса. Что касается, например, хранилищ Windows Azure (Table Storage, BLOB Storage и т.п.), то их масштабирование абсолютно прозрачно для конечной системы и разработчика. С SQL Azure ситуация немного другая – масштабирование достигается за счет федераций (горизонтального масштабирования), настройкой федераций занимается разработчик. И еще одним важным ресурсов, который должен иметь возможность масштабирования, являются вычислительные ресурсы (веб- и воркер-роли). Именно об изменении количества экземпляров веб- и воркер-ролей далее мы поговорим подробнее.

Масштабирование вычислительных ресурсов

На данный момент возможно следующими способами изменить количество работающих экземпляров ролей (обеспечить эластичность):

1. Вручную через портал администрирования Windows Azure.

2. Автоматически за счет использования специального сервиса (на данный момент – это 3rd party сервисы, например, AzureWatch).

3. Автоматически за счет создания собственного сервиса поверх Azure Management API.

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

Использование 3rd party сервиса позволяет подключить функциональность масштабирования в один клик, но при этом обычно является платной услугой и означает, что Ваше приложение или сервис (и их SLA) будет включать дополнительную зависимость от стороннего провайдера.

И последний вариант – реализация сервиса масштабирования самостоятельно. С одной стороны, это обеспечивает больший контроль и, возможно, будет дешевле, чем первые два варианта. Т.к. в первом варианте цена ошибки (администратор во время не увеличил\уменьшил количества экземпляров) может быть достаточно высокой, стоимость 3rd party сервиса так же может быть высокой и требует отдельной оплаты для каждого проекта, тогда свой собственный код можно использовать повторно, затратив минимальные усилия. В другой стороны – написанный код вам же и поддерживать, и можно увлечься и начать создавать все сервисы (идентификации, диагностики журналирования и т.п.) самостоятельно.

В любом случае – выбора за вами, а далее мы подробнее поговорим о технической реализации третьего варианта. На codeplex есть специальный модуль по автоматическому масштабированию Windows Azure ролей – Wasabi (Windows Azure Autoscaling Block), который входит в состав Enterprise Library 5.0 Integration Pack for Windows Azure.

Windows Azure Autoscaling Block

Wasabi – это сервис, который периодически выполняет мониторинг хранилища диагностических данных вашего приложения (через Windows Azure Diagnostic API) и на основании заданных правил принимает решение о динамическом увеличении или уменьшении количества количества запущенных экземпляров ролей (через Windows Azure Management API) .

Wasabi ориентирован на две основные задачи:

1. Динамическое изменение числа экземпляров ролей, например, увеличение экземпляров при возрастающей нагрузки.

2. Ограничение (throttling) функциональности приложения в зависимости от токующей нагрузки. Если нагрузка велика, а новый экземпляр роли еще только в процессе инициализации (процесс старта роли может занимать 5-10 минут) или вы не считаете целесообразным дальнейшее увеличение число ролей, то можно отключить ту или иную функциональность приложения, например, автозаполнение и увеличить интервал агрегирования статистики.

Основные особенности, характеристики и преимущества Wasabi:

1. Wasabi = эластичность, но Wasabi ≠ автоматическое масштабирование любого приложения. Wasabi позволяет динамически изменять число экземпляров ролей на основе заданных правил, но при этом для того, чтобы приложение или сервис действительно масштабировалось (т.е. увеличение числа экземпляров приводило к увеличению производительности), приложение должны быть написано “правильным” образом" (асинхронные операции, stateless и т.п.), см. Особенности проектирования приложений.

2. Снижение затрат. Правильное использование Wasabi позволяет снижать затраты на Windows Azure за счет необходимого и достаточного использования ресурсов в каждый момент времени, т.е. не переплачивать и не позволять приложение “упасть” под возросшей нагрузкой.

3. Не требует модификации приложения. Для использования Wasabi не потребуется вносить какие-либо изменения в существующее приложение. Единственным исключением может стать случай, когда в правилах Wasabi используется информация от счетчиков производительности. В этом случае вам потребуется убедиться, что информация о счётчиках собирается и сохраняется в Windows Azure хранилище. Эти изменения можно внести с помощью Windows Azure Diagnostics Configuration File (diagnostics.wadcfg).

4. Публикация сервиса Wasabi . Для использования Wasabi потребуется где-то его опубликовать (т.к. это сервис). Опубликовать можно как отдельную воркер-роль в Windows Azure или в вашей локальной инфраструктуре.

Возникает вопрос: не станет ли Wasabi узким местом системы? Т.е. каким образом “падение” сервиса отразится на вашем приложении? Во-первых, аналогично любому Windows Azure приложению для обеспечения высокой доступности Wasabi (SLA 99,9%) можно запустить два экземпляра сервиса. Во-вторых, если запущен один экземпляр, то сервис после “падения” автоматически будет поднят на другом узле, но в этом случае на некоторое время (время инициализации роли, ~5-10 минут) для вашего приложения функциональность по автомасштабированию будет не доступна. Wasabi все настройки хранит в Azure Storage, поэтому после успешного восстановления продолжит свою работу корректно.

5. Гибкие правила. Wasabi может принимать решение о необходимости увеличения\уменьшения числа экземпляров ролей на основе временной таблицы (если пики и спады предсказуемы во времени) , счетчиков производительности (CPU, память и т.п.) и\или Windows Azure метрик (размер очередей и т.п.). Например, можно отслеживать среднее значение загрузки процессора в течение часа для всех ролей, если нагрузка > 80%, то добавлять новые экземпляры роли.

6. Граничные значения. Wasabi позволяет жестко задать нижнюю и верхнюю границу масштабирования. Это позволяет не превысить, например, определенный лимит на стоимость Windows ресурсов. Другая распространенная ситуация, которую можно решить за счет установки лимитов, – это отсутствие значительного прироста производительности системы при увеличении числа экземпляров ролей, т.е. когда есть некая оптимальная точка стоимость\производительности решения. Еще один вариант использования – это задание разных правил для различных тенантов (например, платный или бесплатный аккаунт в вашем сервисе).

7. Стабилизация резких колебаний. Встроенный модуль Stabilizer позволяет предотвращать резкие колебания числа экземпляров ролей и оптимизировать затраты. Заданные правила (допустим, размер очереди) могут отрабатывать таким образом, что, например, потребуется каждые 5-10 минут то увеличивать количество экземпляров, то уменьшать. При этом не забывайте, что стоимость вычислительных ресурсов округляется до часа использования относительно экземпляра, т.е. каждый запуск экземпляра роли оплачивается.

Из этого следуют два основных правила:

1. Не рекомендуется запускать новый экземпляр в “конце” часа, т.к. скорее всего это вам будет стоить 2 часа работы. Пример: если экземпляр был запущен а 11:50, а остановлен в 12:20, то оплачиваться будут два часа использования ресурсов, хотя фактически экземпляр отработал 30 минут.

2. Не рекомендуется останавливать экземпляр сразу после выполнения им своих задач, т.к. все равно "оплачен” час работы. Пример: если экземпляр1 был запущен в 12:05, остановлен в 12:25, экземпляр2 был запущен в 12:35 и остановлен в 12:55, то оплачиваться будут 2 часа работы. Мы могли бы сэкономить, если бы позволили экземпляру1 доработать до конца часа и выполнить вторую поступившую задачу.

Пример конфигурации, которая позволяет выполнить правила, описанные выше:

<stabilizer scaleUpCooldown="00:20:00" scaleDownCooldown="00:30:00" scaleUpOnlyInFirstMinutesOfHour="15" scaleDownOnlyInLastMinutesOfHour=“20" >
<roles>...</roles>
</stabilizer>

8. ИТ-про.Wasabi поддерживает администрирование через PowerShell командлеты.

9. Статистика. Wasabi ведет статистику. Собранная статистика позволяет корректировать правила масштабирования, основываясь на реальных “боевых” данных.

10. Нотификации. Wasabi поддерживает систему уведомлений\нотификаций. ScaleAndNotify опция заставляет Wasabi отсылать уведомления о том, что необходимо изменить число экземпляров ролей, но не выполнять эту операцию автоматически. Например, данный вариант очень хорошо подходит на стадии тестирования и staging-среды.

11. Бесплатно. Wasabi является абсолютно бесплатным и предоставляет по лицензии MS-PL. При необходимости вы можете вносить изменения в исходные коды. Скачать Wasabi можно на MSDN или через NuGet.

Более подробная информация доступна в книге Developer’s Guide to Enterprise Library Integration Pack for Windows Azure (en), пример настройки в статье Azure Elasticity with Wasabi Application Block, а так же видео-доклад на techdays.ru по настройке Wasabi.