Вы можете объединить несколько задач и операций в единый вычислительный блок. Это повысит эффективность использования вычислительных ресурсов и сократит расходы на выполнение вычислительной обработки в облачных приложениях и управление ею.
Контекст и проблема
В облачных приложениях часто реализованы сразу несколько разных операций. В некоторых решениях имеет смысл изначально следовать принципу разделения проблем и разделять эти операции на отдельные вычислительные единицы, размещенные и развернутые по отдельности (например, как отдельные веб-приложения Служба приложений или отдельные Виртуальные машины). Такая стратегия упрощает логическую структуру решения, но развертывание большого числа вычислительных блоков повышает затраты на размещение среды для приложения и усложняет управление системой.
На приведенном выше рисунке представлен упрощенный пример структуры облачного решения с несколькими вычислительными блоками. Каждый вычислительный блок выполняется в собственной виртуальной среде. Каждая функция реализована как отдельная задача (обозначены буквами от A до E), которая выполняется в своем вычислительном блоке.
Для каждого вычислительного блока используются оплачиваемые ресурсы, даже в периоды простоя или низкой нагрузки. Это означает, что такое решение может оказаться не самым экономичным.
В Azure эта проблема относится к Служба приложений, приложениям контейнеров и Виртуальные машины. Эти элементы выполняются в собственной среде. Выполнение коллекции отдельных веб-сайтов, микрослужб или виртуальных машин, предназначенных для выполнения набора хорошо определенных операций, но которые должны взаимодействовать и сотрудничать в рамках одного решения, могут быть неэффективным использованием ресурсов.
Решение
Чтобы снизить затраты, повысить эффективность использования ресурсов и скорость обмена данными, а также упростить управление, вы можете объединять группы задач и операций в вычислительные блоки.
Задачи можно группировать по разным критериям в зависимости от возможностей, предоставляемых средой, и их стоимости. Часто объединяются задачи со схожими профилями по масштабируемости, периодам существования и требованиям к обработке. Такое группирование позволяет масштабировать задачи как единый блок. Гибкость многих облачных сред дает возможность легко запускать и останавливать экземпляры вычислительных блоков в соответствии с текущей нагрузкой. Например, Azure предоставляет автомасштабирование, которое можно применить к Служба приложений и Масштабируемые наборы виртуальных машин. Дополнительные сведения см. в руководстве по автомасштабированию.
Масштабируемость позволяет определить, какие операции не следует группировать. В качестве примера давайте рассмотрим следующие две задачи.
- В задаче 1 выполняется опрос очереди, чтобы определить сообщения, которые поступают редко и не требуют срочной обработки.
- В задаче 2 обрабатываются большие объемы внезапно возникающего сетевого трафика.
Вторая задача требует эластичности, то есть возможности запускать и останавливать большое число экземпляров вычислительных блоков. Если применить такой же принцип масштабирования к первой задаче, мы просто получим большое число одинаковых задач ожидания для редко поступающих сообщений в одной и той же очереди. Это очевидно бесполезная трата ресурсов.
В многих облачных средах можно найти ресурсы, которые следует поместить в один вычислительный блок, со схожими требованиями к числу ядер ЦП, памяти, дисковому пространству и т. д. Как правило, стоимость растет в прямой зависимости от объема ресурсов. Чтобы сократить затраты, важно максимально загрузить дорогостоящие вычислительные блоки и не допускать для них продолжительного простоя.
Если у вас есть задачи, для которых требуется значительная мощность процессора на короткие периоды времени, попробуйте объединить их в отдельный вычислительный блок, который предоставит необходимую мощность. Но в такой ситуации важно еще и защитить дорогостоящие ресурсы от проблем, связанных с состоянием состязания при чрезмерной нагрузке на них. Например, не следует располагать в одном вычислительном блоке задачи, для которых длительно используется значительная вычислительная мощность.
Проблемы и рекомендации
Реализуя этот шаблон, учитывайте указанные ниже факторы.
Масштабируемость и эластичность. Многие облачные решения поддерживают масштабируемость и эластичность на уровне вычислительного блока, запуская и останавливая его дополнительные экземпляры. Старайтесь не группировать в одном вычислительном блоке задачи с противоречивыми требованиями к масштабируемости.
Время существования. В облачной инфраструктуре периодически удаляются виртуальные среды, в которых размещены вычислительные блоки. Если в одном вычислительном блоке выполняется сразу несколько длительных задач, укажите дополнительные настройки для защиты этого блока от удаления до завершения всех задач. Еще один вариант решения такой проблемы: используйте принцип контрольных точек, который позволит правильно завершать выполнение задач и возобновлять его с того же момента, когда вычислительный блок будет перезапущен.
Частота изменений. Если у вас часто меняется способ реализации или конфигурация задач, для обновления кода и (или) изменения настроек вам придется часто останавливать и перезапускать соответствующий вычислительный блок. Это означает, что остановка, развертывание и повторный запуск коснутся и всех других задач в том же вычислительном блоке.
Безопасность. Задачи в одном вычислительном блоке могут иметь одинаковый контекст безопасности и обращаться к одним и тем же ресурсам. Требуется высокий уровень доверия между задачами и уверенность в том, что ни одна из них не будет препятствовать другим или негативно на них влиять. Кроме того, увеличение числа задач в вычислительном блоке повышает его уязвимость для атак. Каждая из задач в блоке будет иметь тот же уровень безопасности, что и задача с самой высокой степенью уязвимости.
Отказоустойчивость. Если любая задача в вычислительном блоке завершится сбоем или в ее рамках будут выполнены некорректные действия, это может повлиять на другие задачи в том же вычислительном блоке. Например, если одна из задач не запускается корректным образом, нарушается вся логика запуска в этом вычислительном блоке. Это может помешать запуску остальных задач в блоке.
Состязание. Избегайте ситуаций состязания за ресурсы между задачами в одном вычислительном блоке. Очень желательно, чтобы в одном вычислительном блоке размещались задачи с разными характеристики по использованию ресурсов. Например, не стоит группировать в один вычислительный блок две задачи с высокой вычислительной нагрузкой или потреблением памяти. Однако сочетание вычислительной задачи с задачей, требующей большого объема памяти, является работоемкой комбинацией.
Примечание.
Рассмотрите возможность консолидации вычислительных ресурсов только для системы, которая находится в рабочей среде в течение определенного периода времени, чтобы операторы и разработчики могли отслеживать систему и создавать тепловую карту , которая определяет, как каждая задача использует разные ресурсы. Такая карта позволит определить, какие задачи целесообразно размещать в общих вычислительных ресурсах.
Сложность. Объединение нескольких задач в один вычислительный блок усложняет код этого блока, что может затруднить тестирование, отладку и поддержку.
Стабильная логическая архитектура. Проектируйте и создавайте код каждой задачи так, чтобы его не нужно было изменять даже при изменениях физической среды, в которой выполняется задача.
Другие стратегии. Группирование вычислительных ресурсов — лишь один из многих способов снижения затрат, связанных с параллельным выполнением большого числа задач. Чтобы этот подход сохранил эффективность, его нужно тщательно планировать и постоянно контролировать. Возможно, другие стратегии будут более эффективными, учитывая характер ваших задач и местонахождение пользователей. Например, оптимальным решением может оказаться функциональная декомпозиция рабочей нагрузки (как описано в руководстве по секционированию вычислений).
Когда следует использовать этот шаблон
Этот шаблон применим для задач, которые недостаточно экономичны при выполнении в отдельном вычислительном блоке. Если задача значительное время находится в состоянии простоя, отдельный вычислительный блок для такой задачи будет дорогостоящим решением.
Этот шаблон не слишком подходит для задач, в рамках которых выполняются операции с критически важным уровнем отказоустойчивости или обрабатываются крайне важные и конфиденциальные данные, то есть для задач, требующих особого контекста безопасности. Такие задачи следует выполнять в собственной изолированной среде, помещенной в отдельный вычислительный блок.
Проектирование рабочей нагрузки
Архитектор должен оценить, как шаблон консолидации вычислительных ресурсов можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах платформы Azure Well-Architected Framework. Например:
| Принцип | Как этот шаблон поддерживает цели основных компонентов |
|---|---|
| Оптимизация затрат ориентирована на поддержание и улучшение рентабельности инвестиций рабочей нагрузки. | Этот шаблон обеспечивает максимальное использование вычислительных ресурсов, избегая неиспользуемой подготовленной емкости путем агрегирования компонентов или даже целых рабочих нагрузок в пулной инфраструктуре. - Консолидация CO:14 |
| Операционное превосходство помогает обеспечить качество рабочей нагрузки через стандартизированные процессы и сплоченность команды. | Консолидация может привести к более однородной вычислительной платформе, которая может упростить управление и наблюдаемость, уменьшить разрозненные подходы к операционным задачам и сократить объем необходимых средств. - Система мониторинга OE:07 - Проектирование автоматизации OE:10 |
| Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода. | Консолидация обеспечивает максимальное использование вычислительных ресурсов с помощью емкости свободного узла и снижения необходимости перепроизбытки. Крупные (вертикально масштабируемые) вычислительные экземпляры часто используются в пуле ресурсов для этих инфраструктур. - Планирование емкости PE:02 - PE:03 Выбор служб |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.
Выбор платформы приложений
Этот шаблон можно достичь разными способами в зависимости от используемой вычислительной службы. См. следующие примеры служб:
- приложение Azure служба и Функции Azure. Развертывание общих планов Служба приложений, представляющих инфраструктуру сервера размещения. Вы можете настроить одно или несколько приложений для выполнения на одних вычислительных ресурсах (или в одном плане службы приложений).
- Приложения контейнеров Azure: развертывание контейнерных приложений в одних и тех же общих средах, особенно в ситуациях, когда необходимо управлять связанными службами или развертывать разные приложения в одной виртуальной сети.
- Служба Azure Kubernetes (AKS): AKS — это инфраструктура размещения на основе контейнеров, в которой можно настроить несколько приложений или компонентов приложений для совместного запуска на одном вычислительных ресурсах (узлах), сгруппированных по вычислительным требованиям, таким как потребности ЦП или памяти (пулы узлов).
- Виртуальные машины: разверните один набор виртуальных машин для всех клиентов, чтобы затраты на управление распределялись между клиентами. Масштабируемые наборы виртуальных машин — это функция, которая поддерживает управление общими ресурсами, балансировку нагрузки и горизонтальное масштабирование Виртуальные машины.
Связанные ресурсы
При реализации этого шаблона следует принять во внимание следующие шаблоны и рекомендации.
Руководство по автоматическому масштабированию. Автомасштабирование позволяет запускать и останавливать экземпляры службы, в которой размещаются вычислительные ресурсы, в зависимости от ожидаемой потребности в обработке.
Compute Partitioning Guidance (Рекомендации по секционированию вычислений). В этом руководстве описан метод выделения служб и компонентов в облачной службе, который позволяет снизить эксплуатационные расходы при сохранении всех важных характеристик службы: масштабируемости, производительности, доступности и безопасности.
Архитектурные подходы для вычислений в мультитенантных решениях. Предоставляет рекомендации по рекомендациям и требованиям, необходимым для архитекторов решений, при планировании вычислительных служб мультитенантного решения.