Modèle d’empreintes de déploiement

Le modèle Tampons de déploiement provisionne, gère et surveille un groupe de ressources pour héberger et exploiter plusieurs charges de travail ou locataires. Chaque copie individuelle est appelée tampon, ou parfois une unité de service, une unité d’échelle ou une cellule. Dans un environnement multilocataire, chaque tampon sert un nombre prédéfini de locataires. Vous déployez plusieurs systèmes pour faire évoluer la solution presque linéairement et servir un nombre croissant de clients. Cette approche peut améliorer la scalabilité de votre solution, vous permettre de déployer des instances dans plusieurs régions et de séparer vos données client.

Contexte et problème

Lorsque vous hébergez une application dans le cloud, tenez compte des performances et de la fiabilité de votre application. Si vous hébergez une seule instance de votre solution, les limitations suivantes peuvent s’appliquer :

• Limites de mise à l’échelle : Une seule instance de votre application peut atteindre des limites de mise à l’échelle naturelles. Par exemple, les services que vous utilisez peuvent limiter le nombre de connexions entrantes, de noms d’hôtes, de sockets TCP (Transmission Control Protocol) ou d’autres ressources.

• Mise à l’échelle ou coût non linéaire : Certains composants de votre solution peuvent ne pas être mis à l’échelle de manière linéaire avec le nombre de requêtes ou la quantité de données. Au lieu de cela, les performances peuvent diminuer ou les coûts peuvent augmenter brusquement après avoir atteint un seuil. Par exemple, vous pouvez constater que l’ajout d’une capacité supplémentaire à une base de données, ou un scale-up, devient prohibitifment coûteux et que le scale-out est plus rentable.

• Séparation des clients : Vous devrez peut-être isoler les données d’un client des données d’un autre client. Vous pouvez également avoir des clients qui consomment plus de ressources système que d’autres. Vous pouvez les regrouper sur différents ensembles d’infrastructure.

• Instances multilocataires et monolocataires : Certains clients volumineux peuvent avoir besoin de leurs propres instances indépendantes de votre solution. Les clients de plus petite taille peuvent partager un déploiement mutualisé.

• Exigences de déploiement complexes : Vous devrez peut-être déployer des mises à jour sur votre service de manière contrôlée et déployer sur différents sous-ensembles de votre base de clients à différents moments.

• Fréquence de mise à jour : Certains clients tolèrent des mises à jour fréquentes, tandis que les clients à risque veulent des mises à jour peu fréquentes du système qui répond à leurs demandes. Vous pouvez déployer ces clients dans des environnements isolés.

• Restrictions géographiques ou géopolitiques : Pour atteindre une faible latence ou respecter les exigences de souveraineté des données, vous pouvez déployer certains clients dans des régions spécifiques.

Ces limitations s’appliquent souvent aux entreprises de développement de logiciels qui créent des logiciels en tant que service (SaaS), qu’elles conçoivent généralement en tant que multilocataire. Les mêmes limitations peuvent également s’appliquer à d’autres scénarios.

Solution

Pour éviter ces problèmes, envisagez de regrouper des ressources en unités d’échelle et de provisionner plusieurs copies de vos timbres. Chaque unité d’échelle héberge et sert un sous-ensemble de vos locataires. Les tampons s’exécutent indépendamment les uns des autres, et vous pouvez les déployer et les mettre à jour indépendamment. Une seule région géographique peut contenir un tampon ou plusieurs tampons qui s’étendent horizontalement au sein de la région. Chaque tampon sert un sous-ensemble de vos clients.

Les tampons de déploiement peuvent s’appliquer si votre solution utilise des composants IaaS (Infrastructure as a Service) ou PaaS (Platform as a Service), ou une combinaison des deux. Les charges de travail IaaS nécessitent généralement plus d’intervention pour effectuer une mise à l’échelle. Ce modèle peut donc aider les charges de travail volumineuses IaaS à effectuer un scale-out.

Vous pouvez utiliser des tampons pour implémenter des anneaux de déploiement. Si différents clients veulent des mises à jour de service à différentes fréquences, regroupez-les sur différents tampons et déployez des mises à jour sur chaque tampon à une cadence différente.

Les balises fonctionnent indépendamment, ce qui signifie qu’elles fragmentent implicitement vos données. Un tampon unique peut également utiliser d’autres partitionnements en interne pour mettre à l’échelle et rester élastique.

Le déploiement de copies identiques des mêmes composants est complexe, de sorte que les bonnes pratiques DevOps sont essentielles. Décrivez votre infrastructure en tant que code afin que le déploiement de chaque tampon soit prévisible et reproductible.

