Рекомендации по проектированию надежной стратегии масштабирования
Применяется к этой рекомендации проверки надежности платформы Azure Well-Architected Framework:
| RE:06 | Реализуйте своевременную и надежную стратегию масштабирования на уровнях приложения, данных и инфраструктуры. |
|---|
Связанное руководство. Секционирование данных
В этом руководстве описываются рекомендации по проектированию надежной стратегии масштабирования.
Определения
| Термин | Определение |
|---|---|
| Вертикальное масштабирование | Подход масштабирования, добавляющий вычислительные ресурсы к существующим ресурсам. |
| Горизонтальное масштабирование | Подход масштабирования, добавляющий экземпляры заданного типа ресурса. |
| Автомасштабирование | Подход масштабирования, который автоматически добавляет или удаляет ресурсы при выполнении набора условий. |
Примечание.
Операции масштабирования могут быть статическими (регулярно запланированными ежедневными масштабированиями для размещения обычных шаблонов нагрузки), автоматическим (автоматическим процессом в ответ на условия выполнения) или вручную (оператор выполняет однократную операцию масштабирования в реакции на непреднамеренные изменения нагрузки). Вертикальное и горизонтальное масштабирование можно выполнять с помощью любого из этих методов. Однако автоматическое вертикальное масштабирование требует дополнительной разработки пользовательской автоматизации и может привести к простою в зависимости от масштабируемых ресурсов.
Основные стратегии проектирования
Проектирование в соответствии с шаблонами загрузки
Чтобы разработать надежную стратегию масштабирования для рабочих нагрузок, сосредоточьтесь на определении шаблонов нагрузки для потоков пользователей и систем для каждой рабочей нагрузки, которая приводит к масштабированию. Ниже приведены примеры различных шаблонов загрузки:
Статический: каждый вечер до 11 вечера EST, число активных пользователей ниже 100, а загрузка ЦП для серверов приложений снижается на 90 % на всех узлах.
Динамический, регулярный и предсказуемый: каждый понедельник утром 1000 сотрудников в нескольких регионах войдите в систему ERP.
Динамические, нерегулярные и предсказуемые: запуск продукта происходит в первый день месяца, и в предыдущих запусках есть исторические данные о том, как трафик увеличивается в этих ситуациях.
Динамическое, нерегулярное и непредсказуемое: крупномасштабное событие приводит к всплеску спроса на продукт. Например, компании по производству и продаже обезумевших могут столкнуться с внезапным всплеском трафика после урагана или другого наводнения, когда люди в пострадавших районах нуждаются в сухом помещении в своем доме.
После определения этих типов шаблонов нагрузки вы можете:
Определите, как изменение нагрузки, связанное с каждым шаблоном, влияет на инфраструктуру.
Автоматизация сборки для надежного масштабирования.
В предыдущих примерах можно использовать следующие стратегии масштабирования:
Статический: у вас есть запланированное масштабирование вычислительных узлов до минимального количества (2) между 11 ВЕЧЕРА и 6 AM EST.
Динамическая, обычная и предсказуемая: у вас есть запланированное горизонтальное масштабирование вычислительных узлов до нормальной ежедневной емкости до начала работы первого региона.
Динамическая, нерегулярная и предсказуемая: вы определяете однократное увеличение масштаба экземпляров вычислительных ресурсов и баз данных утром запуска продукта, а затем выполняете масштабирование после одной недели.
Динамические, нерегулярные и непредсказуемые: пороговые значения автомасштабирования определены для учета незапланированных пиков трафика.
Автоматизация стратегий масштабирования
При проектировании автоматизации масштабирования обязательно учитывайте следующие проблемы:
Все компоненты рабочей нагрузки должны быть кандидатами на масштабирование. В большинстве случаев глобальные службы, такие как идентификатор Microsoft Entra ID , автоматически и прозрачно масштабируемые для вас и ваших клиентов. Не забудьте понять возможности масштабирования сетевых контроллеров и контроллеров исходящего трафика и решения для балансировки нагрузки.
Эти компоненты, которые нельзя масштабировать. Примером будут большие реляционные базы данных, которые не имеют сегментирования и не могут быть рефакторингом без значительного влияния. Задокументируйте ограничения ресурсов, опубликованные поставщиком облачных служб, и внимательно отслеживайте эти ресурсы. Включите эти ресурсы в будущий план миграции в масштабируемые службы.
Время, необходимое для выполнения операции масштабирования, чтобы правильно запланировать операцию, прежде чем дополнительная нагрузка попадает в инфраструктуру. Например, если для масштабирования компонента, например Управление 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.
Если фоновые задачи выполняются в отдельных вычислительных экземплярах, например в рабочих ролях облачного приложения, размещаемого в облачных службах, может потребоваться масштабировать различные части приложения с помощью различных политик масштабирования. Например, может потребоваться развернуть дополнительные вычислительные экземпляры пользовательского интерфейса (UI), не увеличивая количество фоновых вычислительных экземпляров или наоборот. Если вы предлагаете различные уровни обслуживания, такие как базовые и премиум-пакеты служб, может потребоваться увеличить масштаб вычислительных ресурсов для пакетов служб уровня "Премиум" более агрессивно, чем для базовых пакетов служб для удовлетворения соглашений об уровне обслуживания (соглашения об уровне обслуживания).
Рассмотрим длину очереди, по которой взаимодействуют пользовательские интерфейсы и фоновые вычислительные экземпляры. Используйте его в качестве критерия для стратегии автомасштабирования. Эта проблема является одним из возможных индикаторов дисбаланса или разницы между текущей нагрузкой и емкостью обработки фоновой задачи. Немного более сложный, но более лучший атрибут, на котором следует использовать решение о масштабировании между моментом отправки сообщения и завершением его обработки. Этот интервал называется критическим временем. Если это критическое значение времени ниже значимого порогового значения для бизнеса, то не требуется масштабироваться, даже если длина очереди длинна.
Например, в очереди может быть 50 000 сообщений. Но критическое время самого старого сообщения составляет 500 мс, и конечная точка имеет дело с интеграцией с сторонней веб-службой для отправки сообщений электронной почты. Бизнес-заинтересованные лица, скорее всего, считают, что это период времени, который не оправдывает расходы на масштабирование.
С другой стороны, в очереди может быть 500 сообщений с тем же 500-мс критическим временем, но конечная точка является частью критического пути в некоторых онлайн-играх в режиме реального времени, где заинтересованные лица бизнеса определили время отклика в 100 мс или меньше. В этом случае масштабирование имеет смысл.
Чтобы использовать критическое время в решениях автомасштабирования, полезно автоматически добавить соответствующую информацию в заголовки сообщений во время их отправки и обработки. Одна из библиотек, предоставляющая эту функцию, — NServiceBus.
Если вы используете стратегию автомасштабирования на счетчиках, которые измеряют бизнес-процессы, например количество заказов, размещенных в час или среднее время выполнения сложной транзакции, убедитесь, что вы полностью понимаете связь между результатами этих счетчиков и фактическими требованиями к вычислительной емкости. Может потребоваться масштабировать несколько компонентов или единиц вычислений в ответ на изменения счетчиков бизнес-процессов.
Чтобы предотвратить чрезмерное масштабирование системы и избежать затрат, связанных с выполнением многих тысяч экземпляров, рекомендуется ограничить максимальное количество экземпляров, которые добавляются автоматически. Большинство механизмов автомасштабирования позволяют указать минимальное и максимальное количество экземпляров для правила. Кроме того, рассмотрите возможность корректного снижения функциональности, которую предоставляет система, если развернуто максимальное количество экземпляров, и система по-прежнему перегружена.
Помните, что автоматическое масштабирование может не быть наиболее подходящим механизмом для обработки внезапного всплеска рабочей нагрузки. Требуется время для подготовки и запуска новых экземпляров службы или добавления ресурсов в систему, а пиковый спрос может пройти к тому времени, когда эти дополнительные ресурсы доступны. В этом сценарии может потребоваться регулирование службы. Дополнительные сведения см. в описании шаблона регулирования.
И наоборот, если вам нужна емкость для обработки всех запросов, когда объем быстро меняется, и стоимость не является основным фактором, рассмотрите возможность использования агрессивной стратегии автомасштабирования, которая запускает больше экземпляров быстрее. Можно также использовать вариант применения запланированной политики, которая запускает достаточное количество экземпляров для обработки максимальной нагрузки до того, когда эта нагрузка ожидается.
Механизм автомасштабирования должен отслеживать процесс автомасштабирования и регистрировать сведения о каждом событии автомасштабирования (что активировало его, какие ресурсы были добавлены или удалены, а также когда). При создании настраиваемого механизма автоматического масштабирования обязательно реализуйте в нем эту функциональную возможность. Полученные сведения можно проанализировать, чтобы измерить эффективность стратегии автоматического масштабирования и при необходимости адаптировать ее. Ее можно настроить как в краткосрочной перспективе, по мере того, как шаблоны использования становятся более очевидными, так и в долгосрочной перспективе, по мере расширения бизнеса или изменения требований приложения. Если приложение достигает верхнего предела, определенного для автомасштабирования, механизм также может предупредить оператора, который может вручную запустить дополнительные ресурсы при необходимости. В этих обстоятельствах оператор также может отвечать за ручное удаление этих ресурсов после упрощения рабочей нагрузки.
Пример
Ознакомьтесь с руководством по масштабированию эталонной архитектуры AKS.
Дополнительные ссылки
Контрольный список надежности
Ознакомьтесь с полным набором рекомендаций.