Introduction à SaaS multi-tendants sur sans serveur

La mise en place d'une plateforme multi-tantiel Software a-a-Service (SaaS) est une entreprise complexe qui exige une conception soignée autour de l'évolutivité, de la sécurité et de l'efficacité. L'essor de l'infrastructure sans serveur a fondamentalement changé la façon dont les développeurs abordent ces défis, offrant un chemin pour construire des systèmes très élastiques, payants sans le fardeau de la gestion de serveurs traditionnels. Que vous soyez une startup qui lance votre premier produit SaaS ou une équipe établie qui modernise une application existante, comprendre comment combiner l'architecture multi-tantiel avec des composants sans serveur est essentiel pour le succès à long terme.

Cet article fournit un guide complet axé sur la production pour construire des plateformes SaaS multi-tenues sur une infrastructure sans serveur. Nous explorerons les concepts de base, nous plongerons dans les détails de mise en œuvre pour chaque composant clé, et discuterons des compromis que vous devez envisager pour fournir une solution robuste, sécurisée et rentable.

Qu'est-ce que l'infrastructure sans serveur?

L'infrastructure sans serveur est un modèle d'exécution de calcul en nuage dans lequel le fournisseur de cloud gère dynamiquement l'allocation et la fourniture des serveurs. Le code d'application fonctionne dans des conteneurs de calcul apatrides qui sont déclenchés par des événements et entièrement gérés par le fournisseur.

Dans une architecture sans serveur, vous ne fournissez plus, ne corrigez pas ou n'évaluez plus les instances du serveur. Vous téléchargez votre code et définissez les événements qui devraient déclencher son exécution (par exemple, requêtes HTTP, modifications de base de données, téléchargements de fichiers). Le fournisseur évalue automatiquement les ressources informatiques en hausse ou en baisse, souvent à zéro, en fonction de la demande.

Au-delà du calcul, l'écosystème sans serveur comprend des services gérés pour les API (API Gateway), des bases de données (Amazon Aurora Serverless, DynamoDB, Firebase Firestore), l'authentification (Amazon Cognito, Firebase Auth) et la messagerie (SQS, SNS, EventBridge). Ces services forment ensemble un backend entièrement géré qui élimine presque tous les frais généraux de gestion de l'infrastructure.

Pourquoi sans serveur est un naturel pour SaaS multi-tendants

