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

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

  • Статья

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

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

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

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

Масштабировать

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

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

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

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

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

Независимо от того, какой подход используется для масштабирования, обычно необходимо спланировать триггеры, которые вызывают масштабирование компонентов. Если у вас есть общие компоненты, рассмотрите шаблоны рабочих нагрузок каждого клиента, использующего ресурсы, для обеспечения того, чтобы подготовленная емкость соответствовала общей требуемой емкости, и чтобы свести к минимуму вероятность возникновения проблемы с шумным соседом клиента. Вы также можете спланировать масштабируемую емкость, учитывая количество клиентов. Например, если вы измеряете ресурсы, используемые для обслуживания 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 Load Testing, чтобы узнать, как работает ваше приложение под стрессом.

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

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

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

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

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

Соавторы

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

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

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

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

Следующие шаги

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