Разработка многопользовательских приложений для поставщиков SaaS на Azure

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

Понимание мультитенсификации в SaaS

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

Поставщики Azure SaaS обычно сталкиваются с тремя решениями: степенью изоляции, вычислительной моделью (PaaS против IaaS против контейнеров) и архитектурой хранения. Понимание этих компромиссов на раннем этапе предотвращает дорогостоящую реархитектуру позже.

Основные принципы проектирования для многопользовательских приложений на Azure

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

Изоляция

Данные и конфигурация никогда не должны просачиваться между арендаторами. Изоляция может быть логичной (идентификаторы арендаторов на уровне строк в общей базе данных) или физической (отдельные базы данных, учетные записи хранения или даже отдельные подписки). База данных Azure SQL и Azure Cosmos DB поддерживают оба подхода с политиками безопасности строк арендатора и ключами на уровне контейнеров. С вычислительной стороны планы Azure App Service могут быть совместно использованы, но для более строгой изоляции следует рассмотреть Azure Kubernetes Service (AKS) с конкретными пространствами имен арендаторов или даже выделенными пулами узлов.

Масштабируемость

Многоарендаторы испытывают непредсказуемые всплески, поскольку некоторые арендаторы быстро растут, а другие остаются стабильными. Возможности автомасштабирования Azure, такие как правила масштабирования App Service, автомасштабируемый кластер AKS и эластичные пулы базы данных Azure SQL, позволяют вам поглощать рост без вмешательства вручную. Разработайте состояние сеанса без состояния и выгрузки в Azure Cache для Redis или Cosmos DB. Используйте Azure Load Balancer или Azure Front Door для распределения трафика по масштабируемым экземплярам.

Безопасность

Каждый арендатор должен быть изолирован от всех других арендаторов, а аутентификация арендатора должна быть надежной. Используйте Azure Active Directory (Azure AD) с специфичными для арендатора функциями B2C или B2B для федерации идентификации. Для связи между арендатором и службой полагайтесь на управляемые идентификаторы и хранилище ключей Azure, чтобы избежать секретов жесткого кодирования. Внедряйте авторизацию с учетом арендатора в шлюзе API - Управление API Azure может обеспечить валидацию токенов и ограничение скорости на арендатора. Регистрация и аудит должны захватывать контекст арендатора, не разоблачая конфиденциальные данные через границы.

Управление затратами

Общая инфраструктура снижает стоимость на одного арендатора, но неоптимизированное использование может тратить деньги. Используйте Azure Cost Management для маркировки ресурсов арендатором и отслеживания расходов. Объедините зарезервированные экземпляры с автомасштабированием для обработки базовой нагрузки дешево и масштабируйте премиальные экземпляры для пиков. Эластичные пулы баз данных позволяют объединять ресурсы между арендаторами, оплачивая только совокупное использование DTU / vCore, а не предоставление для пика индивидуально. Всегда оценивайте, соответствует ли общая или выделенная стратегия ресурсов вашей модели ценообразования (например, на одно место против потребления).

Стратегии изоляции данных

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

Единая база данных, общая схема

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

Отдельные базы данных (база данных на одного арендатора)

Каждый арендатор получает свою собственную базу данных (и, возможно, свой собственный сервер или эластичный пул). Это обеспечивает самую сильную изоляцию - разделение физических данных - и упрощает соблюдение (например, резидентность данных GDPR). Резервное копирование, восстановление и настройка производительности могут быть сделаны на одного арендатора. Компромиссы - это операционная сложность (сотни или тысячи баз данных для управления) и более высокие накладные расходы. пулы Azure Elastic Database помогают управлять расходами, группируя мелких арендаторов в пулы общей емкости, в то время как крупные арендаторы могут быть размещены в специализированных пулах. Упругий запрос Azure SQL Database и запросы кросс-базы данных позволяют сообщать о кросс-арендаторах, когда это необходимо.

Гибридные подходы

Многие провайдеры SaaS принимают многоуровневую стратегию: бесплатные или пробные арендаторы имеют общую базу данных, в то время как арендаторы премиум-класса получают выделенные базы данных. Альтернативно, некоторые данные (например, общедоступные каталоги, справочные данные) могут совместно использоваться, в то время как частные данные изолированы. Осколки Azure SQL Database и возможности федерации поддерживают гибридные модели. Например, вы можете использовать одну общую базу данных для аутентификации и метаданных арендатора, а затем маршрутизировать транзакционные данные каждого арендатора в свой собственный осколок или базу данных. Azure Cosmos DB также поддерживает гибридную изоляцию с ключами разделов, которые могут отображаться в логических арендаторах, в сочетании с отдельными контейнерами для арендаторов, которым нужны более сильные границы.

Использование Azure для мультитенсификации

Помимо хранения данных, Azure предлагает полную платформу для работы с SaaS-решениями с несколькими арендаторами.

Вычислить и хостинг

Azure App Service является точкой входа для многих поставщиков SaaS. Он поддерживает автоматическое масштабирование, развертывание слотов и встроенную аутентификацию. Для большего контроля над средой выполнения Azure Kubernetes Service (AKS) позволяет изолировать арендаторов через пространства имен, сетевые политики и квоты ресурсов. AKS также интегрируется с Azure AD для управления доступом на основе ролей. Для бессерверных архитектур Azure Functions может быть арендатором, используя входные привязки и учетные записи для арендаторов.

