Share via

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

  • Статья

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

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

Ключевые рекомендации и требования

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

Масштабирование

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

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

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

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

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

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

Состояние

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

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

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

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

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

Важно!

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

Изоляция

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

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

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

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

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

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

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

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

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

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

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

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

  • Служба приложений Azure и Функции Azure. Развертывание планов общих Служба приложений, представляющих инфраструктуру сервера размещения.
  • Контейнеры приложений Azure: развертывание общих сред.
  • Служба Azure Kubernetes (AKS): развертывание общих модулей pod с помощью мультитенантного приложения.
  • Виртуальные машины. Разверните один набор виртуальных машин для использования всеми клиентами.

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

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

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

  • Служба приложений Azure и Функции Azure. Разверните отдельные планы Служба приложений для каждого клиента.
  • Контейнеры приложений Azure: разверните отдельные среды для каждого клиента.
  • Служба Azure Kubernetes (AKS): развертывание выделенных кластеров для каждого клиента.
  • Виртуальные машины. Разверните выделенные виртуальные машины для каждого клиента.

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

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

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

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

Служба Azure Kubernetes (AKS) и Kubernetes в более широком смысле предоставляют различные варианты мультитенантности, в том числе следующие:

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

AKS также позволяет применять управление на уровне pod, чтобы устранить проблему "Шумный сосед". Дополнительные сведения см. в статье Рекомендации для разработчиков приложений по управлению ресурсами в Служба Azure Kubernetes (AKS).

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

Неподходящие антишаблоны

Антишаблон "шумный сосед"

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

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

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

Антишаблон загруженности внешнего интерфейса

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

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

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

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

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

Антишаблон без кэширования

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

Ненужная отслеживание состояния

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

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально она была написана следующими авторами.

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

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

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

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

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