For the most recent update on ongoing service disruptions affecting the AWS Middle East (UAE) Region (ME-CENTRAL-1), refer to the AWS Health Dashboard. For information on AWS Service migration, see How do I migrate my services to another region?
Architecture Multi tenant en silo Model
Bonjour,
Voilà ma problématique, j'aimerais mettre en place une architecture multi tenant en silo model mais avec quelque spécifications.
J'ai des utilisateurs avec des rôles (Gestionnaire et Lecteur). Les gestionnaires sont créer à partir de l'admin en django, les lecteurs sont créer via les gestionnaires.
L'architecture que j'essaye de mettre en place c'est que chaque gestionnaire à le même front, mais pas la même instance back, j'aimerais qu'ils aient chacun leur propre instances avec leur propre caractéristiques (4GO Ram, 2CPU 30go de stockage). Les lecteurs créer à partir de ce gestionnaire seront aussi dans la même instance. Dernière information, la base de donnée est commune à toute les instances (RDS, Postgresql).
Pour l'instant ce que j'ai réussi à mettre en place :
- Le front cloud front + S3
- instance ECS avec un service par défaut qui contient mon application sous docker avec ECR
Ce qui me reste à faire ou je n'ai pas compris comment je pouvais les mettre en place
- API Gateway avec la lambda fonction pour la connexion et redirection vers le service qui lui ait dédié
- Connexion de chaque instance à la base de donnée RDS
- Au moment de la création d'un utilisateur Gestionnaire lui créer automatiquement une instance dans ECS avec ces propres statistiques
- Mise en place de la lambda fonction si il y a pas de mouvement depuis 1h sur l'instance il l'a met en pause
Si vous avez des tutos, documentations autre je suis preneur
- Le plus récent
- Le plus de votes
- La plupart des commentaires
Bonjour,
Votre architecture multi-tenant en modèle silo est une approche intéressante pour isoler les ressources par gestionnaire tout en maintenant une base de données commune.
Dans le modèle silo, chaque tenant (dans votre cas, chaque gestionnaire) dispose de ressources dédiées et isolées. Cette approche est souvent utilisée pour répondre à des exigences de conformité, de réglementation ou pour éviter les problèmes de "voisins bruyants" où l'activité d'un tenant pourrait affecter les performances des autres.
Pour votre architecture spécifique, voici comment vous pourriez procéder:
- Création automatique d'instances pour les gestionnaires:
- Vous pourriez utiliser AWS Lambda couplé à Amazon EventBridge pour déclencher la création d'un nouveau service ECS lorsqu'un gestionnaire est créé dans votre application Django.
- Cette Lambda pourrait utiliser l'AWS SDK pour créer une nouvelle définition de tâche ECS avec les spécifications requises (4Go RAM, 2CPU, 30Go stockage).
- API Gateway et authentification:
- Configurez API Gateway pour router les requêtes vers les différentes instances ECS en fonction de l'identité du gestionnaire.
- Créez une Lambda d'authentification qui vérifie les identifiants, détermine le rôle de l'utilisateur et le service ECS correspondant.
- Cette Lambda peut générer des jetons JWT contenant l'information du service ECS cible.
- Connexion à la base de données RDS:
- Chaque instance ECS peut se connecter à la même base de données RDS.
- Utilisez des schémas différents ou un identifiant de tenant dans vos tables pour séparer les données.
- Configurez des IAM roles pour chaque service ECS avec les permissions appropriées pour accéder à RDS.
- Mise en veille automatique:
- Créez une Lambda qui s'exécute périodiquement pour vérifier l'activité de chaque service ECS.
- Utilisez CloudWatch Metrics pour surveiller l'activité (CPU, réseau, etc.).
- Si aucune activité n'est détectée pendant 1 heure, la Lambda peut réduire le nombre de tâches à zéro ou utiliser la mise à l'échelle automatique d'ECS.
Pour la mise en œuvre, vous devrez:
- Créer des IAM roles pour chaque service avec les permissions appropriées.
- Automatiser la création et la configuration des services ECS via CloudFormation ou l'AWS CDK.
- Mettre en place un mécanisme de routage dans API Gateway basé sur l'identité de l'utilisateur.
Cette approche vous permettra d'avoir une isolation complète des ressources de calcul pour chaque gestionnaire tout en maintenant une base de données commune, ce qui correspond bien au modèle silo avec une variation sur la partie stockage des données.
Sources
Silo-model multi-tenancy - AWS Prescriptive Guidance
Multitenancy on Amazon RDS - SaaS Storage Strategies
Build multi-tenant architectures on Amazon Neptune | AWS Database Blog
Multitenancy on DynamoDB - SaaS Storage Strategies
Contenus pertinents
- demandé il y a 6 mois
- demandé il y a 3 ans
- demandé il y a 3 ans
- AWS OFFICIELA mis à jour il y a 2 ans
