Оптимизация размеров и автомасштабирование

Изменение размера ресурсов — это подбор SKU Azure VM или службы в соответствии с фактическими требованиями рабочей нагрузки: без избыточного выделения ресурсов (что приводит к лишним расходам) и без недостаточного выделения (что создаёт риск снижения производительности). При миграции из локальной среды большинство организаций изначально выделяют на 30–50% больше ресурсов из соображений осторожности. Регулярный анализ размеров ресурсов, обычно ежемесячный, позволяет вернуть значительную часть переплаты без негативного влияния на производительность приложения.

Используйте метрики Azure Monitor и VM Insights, чтобы собирать данные о CPU, памяти, дисковых IOPS и пропускной способности сети как минимум за 30 дней. Учитывайте пиковую загрузку (P95 или P99), а не среднюю, чтобы VM подходящего размера могла справляться со скачками трафика. По умолчанию рекомендация Azure Advisor по изменению размера анализирует предыдущие 7 дней, но в конфигурации Advisor этот период можно увеличить до 30 или 60 дней для получения более репрезентативных данных.

VM Azure организованы в семейства SKU, оптимизированные для разных рабочих нагрузок: D-series (общего назначения), E-series (оптимизированные для памяти), F-series (оптимизированные для вычислений), N-series (GPU) и L-series (оптимизированные для хранилищ). Если загрузка CPU VM низкая, а использование памяти высокое, переход с D-series на E-series при том же количестве vCPU обеспечивает больше RAM при аналогичной стоимости. Изменение размера VM в Azure обычно требует кратковременного перезапуска продолжительностью несколько минут.

Запланированное автоматическое масштабирование подходит, когда закономерности рабочей нагрузки предсказуемы. Для розничного приложения с высокой посещаемостью в рабочие часы и почти нулевой нагрузкой ночью можно настроить расписание масштабирования с увеличением на 07:00 и расписание масштабирования с уменьшением на 22:00. Virtual Machine Scale Sets (VMSS) и App Service поддерживают правила запланированного автоматического масштабирования. Такой подход проще и обеспечивает более предсказуемые затраты, чем автоматическое масштабирование на основе метрик при известных закономерностях нагрузки.

Автоматическое масштабирование на основе метрик динамически добавляет или удаляет экземпляры в ответ на метрики реального времени, такие как процент загрузки CPU, длина очереди HTTP-запросов или пользовательские метрики, публикуемые через Azure Monitor. Вы определяете правила масштабирования с увеличением (когда добавлять экземпляры) и правила масштабирования с уменьшением (когда удалять экземпляры), задавая периоды охлаждения для предотвращения частых колебаний. Рекомендуется устанавливать порог масштабирования с увеличением ниже порога масштабирования с уменьшением — например, увеличивать масштаб при загрузке CPU выше 70% и уменьшать при загрузке ниже 30%, — с пятиминутным периодом охлаждения.

Azure Spot VMs позволяют использовать неиспользуемые ресурсы Azure со скидкой до 90% по сравнению с тарифами с оплатой по мере использования. Компромисс заключается в том, что Azure может изъять spot-VM с уведомлением за 30 секунд, когда ресурсы снова понадобятся. Поэтому spot-экземпляры идеально подходят для прерываемых пакетных нагрузок, таких как рендеринг, научные вычисления и конвейеры обработки данных. VMSS поддерживает смешивание обычных VM (для базовой нагрузки) и spot-VM (для резкого увеличения нагрузки) в одном масштабируемом наборе с использованием политики смешивания приоритетов.

Автомасштабирование Azure App Service работает на уровне плана App Service: оно добавляет или удаляет рабочие экземпляры на основе настроенных Вами правил. Доступные триггеры метрик включают длину очереди HTTP, процент загрузки CPU и процент использования памяти. Уровень Standard и выше поддерживает ручное масштабирование и автомасштабирование, а уровень Basic — только ручное масштабирование. Для бессерверных нагрузок рассмотрите функции Azure в плане потребления: они масштабируются до нуля и тарифицируются только за выполнение, полностью устраняя затраты на простаивающие экземпляры.

Распространённые ошибки автомасштабирования: привязка сеанса — если приложение хранит состояние сеанса в памяти VM, масштабирование внутрь приведёт к потере сеансов; вместо этого используйте Redis Cache или сеансы на основе базы данных. Медленный запуск — если прогрев VM или контейнеров занимает 10 минут, автомасштабирование на основе метрик не сможет отреагировать достаточно быстро; выполняйте предварительный прогрев с помощью запланированного масштабирования наружу перед ожидаемыми пиковыми нагрузками. Слишком агрессивное масштабирование внутрь — завершение работы экземпляров во время обработки запросов приводит к ошибкам; настройте отвод соединений и достаточно длительный период ожидания после масштабирования.

Оптимизация размеров применяется и к службам PaaS. Для Azure SQL Database на модели DTU можно уменьшить размер, если процент DTU стабильно ниже 50%. Модель vCore позволяет независимо масштабировать CPU и хранилище. Размер Azure Cache for Redis можно уменьшить, перейдя с уровня Premium на Standard, если постоянное хранение и георепликация не нужны. Пулы узлов Azure Kubernetes Service могут использовать автомасштабировщик кластера для масштабирования узлов внутрь и наружу в зависимости от состояния ожидающих и простаивающих модулей.

Оптимизация размеров — это не разовая задача. Нагрузки со временем меняются: меняется характер трафика, добавляются функции, увеличивается или сокращается база пользователей. Включите ежемесячный анализ размеров в процесс FinOps: получайте рекомендации Advisor, анализируйте 10 наиболее недоиспользуемых VM и избыточно выделенных служб PaaS и создавайте рабочие задачи для ответственных команд. Отслеживайте реализованную экономию по сравнению с созданными рекомендациями, чтобы демонстрировать руководству ROI FinOps.

Оптимальная стратегия управления затратами: сначала оптимизировать размер, затем выполнить резервирование. Покупка Reserved VM Instance для VM с избыточно большим размером закрепляет обязательство за неподходящим SKU. Сначала измените размер VM на правильный, затем в течение 30 дней наблюдайте за новым уровнем Utilization, чтобы подтвердить стабильность, и после этого приобретите резервирование для этого SKU с оптимизированным размером. Такой двухэтапный подход позволяет получить максимальную скидку и избежать неиспользуемых зарезервированных ресурсов.

В этом уроке Вы узнали, что оптимизация размеров сопоставляет SKU VM с фактическими требованиями нагрузки с помощью показателей производительности, запланированное автомасштабирование и автомасштабирование на основе метрик динамически изменяют объём ресурсов в соответствии со спросом, а Spot VM обеспечивают скидки до 90% для прерываемых пакетных нагрузок. Далее мы рассмотрим Azure Savings Plans и Reservations для нагрузок с зафиксированными обязательствами.