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

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

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

В следующей таблице сравниваются опции масштабирования "scale-out" и "scale-in", доступные в службе приложений App Service.

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

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

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

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

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

Настройка Максимальная нагрузка определяет наибольшее количество экземпляров, которое ваш план службы приложений может увеличить в ответ на входящие HTTP-запросы. Для планов Premium версии 2 и v3 можно указать до 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 в плане службы приложений, в котором вы хотите включить автоматическое масштабирование. Для приложений Функций Azure рекомендуется использовать план "Премиум " для функций Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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