Azure offre de nombreuses options pour organiser vos ressources. Dans une solution multilocataire, il y a des compromis spécifiques à prendre en compte lorsque vous planifiez votre stratégie d’organisation des ressources. Dans cet article, nous allons examiner deux éléments fondamentaux de l’organisation de vos ressources Azure : l’isolation des locataires et le Scale-out sur plusieurs ressources. Nous décrivons également comment travailler avec les limites et quotas de ressources Azure et comment mettre à l’échelle votre solution au-delà de ces limites.
Principaux éléments et exigences à prendre en compte
Exigences en matière d’isolation des locataires
Lorsque vous déployez une solution multilocataire dans Azure, vous devez décider si vous consacrez des ressources à chaque locataire ou si vous partagez des ressources entre plusieurs locataires. Tout au long des sections de cette série consacrées aux approches multilocataires et aux aides spécifiques aux services, nous décrivons les options et les compromis pour de nombreuses catégories de ressources. En général, il existe un éventail d’options pour l’isolation des locataires. Pour plus d’informations sur la manière de choisir votre modèle d’isolation, consultez Modèles de location à prendre en compte pour une solution multilocataire.
Scale
La plupart des ressources Azure, ainsi que les groupes de ressources et les abonnements, imposent des limites qui peuvent influer sur votre capacité à mettre à l’échelle. Vous devrez peut-être envisager d’effectuer un Scale-out ou une compression de compartiment pour correspondre au nombre planifié de locataires ou à la charge système prévue.
Si vous savez avec certitude que vous n’atteindrez pas un grand nombre de locataires ou une charge élevée, ne rendez pas votre plan de Scale-out plus compliqué que nécessaire. En revanche, si vous prévoyez que votre solution va se développer, réfléchissez bien à votre plan de Scale-out. Assurez-vous d’intégrer la mise à l’échelle dans votre conception en suivant l’aide fournie dans cet article.
Si vous disposez d’un processus de déploiement automatisé et que vous devez mettre à l’échelle des ressources, déterminez la manière dont vous allez déployer et affecter les locataires sur plusieurs instances de ressources. Par exemple, comment allez-vous détecter que vous approchez du nombre maximum de locataires pouvant être affectés à une ressource spécifique ? Prévoyez-vous de déployer de nouvelles ressources juste-à-temps pour le moment où vous en aurez besoin ? Ou bien allez-vous déployer un pool de ressources à l’avance afin qu’elles soient prêtes à être utilisées lorsque vous en aurez besoin ?
Conseil
Dans les premières phases de conception et de développement, vous ne choisirez peut-être pas d’implémenter un processus de Scale-out automatisé. Vous devez néanmoins envisager et documenter clairement les processus requis pour mettre à l’échelle au fur et à mesure de votre croissance.
Il est également important de ne pas faire de suppositions dans votre code et votre configuration, ce qui peut limiter votre capacité à mettre à l’échelle. Par exemple, vous pourriez avoir besoin de mettre à l’échelle plusieurs comptes de stockage. Assurez-vous que votre couche Application ne part pas du principe qu’elle ne se connecte qu’à un seul compte de stockage pour tous les locataires.
Approches et modèles à prendre en compte
Isolation des locataires
Les ressources Azure sont déployées et gérées selon une hiérarchie. La plupart des ressources sont déployées dans des groupes de ressources, qui sont contenus dans des abonnements. Les groupes d’administration regroupent logiquement les abonnements. Toutes ces couches hiérarchiques sont associées à un client Microsoft Entra.
Lorsque vous déterminez comment déployer des ressources pour chaque locataire, vous pouvez isoler à différents niveaux de la hiérarchie. Chaque option est valable pour certains types de solutions multilocataires et présente des avantages et des inconvénients. Il est également courant de combiner les approches, en utilisant différents modèles d’isolation pour différents composants d’une solution.
Isolation au sein d’une ressource partagée
Vous pouvez choisir de partager une ressource Azure entre plusieurs locataires et d’exécuter toutes leurs charges de travail sur une seule instance. Consultez les aides spécifiques aux services Azure que vous utilisez pour comprendre les considérations ou options particulières qui peuvent être importantes.
Lorsque vous exécutez des instances uniques d’une ressource, vous devez tenir compte des limites de service, des limites d’abonnement ou des quotas qui peuvent être atteints lorsque vous effectuez une mise à l’échelle. Par exemple, il existe un nombre maximal de nœuds pris en charge par un cluster Azure Kubernetes Service (AKS) et une limite supérieure au nombre de transactions par seconde prises en charge par un compte de stockage. Réfléchissez à la manière dont vous allez mettre à l’échelle plusieurs ressources partagées lorsque vous vous rapprochez de ces limites.
Vous devez également vous assurer que le code de votre application est pleinement conscient de l’architecture mutualisée et qu’il restreint l’accès aux données pour un locataire spécifique.
Pour illustrer l’approche des ressources partagées, supposons que Contoso crée une application SaaS multilocataire comprenant une application web, une base de données et un compte de stockage. Contoso pourrait décider de déployer des ressources partagées et utiliser ces ressources pour servir tous ses clients. Dans le diagramme suivant, un seul ensemble de ressources est partagé par tous les clients.
Séparer les ressources dans un groupe de ressources
Vous pouvez également déployer des ressources dédiées pour chaque locataire. Vous pouvez déployer une copie complète de votre solution pour un seul locataire. Ou bien, vous pouvez partager certains composants entre les locataires et déployer d’autres composants qui sont dédiés à un locataire spécifique.
Nous vous recommandons d’utiliser des groupes de ressources pour gérer les ressources avec le même cycle de vie. Dans certains systèmes mutualisés, il est judicieux de déployer des ressources pour plusieurs locataires dans un seul groupe de ressources ou un ensemble de groupes de ressources.
Il est important que vous considériez la manière dont vous déployez et gérez ces ressources, notamment si le déploiement des ressources spécifiques aux locataires est initié par votre pipeline de déploiement ou votre application. Vous devez également déterminer la manière dont vous allez identifier clairement que des ressources spécifiques sont liées à des locataires spécifiques. Envisagez d’utiliser une stratégie claire de convention d’affectation de noms, des étiquettes de ressources ou une base de données de catalogue de locataires.
Il est recommandé d’utiliser des groupes de ressources distincts pour les ressources que vous partagez entre plusieurs locataires et celles que vous déployez pour des locataires individuels. Toutefois, pour certaines ressources, Azure limite le nombre de ressources d’un même type qui peuvent être déployées dans un groupe de ressources. Cette limite signifie que vous devrez peut-être effectuer une mise à l’échelle sur plusieurs groupes de ressources au fur et à mesure de votre croissance.
Supposons que Contoso ait trois clients : Adventure Works, Fabrikam et Tailwind. La société peut choisir de partager l’application web et le compte de stockage entre les trois clients, puis de déployer des bases de données individuelles pour chaque locataire. Dans le diagramme suivant, chaque client se voit attribuer un groupe de ressources qui contient des ressources partagées et un autre qui contient une base de données.
Séparer les groupes de ressources dans un abonnement
Lorsque vous déployez un ensemble de ressources pour chaque locataire, envisagez d’utiliser des groupes de ressources dédiés spécifiques aux locataires. Par exemple, lorsque vous suivez le modèle Empreintes de déploiement, chaque empreinte doit être déployée dans son propre groupe de ressources. Vous pouvez envisager de déployer plusieurs groupes de ressources spécifiques aux locataires dans un abonnement Azure partagé, ce qui vous permet de configurer facilement des stratégies et des règles de contrôle d’accès.
Vous pouvez choisir de créer un ensemble de groupes de ressources pour chaque locataire, ainsi que des groupes de ressources partagées pour toutes les ressources partagées.
Lorsque vous déployez des groupes de ressources spécifiques aux locataires dans des abonnements partagés, vous devez connaître le nombre maximal de groupes de ressources dans chaque abonnement et les autres limites au niveau de l’abonnement qui s’appliquent aux ressources que vous déployez. Lorsque vous vous rapprochez de ces limites, vous pouvez être amené à effectuer une mise à l’échelle sur plusieurs abonnements.
Dans notre exemple, Contoso pourrait choisir de déployer une empreinte pour chacun de ses clients et de placer les empreintes dans des groupes de ressources dédiés au sein d’un seul abonnement. Dans le diagramme suivant, un abonnement, qui contient trois groupes de ressources, est créé pour chaque client.
Séparer les abonnements
En déployant des abonnements spécifiques aux locataires, vous pouvez isoler complètement les ressources spécifiques aux locataires. En outre, comme la plupart des quotas et des limites s’appliquent au sein d’un abonnement, l’utilisation d’un abonnement distinct par client garantit que chaque locataire utilise pleinement les quotas applicables. Pour certains types de comptes de facturation Azure, vous pouvez créer des abonnements par programmation. Vous pouvez également utiliser les réservations Azure et leplan d’économies Azure pour le calcul sur plusieurs abonnements.
Notez le nombre d’abonnements que vous pouvez créer. Le nombre maximal d’abonnements peut varier en fonction de votre relation commerciale avec Microsoft ou un partenaire Microsoft, par exemple, si vous avez un Contrat Entreprise.
Toutefois, il peut être plus difficile une augmentation des quotas lorsque vous travaillez sur un grand nombre d’abonnements. L’API Quota fournit une interface de programmation pour certains types de ressources. Toutefois, pour de nombreux types de ressources, les augmentations de quotas doivent être demandées en initiant un cas de support. Il peut également être difficile de travailler avec des contrats de support Azure et des cas de support lorsque vous travaillez avec de nombreux abonnements.
Envisagez de regrouper vos abonnements spécifiques aux locataires dans une hiérarchie de groupes d’administration, afin de faciliter la gestion des règles et stratégies de contrôle d’accès.
Par exemple, supposons que Contoso ait décidé de créer des abonnements Azure distincts pour chacun de ses trois clients, comme indiqué dans le diagramme suivant. Chaque abonnement contient un groupe de ressources, avec l’ensemble complet de ressources pour ce client.
Chaque abonnement contient un groupe de ressources, avec l’ensemble complet de ressources pour ce client.
La société utilise un groupe d’administration pour simplifier la gestion de ses abonnements. En incluant Production dans le nom du groupe d’administration, elle peut clairement distinguer les locataires de production des locataires hors production ou de test. Les locataires hors production se verraient appliquer des règles et des stratégies de contrôle d’accès Azure différentes.
Tous leurs abonnements sont associés à un seul locataire Microsoft Entra. L’utilisation d’un même locataire Microsoft Entra signifie que les identités de l’équipe Contoso, y compris les utilisateurs et les principaux de service, peuvent être utilisées dans l’ensemble de son patrimoine Azure.
Séparer les abonnements dans des locataires Microsoft Entra distincts
Il est également possible de créer manuellement des locataires Microsoft Entra individuels pour chacun de vos locataires ou de déployer vos ressources dans des abonnements au sein des locataires Microsoft Entra de vos clients. Toutefois, l’utilisation de plusieurs locataires Microsoft Entra complique l’authentification, la gestion des attributions de rôle, l’application des stratégies globales et de nombreuses autres opérations de gestion.
Avertissement
Nous déconseillons la création de plusieurs locataires Microsoft Entra pour la plupart des solutions multilocataires. Le fait de travailler sur plusieurs locataires Microsoft Entra introduit une complexité supplémentaire et réduit votre capacité à mettre à l’échelle et à gérer vos ressources. En règle générale, cette approche est utilisée uniquement par les fournisseurs de services gérés (MSP) qui exploitent des environnements Azure pour le compte de leurs clients.
Un seul locataire Microsoft Entra peut être utilisé par plusieurs abonnements et ressources Azure distincts. Avant de déployer plusieurs locataires Microsoft Entra, déterminez s’il existe d’autres approches qui vous permettraient d’atteindre vos objectifs.
Dans les cas où vous devez gérer des ressources Azure dans des abonnements liés à plusieurs locataires Microsoft Entra, envisagez d’utiliser Azure Lighthouse pour vous aider à gérer vos ressources entre vos locataires Microsoft Entra.
Par exemple, Contoso pourrait créer des locataires Microsoft Entra distincts et des abonnements Azure distincts pour chacun de ses clients, comme indiqué dans le diagramme suivant.
Un locataire Microsoft Entra est configuré pour chacun des locataires de Contoso. Il contient un abonnement et les ressources nécessaires. Azure Lighthouse est connecté à chaque locataire Microsoft Entra.
Compression de compartiment
Quel que soit votre modèle d’isolation des ressources, il est important de savoir quand et comment votre solution sera mise à l’échelle sur plusieurs ressources. Vous pouvez être amené à mettre à l’échelle vos ressources à mesure que la charge de votre système augmente ou que le nombre de locataires s’accroît. Envisagez la compression de compartiment pour déployer un nombre optimal de ressources selon vos besoins.
Conseil
Dans de nombreuses solutions, il est plus facile de mettre à l’échelle la totalité de votre ensemble de ressources plutôt que de mettre à l’échelle les ressources individuellement. Envisagez de suivre le modèle Empreintes de déploiement.
Limites des ressources
Les ressources Azure ont des limites et des quotas qui doivent être pris en compte dans la planification de votre solution. Par exemple, les ressources peuvent prendre en charge un nombre maximal de demandes simultanées ou des paramètres de configuration spécifiques au locataire.
La façon dont vous configurez et utilisez chaque ressource détermine également la scalabilité de cette ressource. Par exemple, avec une certaine quantité de ressources de calcul, votre application peut répondre avec succès à un nombre défini de transactions par seconde. Au-delà de ce nombre, vous devrez peut-être effectuer un scale-out. Le test de performance vous aide à identifier le moment où vos ressources ne répondent plus à vos besoins.
Notes
Le principe de mise à l’échelle vers plusieurs ressources s’applique même lorsque vous utilisez des services qui prennent en charge plusieurs instances.
Par exemple, Azure App Service prend en charge le Scale-out du nombre d’instances de votre plan, mais il existe des limites à la mise à l’échelle d’un seul plan. Dans le cas d’une application multilocataire à grande échelle, vous risquez de dépasser ces limites et de devoir déployer des ressources App Service supplémentaires pour faire face à votre croissance.
Lorsque vous partagez certaines de vos ressources entre les locataires, vous devez d’abord déterminer le nombre de locataires pris en charge par la ressource lorsqu’elle est configurée en fonction de vos besoins. Ensuite, déployez autant de ressources que nécessaire pour servir votre nombre total de locataires.
Par exemple, supposons que vous déployez une passerelle applicative Azure, dans le cadre d’une solution SaaS multilocataire. Vous examinez la conception de votre application, testez les performances de la passerelle applicative en cours de chargement et passez en revue sa configuration. Ensuite, vous déterminez qu’une seule ressource de passerelle applicative peut être partagée entre 100 clients. Selon le plan de croissance de votre organisation, vous prévoyez d’intégrer 150 clients au cours de la première année. Vous devez donc planifier le déploiement de plusieurs passerelles applicatives pour répondre à la charge attendue.
Dans le schéma précédent, il existe deux passerelles applicatives. La première passerelle est dédiée aux clients 1 à 100, et la seconde est dédiée aux clients 101 à 200.
Limites des groupes de ressources et des abonnements
Que vous travailliez avec des ressources partagées ou dédiées, il est important de tenir compte des limites. Azure limite le nombre de ressources qui peuvent être déployées dans un groupe de ressources et dans un abonnement Azure. Lorsque vous approchez de ces limites, vous devez planifier la mise à l’échelle sur plusieurs groupes de ressources ou abonnements.
Par exemple, supposons que vous déployez une passerelle applicative dédiée, pour chacun de vos clients, dans un groupe de ressources partagées. Pour certaines ressources, Azure prend en charge le déploiement d’un maximum de 800 ressources du même type dans un seul groupe de ressources. Ainsi, lorsque vous atteignez cette limite, vous devez déployer toutes les nouvelles passerelles applicatives dans un autre groupe de ressources. Dans le diagramme suivant, il existe deux groupes de ressources. Chaque groupe de ressources contient 800 passerelles applicatives.
Effectuer une compression de compartiment des locataires sur les groupes de ressources et les abonnements
Vous pouvez également appliquer le concept de compression de compartiment entre les ressources, les groupes de ressources et les abonnements. Par exemple, si vous avez un petit nombre de locataires, vous pouvez déployer une seule ressource et la partager entre tous vos locataires. Le diagramme suivant illustre la compression de compartiment dans une seule ressource.
Au fur et à mesure de votre croissance, vous pouvez approcher la limite de capacité d’une ressource et effectuer un scale-out sur plusieurs ressources (R). Le diagramme suivant illustre la compression de compartiment sur plusieurs ressources.
Au fil du temps, vous pouvez atteindre la limite du nombre de ressources dans un seul groupe de ressources, et vous déployez alors plusieurs ressources (R) dans plusieurs groupes de ressources (G). Le diagramme suivant illustre la compression de compartiment sur plusieurs ressources, dans plusieurs groupes de ressources.
Et si votre activité croît encore davantage, vous pouvez effectuer un déploiement sur plusieurs abonnements (S), chacun contenant plusieurs groupes de ressources (G) avec plusieurs ressources (R). Le diagramme suivant illustre la compression de compartiment sur plusieurs ressources, dans plusieurs groupes de ressources et abonnements.
En planifiant votre stratégie de Scale-out, vous pouvez effectuer une mise à l’échelle vers un très grand nombre de locataires et maintenir un niveau de charge élevé.
Étiquettes
Les étiquettes de ressources vous permettent d’ajouter des métadonnées personnalisées à vos ressources Azure, ce qui peut être utile pour la gestion et le suivi des coûts. Pour plus d’informations, consultez Allouer les coûts à l’aide des étiquettes de ressources.
Antimodèles à éviter
- Ne pas planifier de mise à l’échelle. Assurez-vous de bien comprendre les limites des ressources que vous allez déployer ainsi que les limites qui pourraient devenir importantes à mesure que votre charge ou le nombre de locataires augmente. Planifiez la façon dont vous allez déployer des ressources supplémentaires au fur et à mesure que vous vous mettez à l’échelle, et testez ce plan.
- Ne pas planifier de compression de compartiment. Même si vous n’avez pas besoin de croître immédiatement, planifiez la mise à l’échelle de vos ressources Azure sur plusieurs ressources, groupes de ressources et abonnements au fil du temps. Évitez de faire des hypothèses dans le code de votre application, par exemple qu’il n’y a qu’une seule ressource alors que vous pourriez avoir besoin d’effectuer une mise à l’échelle vers plusieurs ressources à l’avenir.
- Mettre à l’échelle de nombreuses ressources individuelles. Si la topologie de vos ressources est complexe, il peut être difficile de mettre à l’échelle des composants individuels, un par un. Il est souvent plus simple de mettre à l’échelle votre solution en tant qu’unité, en suivant le modèle Empreintes de déploiement.
- Déployer des ressources isolées pour chaque locataire lorsque cela n’est pas nécessaire. Dans de nombreuses solutions, il est plus rentable et efficace de déployer des ressources partagées pour plusieurs locataires.
- Utilisation de locataires Microsoft Entra distincts. En général, il est déconseillé d’approvisionner plusieurs locataires Microsoft Entra. La gestion des ressources entre les locataires Microsoft Entra est complexe. Il est plus simple d’effectuer une mise à l’échelle entre les abonnements liés à un seul locataire Microsoft Entra.
- Surconcevoir l’architecture lorsque vous n’avez pas besoin de mettre à l’échelle. Dans certaines solutions, vous savez avec certitude que vous ne dépasserez jamais un certain niveau d’échelle. Dans ce cas, il n’est pas nécessaire de mettre en place une logique de mise à l’échelle complexe. Toutefois, si votre organisation prévoit de se développer, vous devrez être prêt à effectuer une mise à l’échelle, potentiellement dans des délais très courts.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- John Downs | Ingénieur client principal, FastTrack for Azure
Autres contributeurs :
- Jason Beck | Ingénieur client senior, FastTrack for Azure
- Bohdan Cherchyk | Ingénieur client senior, FastTrack for Azure
- Laura Nicolas | Ingénieur client senior, FastTrack for Azure
- Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure
- Joshua Waddell | Ingénieur client senior, FastTrack for Azure
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
Examinez les approches de gestion et d’allocation des coûts.