Рекомендации по разработке надежной стратегии масштабирования

  • Статья

Применяется к этой рекомендации по контрольным спискам надежности платформы Azure Well-Architected:

RE:06 Реализуйте своевременную и надежную стратегию масштабирования на уровне приложений, данных и инфраструктуры.

Связанное руководство.Секционирование данных

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

Определения

Термин Определение
Вертикальное масштабирование Подход к масштабированию, который добавляет вычислительные ресурсы к существующим ресурсам.
Горизонтальное масштабирование Подход к масштабированию, который добавляет экземпляры заданного типа ресурса.
Автомасштабирование Подход к масштабированию, который автоматически добавляет или удаляет ресурсы при выполнении набора условий.

Примечание

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

Ключевые стратегии проектирования

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

  • Статический: каждую ночь к 23:00 по EST число активных пользователей меньше 100, а загрузка ЦП на серверах приложений снижается на 90 % на всех узлах.

  • Динамическая, регулярная и предсказуемая: каждый понедельник утром в систему ERP входят 1000 сотрудников из нескольких регионов.

  • Динамический, нерегулярный и предсказуемый. Запуск продукта происходит в первый день месяца, и есть исторические данные из предыдущих запусков о том, как увеличивается трафик в таких ситуациях.

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

Определив эти типы шаблонов нагрузки, вы можете:

  • Определите, как изменение нагрузки, связанное с каждым шаблоном, влияет на инфраструктуру.

  • Создание автоматизации для надежного решения проблемы масштабирования.

В предыдущих примерах стратегии масштабирования могут быть следующими:

  • Статический: вы планируете масштабировать вычислительные узлы до минимального количества (2) между 23:00 и 6:00 EST.

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

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

  • Динамические, нерегулярные и непредсказуемые. Для учета незапланированных пиков трафика определены пороговые значения автомасштабирования.

При проектировании автоматизации масштабирования обязательно учитывайте следующие проблемы:

  • Все компоненты рабочей нагрузки должны быть кандидатами для реализации масштабирования. В большинстве случаев глобальные службы, такие как Microsoft Entra идентификаторов, автоматически и прозрачно масштабироваться для вас и ваших клиентов. Обязательно изучите возможности масштабирования сетевых контроллеров входящего и исходящего трафика, а также решения для балансировки нагрузки.

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

  • Время, необходимое для выполнения операции масштабирования, чтобы правильно запланировать выполнение операции до того, как дополнительная нагрузка обрушится на инфраструктуру. Например, если масштабирование компонента, такого как Управление API, занимает 45 минут, изменение порогового значения масштабирования до 65 % вместо 90 % может помочь выполнить масштабирование раньше и подготовиться к ожидаемому увеличению нагрузки.

  • Связь компонентов потока с точки зрения порядка операций масштабирования. Убедитесь, что вы не случайно перегрузите подчиненный компонент, сначала масштабируя компонент вышестоящий.

  • Любые элементы приложения с отслеживанием состояния, которые могут быть прерваны операцией масштабирования, и все реализованные сходства сеансов (или залипчивость сеанса). Прилипание может ограничить возможности масштабирования и привести к отдельным точкам отказа.

  • Потенциальные узкие места. Горизонтальное масштабирование не устраняет все проблемы с производительностью. Например, если серверная база данных является узким местом, добавить дополнительные веб-серверы не поможет. Сначала определите и устраните узкие места в системе, прежде чем просто добавить дополнительные экземпляры. Возникновение узких мест наиболее вероятно в компонентах, которые работают с отслеживанием состояния.

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

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

Упрощение azure

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

Многие службы Azure предлагают API, которые можно использовать для разработки пользовательских операций автоматического масштабирования с помощью служба автоматизации Azure, например примеры кода в разделе Автомасштабирование Центр Интернета вещей Azure. Вы можете использовать такие средства, как KEDA, для автомасштабирования на основе событий, которое доступно в Служба Azure Kubernetes и контейнерных приложениях Azure.

Автомасштабирование Azure Monitor предоставляет общий набор функций автомасштабирования для azure Масштабируемые наборы виртуальных машин, Служба приложений Azure, Azure Spring Apps и многого другого. Масштабирование может выполняться по расписанию или на основе метрики среды выполнения, например использования ЦП или памяти. Рекомендации см. в руководстве по Azure Monitor .

Компромиссы

Рекомендации по автомасштабированию

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

Система должна поддерживать возможность горизонтального масштабирования. Избегайте предположений о сходстве экземпляров. Не разрабатывайте решения, требующие выполнения кода в определенном экземпляре процесса. При горизонтальном масштабировании облачной службы или веб-сайта не следует предполагать, что ряд запросов из одного источника всегда направляется в один и тот же экземпляр. По этой же причине службы следует разрабатывать без сохранения состояния. Это позволит избежать того, чтобы серия запросов из приложения всегда направлялась в тот же экземпляр службы. При разработке службы, которая считывает сообщения из очереди и обрабатывает их, не делайте никаких предположений о том, какой экземпляр службы обрабатывает определенное сообщение. Автомасштабирование может запустить больше экземпляров службы по мере увеличения длины очереди. В статье Шаблон конкурирующих потребителей приводится решение для этого сценария.

Если решение реализует длительно выполняемую задачу, то такую задачу следует создать так, чтобы она поддерживала как масштабирование наружу, так и масштабирование внутрь. Без должной осторожности такая задача может предотвратить чистое завершение работы экземпляра процесса при масштабировании системы. Кроме того, в случае принудительного завершения процесса данные могут быть потеряны. В идеале для длительно выполняемой задачи следует выполнить рефакторинг и разбить процесс обработки, которую он выполняет, на отдельные фрагменты. Шаблон "Каналы и фильтры" содержит пример того, как можно достичь этого решения.

Кроме того, можно реализовать механизм контрольных точек, который регулярно записывает сведения о состоянии задачи. Затем это состояние можно сохранить в долговременном хранилище, доступ к которому может получить любой экземпляр процесса, выполняющего задачу. Таким образом, если процесс завершается, работа, которую он выполнял, может быть возобновлена с последней контрольной точки другим экземпляром. Существуют библиотеки, предоставляющие эту функцию, например NServiceBus и MassTransit. Они прозрачно сохраняют состояние, в котором интервалы согласованы с обработкой сообщений из очередей в Служебная шина Azure.

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

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

Например, в очереди может быть 50 000 сообщений. Но критическое время самого старого сообщения составляет 500 мс, а конечная точка работает с интеграцией со сторонней веб-службой для отправки сообщений электронной почты. Заинтересованные лица, скорее всего, сочтут это период времени, который не оправдывает затраты на масштабирование.

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

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

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

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

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

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

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

Пример

См. руководство по масштабированию базовой эталонной архитектуры AKS.

Контрольный список надежности

См. полный набор рекомендаций.

Контрольный список надежности