Шаблон консолидации вычислительных ресурсов

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

Контекст и проблема

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

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

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

Решение

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

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

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

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

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

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

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

Проблемы и рекомендации

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

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

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

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

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

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

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

  Замечание

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

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

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

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

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

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

Этот шаблон может быть не подходит, если:

• Задачи выполняют отказоустойчивые критически важные операции.
• Задачи обрабатывают конфиденциальные или частные данные и требуют собственного контекста безопасности.
• Задачи должны выполняться в отдельной изолированной среде в отдельной вычислительной единице.

Проектирование рабочей нагрузки

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

Если этот шаблон вводит компромиссы внутри столпа, рассмотрите их против целей других столпов.

Пример

Этот шаблон можно развернуть разными способами в зависимости от вычислительной службы. Рассмотрим пример.

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

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

• Служба Azure Kubernetes (AKS): AKS — это инфраструктура размещения на основе контейнеров, в которой можно настроить несколько приложений или компонентов приложений для совместного выполнения на одних вычислительных ресурсах (узлах). Вычислительные ресурсы можно сгруппировать по вычислительным требованиям, таким как потребности ЦП или памяти (пулы узлов).

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

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

Дальнейшие действия

• Well-Architected Framework — оптимизация затрат

Связанные ресурсы

• Шардинг
• Выбор службы вычислений Azure
• Архитектурные подходы для вычислений в мультитенантных решениях