Хранение и база данных

Мы уже обсуждали Azure SQL Database и Cosmos DB. Для хранения блоб или файлов Azure Blob Storage поддерживает изоляцию арендаторов на уровне контейнеров. Вы можете генерировать токены SAS для арендаторов и обеспечивать соблюдение политик доступа с помощью Azure RBAC. Учетная запись Azure Storage на арендатора также является вариантом для высокой изоляции, но она увеличивает накладные расходы управления. Azure Cache для Redis может быть разделен на арендатора с использованием отдельных баз данных или ключевых префиксов.

Управление идентификацией и доступом

Azure AD B2C (business-to-consumer) предназначен для SaaS с внешними арендаторами. Он поддерживает пользовательские политики, поставщиков социальной идентификации и многофакторную аутентификацию на арендатора. Для корпоративного SaaS, где арендаторы являются организациями, Azure AD B2B (business-to-business) позволяет пользователям входить в систему с учетными данными своей организации. Оба интегрируются с Azure API Management для обеспечения проверки токенов. Используйте управляемые идентификаторы для ресурсов Azure, чтобы избежать хранения учетных данных в вашем коде.

Безопасность и секреты

Azure Key Vault хранит секреты, строки соединений и сертификаты для арендаторов. Вы можете предоставить доступ к отдельным службам или разработчикам, используя политики доступа к хранилищам и RBAC. Для шифрования в режиме покоя база данных Azure SQL поддерживает прозрачное шифрование данных (TDE) с ключами, управляемыми клиентами, хранящимися в Key Vault - ключи могут быть на арендатора, если это необходимо. Политика Azure и Azure Blueprints помогают обеспечить соблюдение требований арендатора (например, геоограничения, разрешенные типы ресурсов) в масштабе.

Мониторинг и наблюдаемость

Azure Monitor и Application Insights необходимы для устранения неполадок с несколькими арендаторами. Отметьте всю телеметрию идентификатором арендатора - либо в пользовательских свойствах, либо через процессор обогащения. Создайте правила оповещения, которые отключают арендатора при нарушении пороговых значений (например, процессор базы данных > 80% для конкретного арендатора). Используйте Azure Log Analytics и KQL для исследования производительности арендатора без утечки данных перекрестного арендатора. Рассмотрите возможность использования Azure Managed Grafana для панелей мониторинга, которые ограничены ролью арендатора.

Реализация многотенантных моделей

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

Shared Everything (Single Application Instance, Shared Database)

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

База данных, отдельные схемы

Арендаторы имеют общую базу данных, но имеют отдельные схемы (например, tenant 123.orders вместо столбца tenant id). Это обеспечивает лучшую логическую изоляцию и позволяет резервное копирование по схеме (хотя Azure SQL Database изначально не поддерживает резервное копирование на уровне схемы - вы бы резервное копирование всей базы данных). Поддержание сложнее, потому что миграции схем должны применяться во всех схемах арендатора, часто через скрипты. Этот шаблон редко используется сегодня, потому что безопасность уровня строк обеспечивает аналогичную изоляцию с меньшими накладными расходами.

Отдельные базы данных (база данных на одного арендатора)

У каждого арендатора есть своя база данных и, возможно, свой собственный эластичный пул или сервер. Этот шаблон предлагает самую сильную изоляцию, самую гибкость для конфигурации арендатора и самое простое соответствие (просто удалите арендатора, удалив его базу данных). Недостатком является накладные расходы на управление - вам нужно создавать сценарии, резервное копирование и миграционные действия для многих баз данных. Azure Elastic Jobs, Azure Automation и Azure CLI могут помочь. Для тысяч арендаторов, шардированная база данных на арендатора является обычным явлением.

Гибридные и комбинированные модели

Многие зрелые поставщики SaaS объединяют шаблоны. Например, используют общую базу данных для метаданных арендатора, конфигураций и журналов аудита и выделяют базы данных для арендаторов выше определенного порога дохода. Или объединяют мелких арендаторов вместе в эластичные пулы и размещают крупных арендаторов в выделенные пулы. Осколки Azure SQL Database (с помощью инструментов Elastic Database) поддерживают этот подход, направляя запросы к правильному осколку на основе ключа арендатора.

Лучшие практики для многопользовательских приложений Azure SaaS

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

Заключение

Проектирование приложений с несколькими арендаторами на Azure не является универсальным упражнением. Правильная архитектура балансирует изоляцию, масштабируемость, безопасность и стоимость на основе вашего конкретного профиля арендатора и бизнес-модели. Обширный портфель услуг Azure - от App Service и Azure SQL Database до Azure AD B2C и Key Vault - обеспечивает строительные блоки для реализации любого шаблона, от полностью совместного до полностью специализированного. Следуя принципам и передовым практикам, изложенным в этой статье, поставщики SaaS могут предоставлять надежные, безопасные и экономически эффективные решения с несколькими арендаторами, которые растут со своими клиентами. Для дальнейшего чтения изучите официальное руководство Azure по многоарендационной архитектуре , эластичные пулы и , осведомленная о арендаторах платформа идентификации Microsoft .