Les tampons de déploiement sont liés aux géodes, mais s'en distinguent. Dans une architecture d’empreinte de déploiement, chaque instance indépendante de votre système sert un sous-ensemble de vos clients et utilisateurs. Dans une architecture de géode, chaque instance peut traiter les demandes de n’importe quel utilisateur, mais cette approche est généralement plus complexe à concevoir et à générer. Vous pouvez également combiner les deux modèles au sein d’une solution. L’approche de routage du trafic décrite plus loin dans cet article est un exemple de ce scénario hybride.

Problèmes et considérations

Tenez compte des points suivants lorsque vous décidez comment implémenter ce modèle :

• Processus de déploiement : Lorsque vous déployez plusieurs tampons, automatisez et répétez entièrement vos processus de déploiement. Utilisez les modules Bicep ou Terraform pour définir de manière déclarative vos configurations et assurer la cohérence des définitions.

• Opérations d’horodatage croisé : Lorsque vous déployez votre solution indépendamment sur plusieurs tampons, il peut être difficile de déterminer le nombre de clients dont vous disposez sur tous vos tampons. Vous devrez peut-être interroger chaque tampon et agréger les résultats. Vous pouvez également configurer tous les timbrages pour publier des données dans un entrepôt de données centralisé pour des rapports consolidés.

• Stratégies de scale-out : Les tampons ont une capacité finie, que vous pouvez définir à l’aide d’une métrique de proxy, par exemple le nombre de locataires que vous pouvez déployer sur le tampon. Surveillez la capacité disponible et utilisée pour chaque timbre, et déployez de manière proactive davantage de timbres pour diriger les nouveaux clients vers ceux-ci.

• Nombre minimal d’empreintes : Lorsque vous utilisez le modèle Tampons de déploiement, déployez au moins deux tampons de votre solution. Si vous déployez un seul suffixe, vous pouvez facilement intégrer des hypothèses rigides dans votre code ou configuration qui ne s’appliquent pas lorsque vous procédez à une extension horizontale.

• Coût : Le modèle de groupes de déploiement déploie plusieurs copies de vos composants d’infrastructure, ce qui augmente considérablement le coût d’exploitation de votre solution.

• Déplacement d’un tampon à l’autre : Chaque tampon s’exécute indépendamment, de sorte que le déplacement des locataires entre les tampons peut être difficile. Votre application a besoin d’une logique personnalisée pour transmettre les informations d’un client à un autre tampon, puis supprimer les informations du locataire de l’empreinte d’origine. Ce processus peut nécessiter un plan arrière pour communiquer entre les tampons, ce qui augmente davantage la complexité de votre solution.

• Routage du trafic : Comme décrit précédemment dans cet article, le routage du trafic vers le tampon approprié pour une demande donnée peut nécessiter un composant supplémentaire qui résout les locataires en tampons. Ce composant peut également avoir besoin d’être hautement disponible.

• Observabilité à travers les tampons : À mesure que le nombre de tampons augmente, il devient plus difficile de comprendre la santé globale et de détecter rapidement les incidents. Utilisez Azure Monitor pour collecter et mettre en corrélation les métriques, les journaux, les traces et les alertes sur tous les tampons. Utilisez ces données pour identifier les tampons défectueux et diagnostiquer les problèmes.

• Impact sur les défaillances régionales : Les unités s'exécutent indépendamment, mais elles ne sont pas intrinsèquement redondantes entre les régions. Si une région qui héberge un ou plusieurs tampons devient indisponible, les locataires sur ces tampons perdent l’accès jusqu’à ce que la région récupère ou que vous migrez les locataires vers des empreintes dans une autre région. Pour planifier ce scénario, documentez vos procédures de récupération, définissez les attentes des locataires et déterminez si les locataires critiques ont besoin d’un positionnement de tampon géoredondant.

• Composants partagés : Vous pourriez avoir des composants à partager entre différentes instances. Par exemple, si vous avez une application monopage partagée pour tous les locataires, déployez-la dans une région et utilisez la mise en cache périphérique de Azure Front Door pour la répliquer à l'échelle mondiale.

• Dérive de gouvernance et de configuration : À mesure que le nombre d’empreintes augmente, il devient plus difficile de conserver les stratégies de sécurité, les attributions de contrôle d’accès en fonction du rôle (RBAC), les contrôles réseau, les paramètres d’observabilité et les configurations de service cohérentes. Utilisez Azure Policy pour considérer la gouvernance comme du code et validez en permanence chaque configuration pour les dérives afin d’éviter les incohérences de fonctionnement et les écarts de conformité.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

• Votre solution a des limites naturelles sur l’extensibilité. Par exemple, si certains composants ne peuvent pas ou ne doivent pas être mis à l’échelle au-delà d’un certain nombre de clients ou de demandes, utilisez des tampons pour effectuer un scale-out.

