Поделиться через

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

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

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

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

Определения

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

Замечание

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

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

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

Основные стратегии проектирования

Проектирование в соответствии с шаблонами загрузки

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

  • Статический: Каждую ночь на 11 вечера EST число активных пользователей приложения снижается до 100, а загрузка ЦП для серверов приложений снижается на 90% на всех узлах. Для этого можно запланировать уменьшение количества вычислительных узлов до минимального (2) между 11 ВЕЧЕРА и 6 УТРА по восточному времени.

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

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

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

Адаптация стратегий масштабирования для соответствия отдельным компонентам или потокам

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

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

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

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

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

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

Выбор правильной технологии

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

  • Воспользуйтесь службами, которые автоматически масштабируются. По возможности используйте службы SaaS, которые автоматически масштабируются без каких-либо настроек или входных данных. Глобальные службы, такие как Идентификатор Microsoft Entra, предлагают эту функцию. Бессерверные решения также предлагают автоматическое масштабирование и могут быть хорошим выбором для многих вариантов использования.

  • Воспользуйтесь преимуществами служб, которые предлагают готовое масштабирование. Многие службы PaaS предлагают интегрированные удобные функции масштабирования, которые можно настроить в соответствии с требованиями к надежности. Например, можно настроить масштабирование пропускной способности для Cosmos DB в соответствии с конкретными требованиями.

Автоматизация масштабирования

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

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

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

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

Выбор соответствующих единиц масштабирования

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

  • Масштабирование ресурсов по отдельности: может потребоваться только масштабирование отдельных виртуальных машин или баз данных.

  • Масштабирование полного компонента одновременно: Например, у вас может быть API микрослужбы, состоящий из службы приложений, базы данных и очередей, которые должны масштабироваться одновременно.

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

Это важно

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

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

При разработке стратегии масштабирования следует учитывать, что различные службы масштабируемые в разных масштабах времени. Существуют некоторые службы, которые масштабируются почти мгновенно и другие, которые масштабируются гораздо медленнее. Например, в экземплярах API Management операции масштабирования могут занимать до 45 минут. Чтобы учесть временные рамки операции масштабирования, правильно спланируйте её выполнение до того, как ожидаемый рост нагрузки начнёт влиять на вашу систему. Другие рекомендации, которые следует рассмотреть, включают:

  • Чтобы сократить время, необходимое для инициализации, предварительно инициализируйте узлы, которые будут развернуты.

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

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

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

Масштабирование хранилищ данных с помощью сегментирования и секционирования

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

  • Горизонтальное секционирование (сегментирование): секции (сегменты) помещаются в отдельные хранилища данных, но все секции имеют одну схему. Каждый сегмент содержит подмножество базы данных. Это хороший подход к оптимизации надежности, так как он помогает упростить балансировку нагрузки и свести к минимуму нагрузку на операции при работе с проблемами. Шарды можно реплицировать для повышения надежности.

  • Вертикальное секционирование: каждая секция содержит подмножество полей для элементов в хранилище данных. Поля разделены по их шаблону использования.

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

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

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

Подробные рекомендации по секционированию и сегментированию см. в руководстве по проектированию

Мониторинг операций масштабирования

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

Упрощение функций Azure

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

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

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

Компромиссы

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

Пример

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

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

Ознакомьтесь с полным набором рекомендаций.

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