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

Архитектурные подходы для вычислений в мультитенантных решениях

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

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

Основные рекомендации и требования

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

Шкала

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

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

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

Проблемы с производительностью часто остаются незамеченными до тех пор, пока приложение не будет загружено. Вы можете использовать полностью управляемую службу, например Azure Load Testing, чтобы узнать, как ваше приложение работает под стрессом.

Триггеры масштабирования

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

Государство

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

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

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

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

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

Это важно

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

Изоляция

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

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

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

Подходы и шаблоны, которые следует учитывать

Автомасштабирование

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

Шаблон меток развертывания (Deployment Stamps)

Дополнительные сведения о том, как использовать шаблон меток развертывания для поддержки мультитенантного решения, см. в разделе "Архитектурные подходы" для мультитенантного решения.

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

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

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

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

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

  • Приложения-контейнеры: Развертывание общих сред.

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

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

Выделенные вычислительные ресурсы для каждого клиента

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

В зависимости от используемых служб вычислений Azure может потребоваться развернуть различные выделенные ресурсы:

  • Служба приложений и функции Azure: Разверните отдельные планы службы приложений для каждого клиента.

  • Контейнерные приложения: Развертывание отдельных сред для каждого клиента.

  • AKS: Развертывание выделенных кластеров для каждого клиента.

  • ВМ: Разверните отдельные виртуальные машины для каждого арендатора.

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

Полуизолированные вычислительные ресурсы

Полуизолированные подходы требуют развертывания аспектов решения в изолированной конфигурации при совместном использовании других компонентов.

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

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

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

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

  • Узлы или пулы узлов для конкретного клиента в общем кластере

  • Pod'ы, специфичные для арендатора, которые могут использовать тот же пул узлов

Вы также можете использовать AKS для применения управления на уровне pod'ов для устранения проблемы шумного соседа. Для получения дополнительной информации см. Лучшие практики для разработчиков приложений по управлению ресурсами в AKS.

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

Антипаттерны, которых следует избегать

Избегайте следующих антипаттернов.

Шумный сосед антипаттерн

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

Утечка данных между клиентами

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

Антипаттерн перегруженного интерфейса

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

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

Неэластичное или недостаточное масштабирование

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

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

Антипаттерн «Отсутствие кэширования»

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

Ненужное состояние

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

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

  • Диксит Арора | Старший инженер по работе с клиентами, FastTrack для Azure
  • Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure

Другие участники:

  • Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Ознакомьтесь с рекомендациями для конкретных служб вычислений:

  • Last updated on