Les plateformes SaaS multi-locataires servent de nombreux clients (locataires) à partir d'une seule instance d'application. Les données de chaque locataire doivent être isolées et la plateforme doit gérer des charges de travail imprévisibles à travers les locataires.

  • Élasticité automatique:[ Les fonctions sans serveur s'échellent horizontalement sans intervention humaine. Lorsque l'utilisation d'un locataire augmente, l'infrastructure se développe instantanément sans affecter les autres locataires.
  • Prix à la carte:[ Vous ne payez que pour les ressources que chaque locataire consomme. Cela harmonise le coût directement avec la valeur, ce qui rend économiquement viable de soutenir de nombreux petits locataires sans gaspiller de l'argent sur la capacité inactive.
  • Complexité opérationnelle réduite:[ Serverless élimine les patchages de serveur, la planification de la capacité et la configuration haute disponibilité. Votre équipe se concentre sur la logique d'affaires, le locataire à bord et l'isolement des données plutôt que l'hygiène de l'infrastructure.
  • Des modèles multi-tendances simplifiés: Des services gérés comme Amazon Cognito et Firebase Authentification offrent un support intégré pour les piscines utilisateurs multi-tenus. Les bases de données sans serveur peuvent imposer l'isolement des locataires par la sécurité au niveau de la ligne ou des stratégies de schéma par locataire sans intergiciel personnalisé.
  • Faster Time to Market: Parce que sans serveur réduit le besoin de fournir et de configurer l'infrastructure, les équipes de développement peuvent itérer rapidement et expédier les fonctionnalités plus rapidement — un avantage critique sur les marchés concurrentiels de SaaS.

Conception de votre architecture SaaS multi-tendants

Une plateforme SaaS multi-tenue bien archivée sur serveur sans serveur doit traiter de l'isolement des données, de l'authentification, du routage et de la facturation.

Stratégies d'isolement des données sur les locataires

L'isolement des données est la décision architecturale la plus importante dans un système multi-locataires. Il existe trois modèles communs, chacun avec des compromis différents:

  1. Base de données partagée, Schéma partagé (avec colonne d'identification du locataire): Tous les locataires partagent les mêmes tables de base de données. Chaque ligne comprend un identifiant du locataire (p. ex. ). C'est l'approche la plus rentable, mais nécessite une application rigoureuse de la sécurité au niveau des lignes.
  2. Base de données partagée, schémas séparés: Chaque locataire obtient son propre schéma dans une seule base de données. Cela fournit une meilleure isolation logique tout en maintenant la gestion de base de données à faible altitude. Amazon Aurora Serverless prend en charge le schéma par locataire et permet une échelle indépendante.
  3. Base de données Par locataire: Chaque locataire a une instance de base de données complètement séparée. Ceci offre l'isolement le plus fort — idéal pour les industries exigeantes en conformité (finances, soins de santé) ou les locataires avec des ensembles de données très importants.

Votre choix dépend des exigences de sécurité, du budget et de la maturité opérationnelle de vos locataires. De nombreuses start-ups commencent par l'approche de base de données partagée et migrent vers les bases de données par locataire à mesure qu'elles grandissent.

Authentification et autorisation

L'authentification de l'utilisateur dans un système multi-locataires doit identifier l'utilisateur et son locataire. La stratégie la plus courante utilise un fournisseur d'identité centralisé (IdP) comme Amazon Cognito ou Auth0. Avec Cognito, vous pouvez créer un seul bassin d'utilisateurs et utiliser des attributs ou des groupes personnalisés pour associer les utilisateurs aux locataires. JWTs (JSON Web Tokens) émis par l'IdP devrait inclure une revendication personnalisée comme ou . Vos fonctions sans serveur peuvent alors valider le jeton et extraire le contexte locataire pour faire appliquer les politiques d'accès aux données.

Pour l'autorisation, mettre en œuvre le contrôle d'accès basé sur les attributs (ABAC) plutôt que le contrôle d'accès basé sur le rôle (RBAC) au niveau du locataire. Utilisez les politiques IAM ou le middleware personnalisé pour limiter les requêtes de base de données basées sur l'ID du locataire de la JWT. Cela garantit qu'un utilisateur du locataire A ne peut pas accéder aux données appartenant au locataire B, même s'il y a un bug dans votre code d'application.

Routage et embarquement des locataires

Lorsqu'une demande arrive, la plateforme doit identifier à quel locataire elle appartient. Les approches communes comprennent:

  • Acheminement par sous-domaine:[ Chaque locataire a un sous-domaine unique (p. ex. ]. Votre API Gateway ou load balancer inspecte l'en-tête pour les demandes d'acheminement à la logique appropriée propre au locataire.
  • Renvoi basé sur la trajectoire:[ L'identificateur de locataire fait partie du chemin URL (p. ex. ). Ceci est plus simple mais peut entraîner des frais généraux supplémentaires d'analyse.
  • Acheminement en tête/cookie:[ L'ID du locataire est passé dans un en-tête personnalisé ou une revendication JWT. Ceci est souvent combiné avec l'authentification utilisateur.

Une fonction sans serveur peut, par exemple, créer un nouveau cluster de base de données Aurora sans serveur ou mettre à jour une table DynamoDB avec la nouvelle configuration du locataire. L'utilisation d'outils d'infrastructure comme code comme AWS CDK ou Terraform automatise ce processus.

Mise en œuvre des composants sans serveur pour SaaS

Maintenant, examinons les composants sans serveur que vous utiliserez et comment les configurer pour des contenus multiples.

API Gateway : La porte d'entrée

Amazon API Gateway (ou Azure API Management) agit comme point d'entrée pour toutes les requêtes client. Il gère l'authentification, le grottling et le routage vers les fonctions Lambda en aval. Pour les multi-tenancy, configurer API Gateway vers:

  • Valider les JWT et extraire le contexte du locataire avant d'invoquer la fonction de moteur.
  • Utilisez des plans d'utilisation ou des clés API pour imposer des limites de tarifs par locataire (p. ex., les locataires de palier gratuit obtiennent 1000 demandes par jour, les locataires payés obtiennent 100 000).
  • Les noms de domaine personnalisés (p. ex. ) et les associer à des paramètres régionaux ou à des paramètres optimisés par le bord pour la réduction de la latence mondiale.

AWS Lambda: Le coeur calculateur

Dans un système multi-locataires, chaque invocation de fonction reçoit un objet contextuel contenant l'ID du locataire, l'ID de l'utilisateur et toute autre revendication pertinente. Les meilleures pratiques sont les suivantes :

  • Utilisez une seule fonction Lambda par service:[ Évitez de créer des fonctions distinctes pour chaque locataire. Au lieu de cela, passez l'ID du locataire dans le cadre de la charge utile de l'événement. La fonction l'utilise pour filtrer les requêtes de base de données.
  • Manage cold starts:[ Utilisation Concurrence prévue pour les locataires sensibles à la latence ou combiner des fonctions dans un seul paquet de déploiement pour réduire le temps de démarrage.
  • Logage de locataire-connaisseur d'installation:[ Inclure l'ID du locataire et l'ID de l'utilisateur dans chaque relevé de journal.
  • Manipulation d'erreurs :[ Ne jamais divulguer les erreurs de croisement locataire. Attrapez toutes les exceptions et retournez des messages d'erreurs génériques aux utilisateurs tout en enregistrant tous les détails en interne.

Services de base de données: stockage des données sur les locataires

Votre choix de base de données a une incidence directe sur l'isolement, les performances et les coûts.

  • Amazon DynamoDB: A NoSQL key-value et base de données de documents. Pour les multi-ténanies, utilisez une clé primaire composite de et une clé de tri (p. ex. ou . DynamoDB prend en charge les écrits conditionnels, les transactions et les politiques de MAI à grain fin qui limitent l'accès par la clé de partition, idéale pour l'isolement des locataires.
  • Amazon Aurora Serverless: Une base de données relationnelle qui s'équilibre automatiquement. Convient aux locataires qui nécessitent des jointures complexes, des procédures stockées ou des transactions ACID. Avec Aurora Serverless v2, vous pouvez utiliser un seul cluster avec plusieurs bases de données (un par locataire) ou un schéma par locataire. Utilisez l'API de données pour invoquer des requêtes SQL sur HTTPS, ce qui simplifie la gestion de la connexion dans les fonctions sans serveur.

Quelle que soit la base de données que vous choisissez, implémentez le throttling au niveau du locataire pour empêcher un locataire bruyant de partager des ressources écrasantes. Utilisez le de DynamoDB par table ou appliquez Amazon RDS Proxy pour la mise en commun de connexions dans les bases relationnelles.

Services d'authentification : Gestion de l'identité et de l'accès

Amazon Cognito User Pools facilite la gestion de l'enregistrement, de la connexion et de la MFA des utilisateurs pour les applications multi-tenues. Points de configuration clés:

  • Personnalisés : Ajoute un attribut à chaque utilisateur. Lorsqu'un utilisateur s'inscrivit, assignez-le à un locataire via un déclencheur Lambda (préinscription ou confirmation Post).
  • Groupes: Utilisez les groupes Cognito pour représenter des dizaines de rôles (administrateur, membre, spectateur) au sein d'un locataire. Affectez les utilisateurs aux groupes par locataire.
  • Pools d'identité: Pour un accès fédéré (p. ex. Google, Facebook) ou pour accorder des identifiants AWS temporaires pour accéder à d'autres ressources, utilisez Cognito Identity Pools.

Pour l'entreprise SaaS, considérez le support multi-locataires d'Auth0 intégré dans l'entreprise.

Les modèles de file d'attente et d'événementiel

Les plateformes SaaS sans serveur ont souvent besoin d'un traitement asynchrone, par exemple, en envoyant des courriels, en traitant des rapports ou en gérant la fourniture de locataires. Utilisez Amazon SQS (Simple Queue Service) ou SNS pour découpler des composants. Chaque message doit inclure l'ID du locataire pour maintenir le contexte.

Défis et stratégies d ' atténuation

Les architectures multi-locataires sans serveur ne sont pas sans pièges. S'y attaquer de manière proactive est essentiel pour la préparation à la production.

Latence de démarrage à froid

Lorsqu'une fonction Lambda n'a pas été invoquée récemment, la prochaine invocation peut connaître un retard (le démarrage à froid). Cela peut être problématique pour les API orientées vers le locataire qui nécessitent une faible latence.

  • Utiliser la comptabilisation prévue pour les fonctions essentielles.
  • Optimisez l'exécution (Python/Node.js démarre plus rapidement que Java/C#).
  • Garder les fonctions petites et réduire la charge de dépendance.
  • Combiner plusieurs gestionnaires en une seule fonction pour augmenter la réutilisation.

Verrouillage du fournisseur

En utilisant des services gérés comme DynamoDB, Cognito et Lambda, vous êtes lié à un fournisseur de cloud spécifique. Pour réduire le risque de verrouillage :

  • APIs spécifiques au cloud abstrait derrière les interfaces ou les couches de façade dans votre code.
  • Utilisez des standards ouverts comme OpenAPI pour les définitions d'API et OpenID Connect pour l'authentification.
  • Concevez votre logique de domaine pour être indépendante de l'infrastructure. Envisagez d'utiliser le modèle d'événement avec des formats de messages communs (CloudEvents).

Débogue et observabilité

Les fonctions sans serveur sont éphémères, rendant inefficaces les outils de débogage traditionnels.

  • Traçage distribué avec AWS X-Ray ou OpenTelemetry.
  • Enregistrement centralisé avec des mesures personnalisées pour les taux d'erreur au niveau du locataire, latence et les comptes de demandes.
  • Alertes sur les seuils de niveau locataire (p. ex., un locataire qui dépasse 10x utilisation normale).

Prévention des irritations et des abus

Un locataire peut potentiellement consommer toutes les ressources si le throttling n'est pas en place. Implémenter le taux de location limite à la couche API Gateway en utilisant des plans d'utilisation. Pour l'accès à la base de données, appliquer les limites de capacité spécifiques au locataire en utilisant des index secondaires mondiaux DynamoDB avec les clés de partition du locataire et les limites de capacité de lecture/écriture.

Meilleures pratiques pour la production-Grade Serveur sans SaaS

  • Utilisez Infrastructure comme code (IaC):[ Définissez toutes les ressources sans serveur (Lambda, API Gateway, DynamoDB tables) en utilisant AWS CDK, Terraform, ou sans serveur Framework. Cela assure la répétabilité et le contrôle de version pour votre environnement multi-tenu.
  • Automatisation de l'utilisation de la location de l'installation: Fournir des ressources aux nouveaux locataires utilisant une fonction étape ou un pipeline axé sur l'événement. Par exemple, lors de l'inscription du locataire, déclencher une Lambda qui crée le schéma de base de données du locataire, remplir les données par défaut et envoyer un courriel de bienvenue.
  • Séparer la configuration spécifique du locataire:[ Stocker les métadonnées du locataire (nom, type de plan, drapeaux de fonctionnalités) dans un registre de locataires — une table DynamoDB simple indexée par l'ID du locataire. Les fonctions peuvent récupérer cette configuration à l'heure de l'invocation pour personnaliser le comportement sans modifier le code.
  • Plan pour la migration: Commencez par le modèle d'isolement le plus simple (table partagée avec l'ID du locataire) et refactorez l'isolement plus tard. Utilisez des stratégies de migration de base de données comme les changements de schéma zéro-défaut (avec des outils comme Flyway) pour éviter de briser les services du locataire.
  • Coûts de suivi par locataire:[ Utilisez AWS Cost Explorer avec des étiquettes personnalisées (p. ex. ) pour attribuer des coûts de calcul, de stockage et de réseau à chaque locataire. Cela vous permet de construire une facturation basée sur l'utilisation et d'identifier des comptes non rentables.
  • Set Up Disaster Recovery: Les services sans serveur offrent généralement une grande disponibilité dans une région. Pour les charges de travail multi-tenues critiques, envisager la réplication trans-régionale pour DynamoDB (Global Tables) et multi-Région API Gateway paramètres pour maintenir la disponibilité en cas de pannes régionales.

Conclusion

Construire une plateforme SaaS multi-locataires sur une infrastructure sans serveur est un choix pragmatique qui offre une échelle automatique, un bon rapport coût-efficacité et une réduction du fardeau opérationnel. En concevant avec soin votre stratégie d'isolement des données, en mettant en œuvre l'authentification locataire-conservateur, et en exploitant les services gérés comme API Gateway, Lambda, et bases de données sans serveur, vous pouvez créer une plateforme prête à la production qui dessert des centaines ou des milliers de locataires à partir d'une base de code unique.

Comme pour toute architecture, la clé est de faire des compromis délibérés. Commencez par un simple isolement des locataires, investissez dans l'observabilité et IaC dès le premier jour, et ajoutez progressivement des fonctionnalités comme le throttling par locataires, la facturation basée sur l'utilisation et les déploiements multi-régions. Avec la bonne base, sans serveur vous permet de vous concentrer sur la livraison de valeur à vos locataires pendant que le cloud gère l'infrastructure.

Pour plus de renseignements, explorez les ressources AWS SaaS Factory et AWS Well-Architected SaaS Lens[ pour un guidage profond sur les systèmes multi-locataires évolutives de construction.