• Vous devez séparer certains locataires des autres. Si des problèmes de sécurité vous empêchent de déployer certains clients dans un tampon multilocataire, déployez-les sur leur propre tampon isolé.

• Vous devez héberger certains locataires sur différentes versions de votre solution en même temps.

• Vous créez des applications multirégions qui doivent diriger les données et le trafic de chaque locataire vers une région spécifique.

• Vous souhaitez obtenir une résilience pendant les pannes. Les timbres fonctionnent de manière indépendante. Par conséquent, si une panne affecte un seul timbre, les locataires sur d’autres timbres ne sont pas touchés. Ce confinement contient le périmètre d'impact d’un incident ou d’une panne.

Ce modèle peut ne pas convenir lorsque :

• Votre solution est simple et n’a pas besoin d’être mise à l’échelle à un niveau élevé.

• Vous pouvez effectuer un scale-out ou un scale-up de votre système au sein d’une seule instance, par exemple en augmentant la taille de la couche Application ou en augmentant la capacité réservée pour les bases de données et le niveau de stockage.

• Vous devez répliquer des données sur toutes les instances déployées. Considérez le modèle Geode pour ce scénario.

• Vous devez uniquement mettre à l’échelle certains composants et non d’autres. Par exemple, déterminez si vous pouvez mettre à l’échelle votre solution en partitionnant le magasin de données au lieu de déployer une nouvelle copie de tous les composants de la solution.

• Votre solution se compose uniquement de contenu statique, tel qu’une application JavaScript frontale. Fournissez ce contenu par un réseau de distribution de contenu.

Conception de la charge de travail

Évaluez comment utiliser le modèle Deployment Stamps dans la conception d'une charge de travail pour atteindre les objectifs et principes des piliers du Azure Well-Architected Framework. Le tableau suivant fournit des conseils sur la façon dont ce modèle prend en charge les objectifs de chaque pilier.

Si ce modèle introduit des compromis au sein d’un pilier, considérez-les contre les objectifs des autres piliers.

Exemple

L’exemple d’architecture suivant utilise Azure Front Door, Gestion des API Azure et Azure Cosmos DB pour acheminer le trafic globalement vers une série d’empreintes spécifiques à la région.

Supposons qu’un utilisateur réside à New York. Instance 3, dans la région Est des États-Unis, stocke ses données.

Si l’utilisateur se rend en Californie et accède au système, le système achemine sa connexion via la région USA Ouest 2, car cette région est la plus proche de celle-ci lorsqu’elle effectue la demande. Toutefois, l'étiquette 3 doit finalement servir la demande, car il stocke leurs données. Le système de routage du trafic achemine la requête vers le tampon correct.

Déploiement

Décrivez votre infrastructure en tant que code, en utilisant Bicep ou Terraform. Cette approche garantit que le déploiement de chaque tampon est prévisible et reproductible. Elle permet également de réduire les éventuelles erreurs humaines, telles que les incompatibilités accidentelles de la configuration entre les empreintes.

Vous pouvez déployer automatiquement des mises à jour sur tous les tampons en parallèle. Les technologies telles que Bicep peuvent coordonner le déploiement de votre infrastructure et de vos applications. Vous pouvez également décider de déployer progressivement des mises à jour de certains timbres, puis de les étendre progressivement à d’autres timbres. Envisagez d’utiliser un outil de gestion des mises en production comme Azure Pipelines ou GitHub Actions pour orchestrer les déploiements sur chaque instance.

Examinez attentivement la topologie des abonnements et des groupes de ressources Azure correspondant à vos déploiements :

• En règle générale, un abonnement contient toutes les ressources d’une seule solution. Envisagez donc d’utiliser un seul abonnement pour tous les tampons. Toutefois, les services Azure imposent des quotas à l’échelle de l’abonnement. Si vous utilisez ce modèle pour permettre un haut degré de scale-out, vous devrez peut-être déployer des tampons sur différents abonnements.

• Les groupes de ressources contiennent généralement des composants qui partagent le même cycle de vie. Si vous envisagez de déployer des mises à jour sur tous les tampons en même temps, vous pouvez utiliser un seul groupe de ressources qui contient tous les composants pour tous les tampons. Utilisez des conventions de nommage des ressources et des balises pour identifier les composants qui appartiennent à chaque tampon. Sinon, si vous envisagez de déployer des mises à jour sur chaque tampon indépendamment, vous pouvez déployer chaque tampon dans son propre groupe de ressources.

Planification de la capacité

