Cet article décrit comment déployer des applications web stratégiques avec Azure App Service. L’architecture utilise le modèle d’application web fiable comme point de départ. Utilisez cette architecture si vous disposez d’une charge de travail héritée et que vous souhaitez adopter des services PaaS (platform as a service).
Le modèle d’application web fiable pour .NET fournit des conseils pour mettre à jour ou replateformer les applications web que vous déplacez vers le cloud, réduire les modifications de code requises et cibler un objectif de niveau de service (SLO) de 99,9 %. Les charges de travail stratégiques imposent des exigences de fiabilité et de disponibilité élevées. Pour atteindre un SLO de 99,95 %, 99,99 % ou plus, vous devez appliquer des modèles de conception supplémentaires stratégiques et faire preuve de rigueur opérationnelle. Cet article décrit les domaines techniques clés, et comment implémenter et introduire des pratiques de conception stratégiques.
Remarque
Les conseils de cet article sont basés sur la méthodologie de conception et les meilleures pratiques de la série sur les charges de travail stratégiques Well-Architected Framework.
Les sections suivantes décrivent comment :
- examiner la charge de travail existante pour en comprendre les composants, les flux utilisateur/système, ainsi que les exigences en matière de disponibilité et de scalabilité.
- Développez et implémentez une architecture d’unité d’échelle pour optimiser la scalabilité de bout en bout avec la compartimentation et pour normaliser le processus d’ajout et de suppression de capacités.
- Implémentez des unités d’échelle éphémères sans état ou des empreintes de déploiement pour assurer la scalabilité et des déploiements sans temps d’arrêt.
- Déterminez si vous pouvez fractionner la charge de travail en composants pour préparer la scalabilité. Vous devez utiliser des composants individuels pour la scalabilité et le découplage des flux.
- Préparez la distribution globale en déployant une charge de travail dans plusieurs régions Azure afin d’améliorer la proximité du client et préparer les interruptions régionales potentielles.
- Découplez les composants et implémentez une architecture pilotée par les événements.
Architecture
Le diagramme suivant applique les considérations précédentes au modèle d’application web fiable.
Téléchargez le fichier Visio de cette architecture.
La zone rouge représente une unité d’échelle avec des services qui sont mis à l’échelle conjointement. Pour les mettre à l’échelle conjointement et efficacement, optimisez la taille, la référence SKU et les adresses IP disponibles de chaque service. Par exemple, le nombre maximal de requêtes traitées par Azure App Configuration dépend du nombre de requêtes par seconde fourni par une unité d’échelle. Lorsque vous ajoutez des capacités dans une région, vous devez également ajouter des unités d’échelle individuelles.
Ces unités d’échelle individuelles ne présentent pas d’interdépendances et communiquent uniquement avec les services partagés en dehors de l’unité. Vous pouvez tester les unités d’échelle indépendantes en amont. Pour éviter d’affecter d’autres domaines de déploiement, déployez des unités d’échelle indépendantes et introduisez l’option de remplacement des services dans une nouvelle version.
Pour les charges de travail stratégiques, les unités d’échelle indépendantes sont temporaires, ce qui optimise les processus de déploiement et offre une scalabilité au sein des régions et entre elles. Évitez de stocker l’état dans des unités d’échelle indépendantes. Envisagez d’utiliser Azure Cache pour Redis pour assurer au stockage dans l’unité d’échelle et n’y stocker que l’état ou les données critiques qui sont également conservés dans la base de données. En cas de panne ou de remplacement de l’unité d’échelle, vous pouvez rencontrer un ralentissement ou devoir effectuer une nouvelle connexion. Quoi qu’il en soit Azure Cache pour Redis s’exécute toujours.
Application Insights est exclu de l’unité d’échelle. Excluez les services qui stockent ou surveillent des données. Séparez-les dans leur propre groupe de ressources avec leur propre cycle de vie.
Lorsque vous remplacez une unité d’échelle ou que vous en déployez une nouvelle, conservez les données historiques et utilisez une instance par région.
Pour plus d’informations, consultez l’article sur la conception d’applications de charges de travail stratégiques sur Azure.
Composants
Cette architecture utilise les composants ci-dessous.
- App Service est la plateforme d’hébergement des applications.
- Azure Cache pour Redis met les requêtes en cache.
- App Configuration stocke les paramètres de configuration.
- Azure SQL est la base de données back-end.
- Application Insights récupère les données de télémétrie de l’application.
Autres solutions
Dans le modèle d’application web fiable, vous pouvez :
- Utiliser Azure Kubernetes Service (AKS) à la place d’App Service. Cette option fonctionne bien avec les charges de travail complexes qui comptent un grand nombre de microservices. AKS offre un contrôle renforcé sur l’infrastructure sous-jacente et permet des configurations multiniveau complexes.
- Conteneuriser la charge de travail. App Service prend en charge la conteneurisation (toutefois, dans cet exemple, la charge de travail n’est pas conteneurisée). Utilisez des conteneurs pour augmenter la fiabilité et la portabilité.
Pour plus d’informations, consultez l’article Considérations relatives à la plateforme d’application pour les charges de travail stratégiques sur Azure.
Choisir la plateforme d’application
Le niveau de disponibilité dépend de votre choix et de la configuration de la plateforme d’application. Tenez compte des conseils stratégiques suivants :
- Utilisez des zones de disponibilité dès que possible.
- Sélectionnez le service de plateforme adapté à votre charge de travail.
- Conteneurisez la charge de travail.
Les groupes à haute disponibilité répartissent les déploiements entre plusieurs domaines d’erreur et de mise à jour au sein d’un centre de données. Les zones de disponibilité répartissent les déploiements entre plusieurs centres de données individuels au sein d’une région Azure. Les zones de disponibilité sont souvent hiérarchisées, même si la stratégie que vous utilisez dépend de votre charge de travail. Par exemple, les charges de travail sensibles à la latence ou bavardes peuvent tirer parti de la hiérarchisation des groupes à haute disponibilité. Si vous répartissez la charge de travail entre les zones de disponibilité, cela peut augmenter la latence et le coût du trafic interzone. Lorsque vous utilisez des zones de disponibilité, assurez-vous que tous les services de l’unité d’échelle les prennent en charge. Tous les services du modèle d’application web fiable prennent en charge les zones de disponibilité.
Choisir la plateforme de données
La plateforme de base de données que vous choisissez affecte l’architecture de la charge de travail globale, en particulier la prise en charge de la configuration active-active ou active-passive de la plateforme. Le modèle d’application web fiable utilise Azure SQL, qui ne prend pas nativement en charge les déploiements actifs-actifs avec les opérations d’écriture dans plusieurs instances. Le niveau de la base de données est donc limité à une stratégie active-passive. Vous pouvez appliquez une stratégie active-active au niveau de l’application s’il existe des réplicas en lecture seule et si vous écrivez dans une seule région.
Téléchargez le fichier Visio de cette architecture.
Les architectures complexes comportent souvent plusieurs bases de données, à l’instar des architectures de microservices qui comptent une base de données pour chaque service. L’utilisation de plusieurs bases de données permet d’adopter une base de données d’écriture multiprimaire (comme Azure Cosmos DB), ce qui améliore la haute disponibilité et la faible latence. La latence interrégion peut créer des limitations. Il est essentiel de tenir compte des exigences non fonctionnelles et des facteurs tels que la cohérence, l’opérabilité, le coût et la complexité. Autorisez les services individuels à utiliser des magasins de données distincts et des technologies de données spécialisées pour répondre à leurs besoins uniques. Pour plus d’informations, consultez l’article Considérations relatives à la plateforme de données pour les charges de travail stratégiques sur Azure.
Définir un modèle d’intégrité
Avec les charges de travail multiniveau complexes qui s’étendent sur plusieurs centres de données et régions géographiques, vous devez définir un modèle d’intégrité. Définissez les flux utilisateur/système. Définissez et identifiez les dépendances entre les services. Comprenez l’effet qu’une panne ou qu’une détérioration des performances de l’un des services peut avoir sur la charge de travail globale Surveillez et visualisez l’expérience client pour permettre une supervision appropriée et améliorer les actions manuelles et automatisées.
Le diagramme précédent décrit comment la panne ou la détérioration des performances d’un seul composant (comme App Configuration) peut entraîner une dégradation potentielle des performances côté client.
Lorsque vous séparez des composants en unités d’échelle, cela vous permet d’arrêter d’envoyer du trafic à la partie affectée de l’application (par exemple, une unité d’échelle affectée ou la région complète).
Pour plus d’informations, consultez Modélisation d’intégrité et observabilité des charges de travail critiques sur Azure.
Sécurité et mise en réseau
Il existe des exigences strictes en matière de mise en réseau et de sécurité pour les charges de travail qui migrent depuis un déploiement d’entreprise local. Les processus locaux établis ne se traduisent pas tous en environnement cloud. Évaluez ces exigences pour savoir si elles sont applicables aux environnements cloud.
L’identité est souvent le périmètre de sécurité principal pour les modèles natifs cloud. Les clients d’entreprise peuvent avoir besoin de mesures de sécurité plus importantes. Pour répondre à leurs exigences de sécurité réseau, la plupart des services PaaS Azure peuvent utiliser Azure Private Link pour implémenter le réseau en tant que périmètre de sécurité. Private Link garantit que les services sont uniquement accessibles à partir d’un réseau virtuel. Tous les services sont uniquement accessibles par le biais de points de terminaison privés. Le diagramme suivant décrit comment le seul point de terminaison accessible sur l’Internet public est Azure Front Door.
Télécharger le fichier Visio de cette architecture.
Pour configurer un réseau en tant que périmètre de sécurité, le modèle d’application web fiable doit utiliser :
- Private Link pour tous les services qui le prennent en charge.
- Azure Front Door Premium en tant qu’unique point de terminaison public accessible sur Internet.
- Des jumpboxes pour accéder aux services avec Azure Bastion.
- Des agents de build autohébergés qui peuvent accéder aux services.
Les applications stratégiques sont souvent soumises à une autre exigence, à savoir restreindre le trafic de sortie pour empêcher l’exfiltration de données. Limitez le trafic de sortie en acheminant un pare-feu Azure avec un appareil de pare-feu adapté et en le filtrant avec l’appareil. L’architecture de base de référence stratégique Azure avec des contrôles réseau utilise un pare-feu et Private Link.
Déploiement et test
Les temps d’arrêt provoqués par l’utilisation d’une version erronée ou une erreur humaine peuvent être un problème pour les charges de travail qui doivent toujours être disponibles. Voici quelques points clés à prendre en considération :
- Déploiements sans temps d’arrêt
- Déploiements bleus/verts éphémères
- Analyse du cycle de vie des composants individuels et regroupement de ceux-ci
- Validation continue
Les déploiements sans temps d’arrêt sont essentiels aux charges de travail stratégiques. Une charge de travail qui doit toujours être opérationnelle ne peut pas avoir de fenêtre de maintenance pour déployer des versions plus récentes. Pour contourner cette limitation, l’architecture stratégique d’Azure suit le modèle de déploiements sans temps d’arrêt. Les modifications sont déployées en tant que nouvelles unités d’échelle ou empreintes testées de bout en bout avant que le trafic y soit acheminé de manière incrémentielle. Une fois tout le trafic acheminé vers la nouvelle empreinte, les anciennes empreintes sont désactivées et supprimées.
Pour plus d’informations, consultez l’article Déploiement et tests de charges de travail stratégiques sur Azure.
Étapes suivantes
- Parcours d’apprentissage : créer des charges de travail stratégiques sur Azure
- Projet défi : concevoir une application web stratégique
- Module d’apprentissage : concevoir un modèle d’intégrité pour votre charge de travail stratégique