Автоматическое масштабирование
Автоматическое масштабирование — это метод, используемый в облачных вычислениях, который автоматически и динамически регулирует количество вычислительных ресурсов в серверной ферме — обычно измеряется числом активных серверов — на основе текущей нагрузки на ферму. Количество серверов, работающих в составе веб-приложения, может автоматически увеличиваться или уменьшаться в зависимости от числа активных пользователей на сайте. Поскольку такие показатели могут существенно меняться в течение дня, а серверы являются ограниченным ресурсом и требуют затрат даже при простое, компании заинтересованы в том, чтобы поддерживать только необходимое число серверов, чтобы справиться с текущей нагрузкой, но при этом быть готовыми к внезапным скачкам активности. Автоматическое масштабирование помогает решать такие задачи: оно позволяет уменьшать число активных серверов при низкой активности и запускать новые серверы, когда нагрузка возрастает. Автоматическое масштабирование тесно связано с концепцией балансировки нагрузки и базируется на ней[1][2].
Преимущества
Автоматическое масштабирование предоставляет следующие преимущества:
- Для компаний, владеющих собственной серверной инфраструктурой, автоматическое масштабирование обычно позволяет некоторым серверам переходить в спящий режим при низкой нагрузке, что экономит электроэнергию (а также воду, если используется водяное охлаждение).
- Для компаний, использующих облачную инфраструктуру, автоматическое масштабирование может привести к снижению расходов, так как большинство облачных провайдеров взимает плату на основе фактического использования, а не максимальной мощности[3].
- Даже если компания не может уменьшить общее вычислительное количество ресурсов в любой момент времени, автоматическое масштабирование позволяет запускать менее критичные по времени задачи на серверах, высвобождающихся при уменьшении трафика[4].
- Решения автоматического масштабирования, такие как сервис Amazon Web Services, обеспечивают автоматическую замену некорректно работающих экземпляров, тем самым защищая инфраструктуру от аппаратных, сетевых и программных сбоев[5].
- Автоматическое масштабирование увеличивает время безотказной работы и доступность, особенно при переменных и непредсказуемых нагрузках.
Автоматическое масштабирование отличается от фиксированных ежедневных, еженедельных или ежегодных циклов использования серверов тем, что реагирует на реальную динамику нагрузки, уменьшая риск возникновения слишком большого или слишком малого количества серверов. Например, если трафик обычно снижается к полуночи, статическое масштабирование может запланировать вывод серверов в сон, но это приведёт к простоям при необычно высокой ночной активности (например, в случае вирусных новостей). Автоматическое масштабирование справляется с внезапными всплесками нагрузки намного лучше[6][7].
Терминология
В перечне ниже используется терминология Amazon Web Services (AWS)[8].
| Название (в AWS[8], если не указано иное) | Значение | Альтернативные названия (в Google Cloud Platform[9], Microsoft Azure[10], или других платформах) |
|---|---|---|
| Экземпляр (Instance) | Отдельный сервер или виртуальная машина в составе группы, управляемой автоматическим масштабированием | |
| Группа автоматического масштабирования (Autoscaling group) | Совокупность экземпляров, подчинённых политике масштабирования, с соответствующими правилами и состояниями | Управляемая группа экземпляров (Managed instance group, Google Cloud Platform) |
| Размер (Size) | Число экземпляров, входящих в группу автоматического масштабирования | |
| Желаемая нагрузка (Desired capacity, desired size) | Число экземпляров, к которому должна стремиться группа автоматического масштабирования. Если текущее число экземпляров меньше — группа добавляет (запускает и подключает) новые; если больше — удаляет (отключает и завершает) лишние экземпляры | |
| Минимальный размер (Minimum size) | Число экземпляров, ниже которого группа не может быть уменьшена | |
| Максимальный размер (Maximum size) | Число экземпляров, выше которого группа не может быть увеличена | |
| Метрика (Metric) | Параметр (например, загрузка процессора, использование памяти, сетевой трафик), по которому регулярно собирается статистика. Пороги метрик используются для политики масштабирования. Метрики могут агрегироваться по всему множеству экземпляров группы или по связанным балансировщикам нагрузки | |
| Политика масштабирования (Scaling policy, autoscaling policy) | Правило, определяющее изменение желаемой нагрузки (а иногда — минимального или максимального размера) в ответ на достижение метриками заданных порогов. Политикам может быть присвоен период охлаждения (cooldown period), предотвращающий частые или одновременные операции. Изменения могут быть относительными (увеличение/уменьшение на число экземпляров) или абсолютными (задание нового значения желаемой нагрузки). Политики, увеличивающие желаемую нагрузку, называются «масштабирование наружу/вверх» (scaling out/up); уменьшающие — «внутрь/вниз» (scaling in/down) | |
| Проверка состояния (Health check) | Механизм оценки корректной работы экземпляров в группе (например, по факту существования, доступности или регистрации в балансировщике нагрузки) | |
| Конфигурация запуска (Launch configuration) | Описание параметров и скриптов для запуска новых экземпляров: тип машины, опции покупки (например, spot или при наличии — on-demand), зона доступности, образ машины, скрипты и др. | Шаблон экземпляра (Instance template, Google Cloud Platform) |
| Ручное масштабирование (Manual scaling) | Операция масштабирования, выполняемая вручную | |
| Запланированное масштабирование (Scheduled scaling) | Политика масштабирования, запускаемая в заданное время (день, неделя, месяц и т. д.) |
На практике
Amazon Web Services (AWS)
Amazon Web Services представила сервис Amazon Elastic Compute Cloud (EC2) в августе 2006 года, что позволило разработчикам программно создавать и удалять экземпляры виртуальных машин[11][12]. При запуске платформа EC2 не имела встроенного автоматического масштабирования, но предоставляла разработчикам гибкие инструменты для собственных решений.
Первые сторонние решения автоматического масштабирования для AWS появились примерно в апреле 2008 года — в том числе инструменты Scalr[13] и RightScale. Компания Animoto использовала RightScale для автоматического масштабирования при всплесках трафика, связанных с популярными соцсетями[14].
18 мая 2009 года Amazon добавила функцию автоматического масштабирования совместно с Elastic Load Balancing как часть Amazon EC2[15]. В настоящее время автоматическое масштабирование является неотъемлемой частью EC2[2][16][17]. Управление масштабированием в AWS возможно через веб-интерфейс или командную строку[18]. В мае 2016 года автоматическое масштабирование было реализовано и в AWS ECS Service[19].
Провайдер видеоконтента Netflix задокументировал внедрение автоматического масштабирования в Amazon Web Services для покрытия колебаний пользовательской активности. Было установлено, что агрессивное масштабирование «вверх» и медленное масштабирование «вниз» дают наилучшие результаты по доступности[7].
По мнению Зева Ладермана, соучредителя и генерального директора Newvem, автоматическое масштабирование позволяет стартапам значительно снизить расходы на AWS[3].
Руководства по практическому использованию AWS рекомендуют применять автоматическое масштабирование даже при неизменной нагрузке, поскольку оно обеспечивает не только автоматическую замену вышедших из строя экземпляров (любые сбои — аппаратные, сетевые, программные), но и автоматическую замену прерываемых spot-экземпляров, делая использование таких ресурсов допустимым в production[5].[20][21] Внутренние стандарты Netflix требуют, чтобы все экземпляры входили в группу автоматического масштабирования, а специальный сервис (conformity monkey) завершает все экземпляры вне таких групп[22].
Microsoft Azure
27 июня 2013 года Microsoft анонсировала поддержку автоматического масштабирования в своей облачной платформе Windows Azure[23][24][25]. Официальная документация размещена на Microsoft Developer Network[10][26].
Oracle Cloud
Платформа Oracle Cloud Platform обеспечивает автоматическое масштабирование кластеров путём задания соответствующих правил[27]. Запуск или отключение узлов выполняется на основании мониторинга загрузки процессора и/или памяти.
Google Cloud Platform
17 ноября 2014 года Google Compute Engine объявила о публичном бета-тестировании функции автоматического масштабирования[28][29][30][31]. По состоянию на март 2015 года инструмент находился в стадии разработки[9].
Масштабирование подов в Kubernetes
Горизонтальный автоскейлер подов в Kubernetes (Horizontal Pod Autoscaler) автоматически масштабирует число подов в replication controller, deployment или replicaset на основании текущей загрузки процессора (или, в бета-режиме, иных пользовательских метрик)[32].
Альтернативные подходы к принятию решений автоматического масштабирования
Стандартный подход автоматического масштабирования основан на реактивных решениях: масштабирование происходит в ответ на изменения метрик практически в реальном времени. Однако, если изменения происходят слишком быстро, такой подход может быть недостаточным. Ниже рассмотрены два альтернативных подхода.
Запланированное масштабирование
В этом подходе изменения минимального/максимального размера группы или желаемой нагрузки производятся строго по расписанию (в заданное время суток). Запланированное масштабирование удобно, когда известно о предстоящем пике или снижении нагрузки в определенные часы, и реактивная система может не успеть отреагировать. В AWS группы масштабирования поддерживают запланированные операции[33].
Прогнозное масштабирование
Данный подход использует методы прогнозной аналитики. Система комбинирует недавние тренды использования, исторические данные и прочие источники для оценки будущей нагрузки и масштабирует инфраструктуру упреждающе.
Netflix сообщила, что собственная система предиктивной аналитики Scryer позволила им добиться лучших результатов по сравнению с реактивным масштабированием AWS. В частности, это проявилось при:[34][35]
- Предварительном реагировании на резкие скачки трафика
- Переживании крупных сбоев (например, недоступности зоны или региона)
- Гибком масштабировании при сложных и быстро меняющихся нагрузках
20 ноября 2018 года AWS объявила о внедрении прогнозного масштабирования на базе методов машинного обучения[36].