Автоматическое масштабирование в Служба приложений Azure

Автоматическое масштабирование — это параметр горизонтального масштабирования, который автоматически обрабатывает решения по масштабированию для веб-приложений и планов службы приложений. Это отличается от Azure автомасштабирования, который позволяет определять правила масштабирования на основе метрик и расписаний.

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

Перед тем как начать

Автоматическое масштабирование в Службе приложений отличается от автомасштабирования.
Используйте автоматическое масштабирование, если требуется, чтобы служба приложений автоматически обрабатывала масштабирование на основе HTTP-трафика без создания правил или расписаний.

Автоматическое масштабирование (эта статья):

• Автоматическое масштабирование на основе входящего HTTP-трафика
• Настроено для каждого приложения
• Поддерживает всегда готовые, ограничения для каждого приложения, максимальное ускорение и предварительно подготовленные экземпляры

Автомасштабирование:

• Использует метрики (ЦП, память, длина очереди, пользовательские метрики)
• Поддерживает масштабирование на основе расписания
• Применяется ко всему плану службы приложений

Если требуется масштабирование на основе ЦП, памяти или времени, используйте автоматическое масштабирование.
Только один метод масштабирования должен быть активным для плана службы приложений.

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

Как работает автоматическое масштабирование

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

Ниже приведены несколько сценариев, в которых следует автоматически масштабировать.

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

Включение автоматического масштабирования

Настройка Максимальная нагрузка определяет наибольшее количество экземпляров, которое ваш план службы приложений может увеличить в ответ на входящие HTTP-запросы. Для планов Premium версий v2, v3 и v4 можно указать количество до 30 экземпляров. Максимальное число всплесков должно быть равно или больше количества рабочих ролей, указанных для плана службы приложений.

az appservice plan update --name <APP_SERVICE_PLAN> --resource-group <RESOURCE_GROUP> --elastic-scale true --max-elastic-worker-count <YOUR_MAX_BURST> 

Задайте минимальное количество экземпляров веб-приложения

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

 az webapp update --resource-group <RESOURCE_GROUP> --name <APP_NAME> --minimum-elastic-instance-count <ALWAYS_READY_COUNT> 

Задайте максимальное количество экземпляров веб-приложения

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

Обновление разогретых экземпляров

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

 az webapp update --resource-group <RESOURCE_GROUP> --name <APP_NAME> --prewarmed-instance-count <PREWARMED_COUNT>

Отключение автоматического масштабирования

az appservice plan update --resource-group <RESOURCE_GROUP> --name <APP_SERVICE_PLAN> --elastic-scale false 

Часто задаваемые вопросы

Поддерживает ли автоматическое масштабирование Функции Azure приложения?

Нет, вы можете включать автоматическое масштабирование только для веб-приложений Служба приложений Azure в том плане App Service, который вы выбрали. Для приложений Функции Azure рекомендуется использовать план Функции Azure Premium.

Как работает автоматическое масштабирование за кулисами?

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

После утихания нагрузки платформа инициирует проверку потенциального масштабирования. Обычно этот процесс начинается примерно через 5–10 минут после остановки загрузки. Во время масштабирования экземпляры удаляются с максимальной частотой — один каждые несколько секунд или до минуты.

Если несколько веб-приложений развертываются в одном плане службы приложений, платформа пытается выделить ресурсы между доступными экземплярами. Это выделение основано на нагрузке каждого отдельного веб-приложения.

Как мне выставляется счёт за заранее подготовленные экземпляры?

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

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

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

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

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

Почему у AppServiceHTTPLogs есть записи журнала, похожие на /admin/host/ping со статусом 404?

Автоматическое масштабирование службы приложений периодически проверяет конечную точку /admin/host/ping, а также другие встроенные в платформу механизмы проверки работоспособности. Иногда из-за существующих конфигураций платформы эти пинги могут возвращать ошибки 404. Однако важно отметить, что эти 404 ошибки не должны влиять на доступность приложения или производительность масштабирования.

Если веб-приложение возвращает состояние 5xx, эти проверки связи конечных точек могут привести к периодическим перезапускам, хотя этот сценарий является редким. Убедитесь, что веб-приложение не возвращает состояние 5xx на этой конечной точке. Эти точки ping нельзя настроить.

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

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

Как ARR Affinity влияет на автоматическое масштабирование?

Служба приложений Azure использует файлы cookie для маршрутизации запросов приложений, известные как ARR Affinity. Файлы cookie сопоставления ARR ограничивают масштабирование, так как они отправляют запросы только на серверы, связанные с файлом cookie, а не на любой доступный экземпляр. Для приложений, которые хранят состояние, лучше увеличить масштаб (увеличить ресурсы в одном экземпляре). Для приложений без отслеживания состояния масштабирование (добавление дополнительных экземпляров) обеспечивает большую гибкость и масштабируемость. Файлы cookie ARR Affinity включены по умолчанию в Службе приложений. Однако при использовании автоматического масштабирования необходимо отключить файлы cookie сопоставления ARR, чтобы обеспечить надлежащее масштабирование.

Чтобы отключить файлы cookie ARR Affinity: выберите приложение Служба приложений и в разделе "Параметры" выберите "Конфигурация". Затем выберите вкладку "Общие параметры ". В разделе "Сходство сеансов" нажмите кнопку "Выкл ." и нажмите кнопку "Сохранить ".

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

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

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

Это обновление необходимо выполнить с помощью API CLI или AZURE RESOURCE MANAGER. На портале Azure в данный момент пересчет не выполняется корректно.

Примере: План может иметь 7 назначенных экземпляров. Приложения в плане могут всегда иметь готовые значения 2, 3 и 5. Выставление счетов осуществляется из расчета на 7 экземпляров, так как это минимальное количество. При изменении значения "всегда готов" у любого приложения, например, с 3 до 4, план пересчитывается. Затем он задает для назначенного экземпляра количество 5, что является самым высоким значением показателя "всегда готов".

Связанный контент

• Начните работу с автомасштабированием в Azure
• Настройка уровня PremiumV3 для службы приложений
• Масштабирование емкости сервера
• Узнайте о размещении с высокой плотностью