Создание многоарендационных SaaS-платформ с безсерверной инфраструктурой

Введение в Multi-Tenant SaaS на безсерверном

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

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

Что такое бессерверная инфраструктура?

Инфраструктура без сервера — это модель выполнения облачных вычислений, в которой облачный провайдер динамически управляет распределением и предоставлением серверов. Код приложения работает в контейнерах вычислений без состояния, которые спровоцированы событиями и полностью управляются провайдером. Наиболее распространенные бессерверные вычислительные услуги включают AWS Lambda, Azure Functions и Google Cloud Functions.

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

Помимо вычислений, бессерверная экосистема включает управляемые сервисы для API (API Gateway), базы данных (Amazon Aurora Serverless, DynamoDB, Firebase Firestore), аутентификацию (Amazon Cognito, Firebase Auth) и обмен сообщениями (SQS, SNS, EventBridge). Эти сервисы вместе образуют полностью управляемый бэкэнд, который устраняет почти все накладные расходы на управление инфраструктурой.

Почему бессерверный сервис является естественным решением для многопользовательского SaaS

Многоарендаторы SaaS-платформы обслуживают множество клиентов (арендаторов) из одного экземпляра приложения. Данные каждого арендатора должны быть изолированы, и платформа должна обрабатывать непредсказуемые рабочие нагрузки между арендаторами. Безсерверные архитектуры согласуются с этими требованиями несколькими способами:

Разработка многопользовательской SaaS-архитектуры

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

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

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

  1. Общая база данных, общая схема (с колонкой идентификатора арендатора): Все арендаторы используют одни и те же таблицы баз данных. Каждая строка включает в себя идентификатор арендатора (например, . Это наиболее экономически эффективный подход, но требует строгого соблюдения безопасности на уровне строк. Безсерверные базы данных, такие как DynamoDB с мелкозернистыми политиками IAM или Firebase Firestore с правилами безопасности, могут эффективно реализовать эту модель. Задержка холодного запуска минимальна, потому что есть один пул соединений.
  2. Общая база данных, отдельные схемы: Каждый арендатор получает свою собственную схему в рамках одной базы данных. Это обеспечивает лучшую логическую изоляцию при сохранении накладных расходов на управление базами данных. Amazon Aurora Serverless поддерживает схему на арендатора и позволяет независимое масштабирование. Основная проблема заключается в управлении миграциями схем во многих арендаторах.
  3. База данных на одного арендатора: Каждый арендатор имеет совершенно отдельный экземпляр базы данных. Это предлагает самую сильную изоляцию — идеально подходит для отраслей с высоким уровнем соответствия (финансы, здравоохранение) или арендаторов с очень большими наборами данных. Безсерверные базы данных, такие как Aurora Serverless, делают это более управляемым, потому что вам не нужно предоставлять и поддерживать каждый экземпляр. Однако стоимость может быть выше, если многие арендаторы имеют низкое использование.

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

Аутентификация и авторизация

Аутентификация пользователя в системе с несколькими арендаторами должна идентифицировать как пользователя, так и его арендатора. Наиболее распространенная стратегия использует централизованного поставщика идентификационных данных (IdP), такого как Amazon Cognito или Auth0. С Cognito вы можете создать единый пул пользователей и использовать пользовательские атрибуты или группы для ассоциирования пользователей с арендаторами. JWT (JSON Web Tokens), выпущенные IdP, должны включать пользовательское требование, такое как или . Ваши бессерверные функции могут затем проверить токен и извлечь контекст арендатора для обеспечения политики доступа к данным.

Для авторизации, реализовать на уровне арендатора на основе атрибутов управления доступом (ABAC), а не на основе ролей управления доступом (RBAC). Используйте политики IAM или пользовательские промежуточное ПО, чтобы ограничить запросы базы данных на основе идентификатора арендатора от JWT. Это гарантирует, что пользователь из арендатора А не может получить доступ к данным, принадлежащим арендатора B, даже если есть ошибка в коде приложения.

Маршрутизация и посадка на борт

Когда поступает запрос, платформа должна определить, к какому арендатору она принадлежит. Общие подходы включают:

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

При аренде на борт необходимо динамически предоставлять ресурсы. Функция без сервера может, например, создать новый кластер баз данных Aurora Serverless или обновить таблицу DynamoDB с конфигурацией нового арендатора. Использование инструментов инфраструктуры в виде кода, таких как AWS CDK или Terraform, автоматизирует этот процесс.

Внедрение безсерверных компонентов для SaaS

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

API Gateway: передняя дверь

Amazon API Gateway (или Azure API Management) выступает в качестве точки входа для всех запросов клиентов. Он обрабатывает аутентификацию, дросселирование и маршрутизацию запросов для функций ниже по течению Lambda. Для многопользовательской работы настройте API Gateway для:

  • Проверяйте JWT и извлекайте контекст арендатора, прежде чем ссылаться на функцию бэкэнда.
  • Используйте планы использования или ключи API для обеспечения соблюдения лимитов ставок на арендатора (например, арендаторы бесплатного уровня получают 1000 запросов / день, а платные арендаторы получают 100 000).
  • Картографируйте пользовательские доменные имена (например, ) и связывайте их с региональными конечными точками или конечными точками, оптимизированными для края, для глобального сокращения задержки.

AWS Lambda: вычислимое сердце

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

  • Используйте одну функцию Lambda для каждой услуги: Избегайте создания отдельных функций для каждого арендатора. Вместо этого передайте идентификатор арендатора как часть полезной нагрузки события. Функция использует его для фильтрации запросов к базе данных.
  • Управление холодными пусками: Использование условной параллели для арендаторов, чувствительных к задержкам, или объединение функций в единый пакет развертывания для сокращения времени запуска. Рассмотрим использование Lambda SnapStart (Java) или Keep-alive pings.
  • Внедрить логинг, учитывающий интересы арендаторов: Включите идентификатор арендатора и идентификатор пользователя в каждое заявление журнала. Используйте структурированную логистику с помощью AWS CloudWatch Logs Insights для отладки между арендаторами.
  • Обработка ошибок: Никогда не утечка ошибок пересечения арендаторов. Поймайте все исключения и верните общие сообщения об ошибках пользователям при входе полные данные внутри.

Услуги базы данных: Хранение данных арендатора

Выбор базы данных напрямую влияет на изоляцию, производительность и стоимость. Выделяются два варианта безсерверной базы данных:

  • Amazon DynamoDB: База данных ключей NoSQL и документов. Для многопользовательской аренды используйте композитный первичный ключ и ключ сортировки (например, или . DynamoDB поддерживает условные записи, транзакции и мелкозернистые политики IAM, которые ограничивают доступ по ключу раздела — идеально подходит для изоляции арендатора. Используйте DynamoDB Accelerator (DAX) для уменьшения задержки для рабочих нагрузок с чтением.
  • Amazon Aurora Serverless: Реляционная база данных, которая масштабируется автоматически. Подходящая для арендаторов, требующих сложных соединений, хранимых процедур или транзакций ACID. С Aurora Serverless v2 можно использовать один кластер с несколькими базами данных (по одной на арендатора) или схема-на-арендатора. Используйте Data API для вызова SQL-запросов по HTTPS, что упрощает управление соединениями в бессерверных функциях.

Какую бы базу данных вы ни выбрали, внедрите дросселирование на уровне арендатора, чтобы предотвратить шумное арендатора от подавляющих общих ресурсов. Используйте DynamoDB за таблицу или применяйте Amazon RDS Proxy для объединения соединений в реляционных базах данных.

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

Amazon Cognito User Pools позволяет легко управлять регистрацией пользователей, входом в систему и MFA для приложений с несколькими арендаторами.

  • Таможенные атрибуты: Добавить атрибут каждому пользователю.Когда пользователь регистрируется, назначьте их арендатора через триггер Lambda (Предварительное подтверждение или Пост-подтверждение).
  • Группы: Группы: Используют группы Cognito для представления десятков ролей (администратора, члена, зрителя) в арендаторах.
  • Пул идентификации: Для федеративного доступа (например, Google, Facebook) или предоставления временных учетных данных AWS для доступа к другим ресурсам используйте Cognito Identity Pools.

Firebase Authentication предлагает аналогичные возможности с проектами для арендаторов. Для корпоративного SaaS рассмотрите встроенную поддержку нескольких арендаторов Auth0 .

Очередь и события-управляемые шаблоны

Бессерверные SaaS-платформы часто нуждаются в асинхронной обработке — например, отправке электронных писем, обработке отчетов или обработке предоставления арендатора. Используйте Amazon SQS (Simple Queue Service) или SNS для разъединения компонентов. Каждое сообщение должно включать идентификатор арендатора для поддержания контекста. Функции Lambda, которые обрабатывают сообщения о очереди, должны проверять разрешения арендатора, прежде чем действовать на основе данных.

Проблемы и стратегии смягчения

Безсерверные многоарендаторы не лишены подводных камней. Упреждающее их решение имеет важное значение для готовности производства.

Холодный старт латентности

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

  • Использование условной параллели для критических функций.
  • Оптимизируйте время выполнения (Python/Node.js запускается быстрее, чем Java/C#).
  • Сохраняйте функции небольшими и уменьшайте нагрузку на зависимость.
  • Объедините несколько обработчиков в одном развертывании функции для увеличения повторного использования.

Продавец Lock-In

Использование управляемых сервисов, таких как DynamoDB, Cognito и Lambda, связывает вас с конкретным поставщиком облачных услуг.

Отладка и наблюдаемость

Бессерверные функции эфемерны, что делает традиционные инструменты отладки неэффективными.

  • Распределенная трассировка с помощью AWS X-Ray или OpenTelemetry.
  • Централизованная регистрация с пользовательскими метриками для ставок ошибок на уровне арендатора, задержки и количества запросов.
  • Предупреждения о пороговых значениях уровня арендатора (например, арендатора, превышающего 10-кратное нормальное использование).

Удушение и предотвращение злоупотреблений

Один арендатор может потенциально потреблять все ресурсы, если дросселирование не происходит. Внедрить ограничение ставки на одного арендатора на уровне API Gateway с использованием планов использования. Для доступа к базе данных применять ограничения пропускной способности для конкретных арендаторов с использованием глобальных вторичных индексов DynamoDB с ключами раздела арендатора и ограничениями пропускной способности чтения/записи. Функции Lambda также должны проверять квоты использования перед обработкой дорогостоящих операций.

Лучшие практики для бессерверных SaaS производства

  • Использовать инфраструктуру как код (IaC): Определить все безсерверные ресурсы (Lambda, API Gateway, таблицы DynamoDB) с использованием AWS CDK, Terraform или Serverless Framework.
  • Реализуйте автоматизацию посадки арендатора: Ресурсы для новых арендаторов с использованием функции шага или событийного конвейера. Например, при регистрации арендатора запустите Lambda, которая создает схему базы данных арендатора, заполняет данные по умолчанию и отправляет приветственное электронное письмо.
  • Отдельная конфигурация арендатора: Храните метаданные арендатора (имя, тип плана, флаги функций) в реестре арендатора — простая таблица DynamoDB, индексируемая идентификатором арендатора.
  • План миграции: Начните с простейшей модели изоляции (общая таблица с идентификатором арендатора) и переформулируйте более строгую изоляцию позже. Используйте стратегии миграции базы данных, такие как изменения схемы нулевого времени простоя (с такими инструментами, как Flyway), чтобы избежать взлома услуг арендатора.
  • Мониторинг затрат арендатором: Используйте AWS Cost Explorer с пользовательскими тегами (например, ), чтобы приписать вычислительные, хранение и сетевые расходы каждому арендатору. Это позволяет вам создавать счета на основе использования и выявлять убыточные учетные записи.
  • Установить аварийное восстановление: Бессерверные сервисы обычно предлагают высокую доступность в пределах региона. Для критических рабочих нагрузок с несколькими арендаторами рассмотрите возможность репликации между регионами для конечных точек DynamoDB (Global Tables) и многорегионального API Gateway для поддержания доступности в случае региональных отключений.

Заключение

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

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

Для дальнейшего чтения, изучите ресурсы AWS SaaS Factory и AWS Well-Architected SaaS Lens для глубокого руководства по созданию масштабируемых многоарендационных систем.