Utilisez les tests de charge et de performances pour déterminer la charge approximative pouvant être prise en charge par une empreinte. Les métriques de chargement peuvent être basées sur le nombre de clients ou de locataires qu’un seul tampon peut prendre en charge, ou sur les métriques émises par les services dans l’empreinte. Instrumentez chaque tampon pour pouvoir mesurer quand il approche de sa capacité et assurez-vous que vous pouvez déployer rapidement de nouveaux tampons pour répondre à la demande.

Routage du trafic

Le modèle Tampons de déploiement fonctionne bien lorsque vous adressez chaque tampon indépendamment. Par exemple, si Contoso déploie la même application API sur plusieurs tampons, Contoso peut utiliser dns (Domain Name System) pour acheminer le trafic vers le tampon approprié :

• unit1.aus.myapi.contoso.com achemine le trafic vers l'identifiant unit1 dans une région australienne.
• unit2.aus.myapi.contoso.com achemine le trafic vers l'identifiant unit2 dans une région australienne.
• unit1.eu.myapi.contoso.com achemine le trafic vers le module unit1 dans une région européenne.

Dans Azure, vous pouvez héberger ces enregistrements dans Azure DNS et utiliser une convention de sous-domaine cohérente pour chaque région et empreinte. Cette approche maintient le routage et les opérations prévisibles.

Les clients sont responsables de la connexion au tampon approprié.

Si votre solution nécessite un point d'entrée unique pour tout le trafic, vous pouvez utiliser un service de routage du trafic pour résoudre l'identificateur d'une requête, d'un client ou d'un locataire donné. Le service de routage du trafic dirige le client vers l’URL appropriée pour le tampon (par exemple, en retournant un code d’état de réponse HTTP 302), ou il agit en tant que proxy inverse et transfère le trafic vers le tampon approprié sans que le client ne sache.

Concevoir un service de routage du trafic peut s’avérer complexe, notamment lorsqu’une solution s’exécute dans plusieurs régions. Envisagez de déployer le service de routage du trafic dans plusieurs régions, y compris potentiellement chaque région qui héberge des marques, et synchronisez le stockage de données qui associe les locataires aux marques. Le composant de routage du trafic peut lui-même être une instance du modèle Geode.

Par exemple, vous pouvez déployer gestion des API pour agir en tant que service de routage du trafic. Gestion des API détermine le tampon approprié pour une requête en recherchant des données dans une collection Azure Cosmos DB qui stocke le mappage entre les locataires et les tampons. Gestion des API définit ensuite dynamiquement l’URL de back-end sur le service d’API du tampon approprié.

Pour géo-distribuer les requêtes et fournir une géoredondance pour le service de routage du trafic, deploy API Management sur plusieurs régions et utiliser Azure Front Door pour diriger le trafic vers la passerelle gestion des API la plus proche. Dans cette topologie, Azure Front Door utilise des groupes d'origines, des sondes de santé et une méthode de routage appropriée pour acheminer les requêtes loin des passerelles régionales de gestion des API défaillantes. Gestion des API achemine ensuite vers l'instance appropriée à l’aide du mappage de locataire-à-instance et de sa configuration back-end (ou pools de back-end), y compris les règles de basculement entre les points de terminaison des instances si nécessaire. Si votre application n'est pas exposée via HTTP ou HTTPS, vous pouvez utiliser un interrégion Azure équilibreur de charge pour distribuer des appels entrants aux équilibreurs de charge régionaux Azure. Utilisez la fonctionnalité de distribution globale d'Azure Cosmos DB pour conserver les informations de mappage mises à jour dans chaque région.

Si votre solution inclut un service de gestion du trafic, déterminez s'il agit en tant que passerelle et peut effectuer un déchargement de passerelle pour les autres services, tels que la validation de jeton, la limitation et l'autorisation.

Étapes suivantes

• Porte d’entrée azur
• Intégrer Bicep à Azure Pipelines
• Intégrer des modèles ARM JSON avec Azure Pipelines

Contributors

Microsoft maintient cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

• John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques

Autres contributeurs :

• Federico Arambarri | Développeur de logiciels senior, Clarius Consulting
• Daniel Larsen | Ingénieur client principal, FastTrack pour Azure
• Angel Lopez | Ingénieur logiciel senior, modèles et pratiques Azure
• Paolo Salvatori | Ingénieur client principal, FastTrack pour Azure
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack pour Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Ressources associées

• Vous pouvez utiliser le partitionnement comme une autre approche plus simple pour effectuer un scale-out de votre niveau de données. Les stamps partitionnent implicitement leurs données, mais le partitionnement ne nécessite pas un stamp de déploiement. Pour plus d’informations, consultez le modèle de partitionnement.
• Si votre solution déploie un service de routage du trafic, vous pouvez combiner les modèles de routage de passerelle et de déchargement de passerelle pour tirer le meilleur profit de ce composant.