Base de référence stratégique avec App Service

Azure App Service

Azure Front Door

Azure Redis géré

Azure App Configuration

Azure Monitor

Cet article explique comment déployer des applications web critiques à l’aide d’Azure App Service. L’architecture utilise le modèle d’application web fiable comme point de départ. Utilisez cette architecture si vous avez une charge de travail héritée et souhaitez adopter des services PaaS (Platform as a Service).

modèle d’application web fiable pour .NET fournit des conseils pour mettre à jour ou réplatformer les applications web que vous déplacez vers le cloud. Cette approche vous aide à réduire les modifications de code requises et à cibler un objectif de niveau de service (SLO) de 99,9%. Les charges de travail critiques ont des exigences élevées en matière de fiabilité et de disponibilité. Pour atteindre un SLO de 99,95%, 99,99%, ou supérieur, vous devez appliquer des modèles de conception stratégiques supplémentaires et une rigueur opérationnelle. Cet article décrit les domaines techniques clés et la façon d’introduire et d’implémenter 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 de charge de travailWell-Architected Framework stratégiques.

Les sections suivantes décrivent comment :

• Passez en revue une charge de travail existante pour comprendre ses composants, ses flux utilisateur et système, ainsi que les exigences de disponibilité et d’extensibilité.
• Développez et implémentez une architecture d’unité d’échelle pour optimiser l’extensibilité de bout en bout grâce à la compartimentation et à normaliser le processus d’ajout et de suppression de capacité.
• Implémentez des unités d’échelle sans état, éphémères ou des tampons de déploiement pour activer la scalabilité et les déploiements sans temps d’arrêt.
• Déterminez si vous pouvez fractionner la charge de travail en composants pour préparer l’extensibilité. Les composants individuels sont requis pour l’extensibilité et le découplage des flux.
• Préparez-vous à distribution mondiale en déployant une charge de travail dans plusieurs régions Azure afin d’améliorer la proximité du client et de préparer les pannes régionales potentielles.
• Dissocier les composants et implémenter 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 .

Le diagramme montre une architecture d’application web critique qui s’étend sur deux régions Azure et utilise le modèle d’application web fiable. En haut, le diagramme montre deux groupes d’utilisateurs. Les utilisateurs du centre d’appels sur la gauche se connectent via l’ID Microsoft Entra, et les clients Relecloud se connectent directement à droite. Les deux groupes d’utilisateurs se connectent à Azure Front Door et à un pare-feu d’applications web (WAF), qui servent de point d’entrée global. Le trafic passe d’Azure Front Door à deux déploiements régionaux parallèles. Chaque région existe dans un groupe de ressources Web Apps. Dans chaque région, l’architecture contient plusieurs couches. La couche supérieure comprend les composants Azure Front Door et pare-feu. Sous cette couche, chaque région a une section de configuration qui inclut Azure Key Vault et Azure App Configuration. La couche intermédiaire contient la couche applicative qui inclut les applications web pour le serveur frontal web et les applications web pour l’API web. Les deux applications web se connectent à Application Insights pour la télémétrie. Chaque région inclut également un composant de déploiement de code. La couche réseau contient un sous-réseau App Service d’API, un sous-réseau App Service frontal et un sous-réseau de point de terminaison privé. Les connexions Azure Private Link lient les services aux sous-réseaux de point de terminaison privé. Les points de terminaison privés fournissent l’accès aux deux services de données. Entre les deux régions, le diagramme montre les zones DNS et Azure Managed Redis dans une position centrale. Les lignes en pointillés affichent le flux de trafic réseau entre les composants. Les flèches indiquent la direction des utilisateurs via Azure Front Door et vers le bas dans les couches d’application vers les services de données. L’architecture illustre la haute disponibilité par le biais de la redondance régionale, de la sécurité via des points de terminaison privés et de la distribution globale via des services Azure gérés dans plusieurs régions.

Téléchargez un fichier Visio de cette architecture.

La zone rouge représente une unité d’échelle avec les services mis à l’échelle ensemble. Pour les mettre à l’échelle ensemble, optimisez la taille, la référence SKU et les adresses IP disponibles de chaque service. Par exemple, le nombre maximal de requêtes qu’Azure App Configuration fournit correspond au nombre de requêtes par seconde qu’une unité d’échelle fournit. Lorsque vous ajoutez plus de capacité dans une région, vous devez également ajouter d’autres unités d’échelle individuelles.

Ces unités d’échelle individuelles n’ont pas de dépendances les unes sur les autres et communiquent uniquement avec les services partagés en dehors de l’unité d’échelle individuelle. Vous pouvez utiliser ces unités d’échelle dans une déploiement bleu-vert en déployant de nouvelles unités d’échelle, en validant qu’elles fonctionnent correctement et en déplaçant progressivement le trafic de production vers eux.

Dans ce scénario, les unités d’échelle sont temporaires, ce qui améliore les processus de déploiement et fournit une scalabilité dans et entre les régions. Lorsque vous effectuez cette approche, stockez uniquement les données système d’enregistrement persistantes dans la base de données, car la base de données est répliquée dans la région secondaire.

Utilisez Azure Managed Redis au sein ou en même temps qu’une unité d’échelle pour stocker l’état d’application auxiliaire comme les données de cache, l’état de session, les compteurs de limite de débit, les indicateurs de fonctionnalité et les métadonnées de coordination au sein de l’unité d’échelle. La géoréplication active permet aux données Redis de répliquer de manière asynchrone entre les régions afin d’améliorer la résilience et de réduire les objectifs de temps de récupération pendant les scénarios de basculement régionaux. Cette fonctionnalité s’applique généralement à l’état auxiliaire qui doit survivre aux pannes régionales, tandis que les données de cache entièrement régénérables restent locales dans une unité d’échelle.

Lorsque les unités d’échelle sont remplacées ou supprimées, les applications doivent être en mesure de se reconnecter de manière transparente au point de terminaison Redis. Concevez des données mises en cache de l’une des manières suivantes :

• État régénéré, qui inclut les entrées de cache que vous pouvez remplir à nouveau sans affecter la disponibilité

• État auxiliaire durable, que les fonctionnalités de disponibilité, de persistance et de géoréplication de votre cache protègent

Application Insights est exclu de l’unité d’échelle. Excluez les services qui stockent ou surveillent les données. Séparez-les dans leur propre groupe de ressources par leur propre cycle de vie.

Lorsque vous remplacez une unité d’échelle ou déployez-en une nouvelle, conservez les données historiques et utilisez une instance pour chaque région.

Pour plus d’informations, consultez conception d’applications de charges de travail stratégiques sur Azure.

Composants

Cette architecture utilise les composants suivants.

• App Service est une plateforme entièrement managée pour la création, le déploiement et la mise à l’échelle d’applications web. Dans cette architecture, App Service sert de plateforme d’hébergement d’applications au sein de chaque unité d’échelle. Il fournit l’infrastructure de calcul pour les applications web stratégiques qui ont des exigences de haute disponibilité et d’extensibilité.

• Azure Managed Redis est une plateforme de données en mémoire, entièrement managée basée sur Redis Enterprise. Dans cette architecture, Azure Managed Redis offre un accès à faible latence à l’état d’application auxiliaire au sein ou en même temps que chaque unité d’échelle, comme la mise en cache, les données de session, la limitation de débit, les indicateurs de fonctionnalités et la coordination distribuée. Il prend en charge le clustering, les zones de disponibilité, la persistance facultative et la géoréplication active, ce qui le rend adapté aux charges de travail stratégiques.

• App Configuration est un service qui gère de manière centralisée les paramètres d’application et les indicateurs de fonctionnalité. Dans cette architecture, App Configuration stocke les paramètres de configuration de l’application dans l’unité d’échelle. Sa capacité est directement corrélée au nombre de requêtes par seconde que chaque unité d’échelle peut gérer.

• Azure SQL est une collection de services de base de données SQL managés basés sur le moteur de base de données SQL Server. Dans cette architecture, Azure SQL sert de base de données principale qui stocke les données persistantes et est répliqué dans des régions secondaires.

• Application Insights est un service de gestion des performances des applications qui fournit des fonctionnalités de supervision et d’analytique. Dans cette architecture, Application Insights collecte les données de télémétrie à partir de l’application. Il est exclu des unités de mise à l’échelle pour maintenir son propre cycle de vie pour la conservation des données historiques et la surveillance des empreintes croisées.

Alternatives

Dans le modèle d’application web fiable, vous pouvez :

• Utilisez Azure Kubernetes Service (AKS) au lieu d’App Service. Cette option fonctionne bien pour les charges de travail complexes qui ont un grand nombre de microservices. AKS offre davantage de contrôle sur l’infrastructure sous-jacente et permet des configurations multiniveau complexes.
• Conteneuriser la charge de travail. App Service prend en charge la conteneurisation, mais 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 considérations relatives à la plateforme d’applications pour les charges de travail stratégiques sur Azure.

Considérations relatives à la haute disponibilité

Quelle que soit la plateforme d’application que vous choisissez, nous vous recommandons de hiérarchiser l’utilisation des zones de disponibilité pour les charges de travail de production.

groupes à haute disponibilité répartir les déploiements entre plusieurs domaines d’erreur et de mise à jour au sein d’un centre de données. zones de disponibilité répartir les déploiements entre différents centres de données au sein d’une région Azure. Les zones de disponibilité sont souvent hiérarchisées, mais la stratégie que vous utilisez dépend de votre charge de travail. Par exemple, les charges de travail sensibles à la latence ou chatty peuvent tirer parti de la hiérarchisation des groupes à haute disponibilité. Si vous répartissez la charge de travail entre les zones de disponibilité, elle peut augmenter la latence et le coût du trafic interzone. Lorsque vous utilisez des zones de disponibilité, assurez-vous que tous les services d’une 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 données que vous choisissez affecte l’architecture globale de la charge de travail, en particulier la prise en charge de la plateforme pour les modèles de déploiement actif-actif ou actif-passif. Dans le modèle d’application web fiable, Azure SQL sert de plateforme de données relationnelles principale. Azure SQL ne prend pas en charge en mode natif les déploiements actifs qui ont des écritures simultanées dans plusieurs régions. Par conséquent, ce modèle suit généralement une stratégie active-passive au niveau de la couche de base de données. Une approche active/active partielle est possible au niveau de l’application en déployant des réplicas en mode lecture seule dans plusieurs régions tout en dirigeant toutes les opérations d’écriture vers une seule région primaire.

Le diagramme montre une architecture de réplication des données pour une application web stratégique qui se déploie dans deux régions Azure et utilise une stratégie de base de données active-passive. En haut du diagramme, le trafic utilisateur entre via Azure Front Door, qui sert de point d’entrée global et d’équilibreur de charge. En dessous d’Azure Front Door, l’architecture se divise en deux déploiements régionaux parallèles étiquetés Région 1 à gauche et Région 2 à droite. Chaque région contient un niveau d’application identique qui possède des instances App Service qui hébergent les couches d’application web et d’API. Dans le centre entre les deux régions, Azure Managed Redis sert de couche de mise en cache partagée qui s’étend sur les deux régions et prend en charge la géoréplication active pour l’état d’application auxiliaire. En bas de chaque région, les instances Azure SQL Database forment la couche de persistance des données. La base de données SQL dans la région 1 sert de base de données principale qui a des fonctionnalités de lecture-écriture. La base de données SQL dans la région 2 sert de réplique en lecture seule. Une ligne en pointillés connecte les deux instances de base de données pour représenter la relation de réplication asynchrone. Toutes les opérations d’écriture des deux niveaux d’application régionaux sont directes vers la base de données primaire dans la région 1. Le réplica en lecture seule dans la région 2 gère localement les opérations de lecture. Cette configuration illustre un modèle de base de données actif-passif où une seule région accepte les écritures alors que les deux régions servent le trafic de lecture. Cette approche permet une haute disponibilité et une distribution géographique et maintient la cohérence des données via un point de terminaison d’écriture unique.

Plusieurs bases de données sont courantes dans les architectures complexes, telles que les architectures de microservices qui ont une base de données pour chaque service. Plusieurs bases de données permettent l’adoption d’une base de données d’écriture multiple principale 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 prendre en compte les exigences non fonctionnelles et les facteurs tels que la cohérence, l’opéraabilité, le coût et la complexité. Permettre aux services individuels d’utiliser des magasins de données distincts et des technologies de données spécialisées pour répondre à leurs exigences uniques. Pour plus d’informations, consultez considérations relatives à la plateforme de données pour les charges de travail stratégiques sur Azure.

Plateforme de mise en cache

Dans les charges de travail à forte écriture ou celles nécessitant une latence d’écriture très faible, écrire directement dans la base de données relationnelle sur le chemin de la requête peut créer un goulot d’étranglement en termes d'évolutivité ou de latence. Dans ces scénarios, introduisez Azure Managed Redis en tant que plateforme de données de la couche Application pour accélérer le débit d’écriture et protéger la base de données système d’enregistrement.

Lorsque vous effectuez cette approche, Azure Managed Redis sert de cible d’écriture initiale pour les domaines de données sélectionnés, tandis que les données persistent de manière asynchrone dans Azure SQL à l’aide d’un modèle d’écriture-behind ou d’écriture différée . Cette conception permet à l’application d’absorber les rafales d’écritures qui ont une faible latence tout en conservant Azure SQL comme système d’enregistrement faisant autorité. Les cas d’usage classiques incluent les mises à jour de session, les compteurs, la limitation du débit, les transitions d’état, l’agrégation de télémétrie et d’autres données qui peuvent tolérer une cohérence éventuelle.

Azure Managed Redis prend également en charge la géoréplication active, ce qui permet aux données sauvegardées par Redis de répliquer de manière asynchrone entre les régions. Lorsqu’elle est appliquée de manière sélective, la géoréplication active permet à des catégories spécifiques d’état d’application de participer aux conceptions d’applications actives, même lorsque la base de données relationnelle principale reste active-passive. Cette fonctionnalité peut réduire considérablement les RTO (Recovery Time Objective) pendant les scénarios de basculement régionaux.

En plus de la mise en cache en écriture différée, les charges de travail critiques utilisent souvent la mise en cache prérécupération ou la mise en cache en lecture anticipée pour précharger des données de manière proactive dans Redis géré par Azure en fonction des modèles d'accès prédéfinis, des travaux planifiés ou des événements de modification. La prérécupération réduit la latence de démarrage à froid pour les nouvelles unités d’échelle et améliore la latence de fin pendant les pics de trafic, ce qui est particulièrement important lorsque les unités d’échelle sont éphémères.

Définir un modèle d’intégrité

Dans les charges de travail multiniveau complexes réparties entre plusieurs centres de données et régions géographiques, vous devez définir un modèle d’intégrité.

Pour définir un modèle d’intégrité :

• Définir des flux utilisateur et système
• Spécifier et comprendre les dépendances entre les services
• Comprendre l’effet que les pannes ou une dégradation des performances sur l’un des services peuvent avoir sur la charge de travail globale
• Surveillez et visualisez l’expérience client pour permettre une surveillance appropriée et améliorer les actions manuelles et automatisées.

Le diagramme montre un flux de dépendances qui illustre la façon dont une défaillance d’un composant unique cascade par le biais d’une architecture d’application stratégique. Azure Front Door apparaît en haut. Deux sections d’unité d’échelle apparaissent ci-dessous. Chaque unité d’échelle contient Azure App Service, Azure App Configuration, Azure Key Vault et Azure SQL Database. Dans la première section, une flèche rouge avec un point X d’Azure Front Door vers App Service pour indiquer une panne. Une autre flèche rouge avec un point X d’App Service vers App Configuration. Dans la deuxième section, une flèche pointe d’Azure Front Door vers App Service pour afficher le routage normal du trafic.

Le diagramme précédent montre comment une panne ou une dégradation d’un composant unique, comme App Configuration, peut entraîner une dégradation potentielle des performances pour le client. Lorsque vous séparez des composants en unités d’échelle, il vous permet d’arrêter l’envoi du trafic à la partie affectée de l’application, tel qu’une unité d’échelle affectée ou la région complète.

Les critères permettant de déterminer l’intégrité d’une unité d’échelle sont définis dans le modèle d’intégrité. Ce modèle est ensuite connecté au point de terminaison d’intégrité de l’unité d’échelle, ce qui permet à l’équilibreur de charge global d’interroger l’état d’intégrité d’une unité d’échelle et d’utiliser ces informations pour les décisions de routage.

Pour plus d’informations, consultez Modélisation et observation de l’intégrité des charges de travail stratégiques sur Azure.

Sécurité et mise en réseau

Les charges de travail critiques ont des exigences strictes en matière de mise en réseau et de sécurité. Appliquez une diligence en particulier aux charges de travail migrées à partir d’un environnement local, car toutes les pratiques de sécurité locales établies se traduisent par un environnement cloud. Nous vous recommandons de réévaluer les exigences de sécurité pendant la migration de l’application.

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, les services PaaS Azure peuvent utiliser Azure Private Link pour implémenter le réseau comme périmètre de sécurité. Private Link permet de s’assurer que les services sont accessibles uniquement à partir d’un réseau virtuel. Tous les services sont ensuite accessibles via des points de terminaison privés uniquement. Le diagramme suivant montre comment le seul point de terminaison public accessible sur Internet est Azure Front Door.

Le diagramme montre une architecture de sécurité réseau qui implémente un périmètre réseau via Private Link et des points de terminaison privés, où Azure Front Door sert de composant public unique accessible sur Internet. En haut à gauche du diagramme, les utilisateurs externes de l’Internet public apparaissent comme point d’entrée. Les flèches circulent de ces utilisateurs vers Azure Front Door, positionnées au centre supérieur, qui sert de point de terminaison public unique qui accepte le trafic entrant à partir d’Internet. Une icône de limite cloud sépare l’Internet public de l’environnement Azure pour indiquer le périmètre de sécurité. À partir d’Azure Front Door, le trafic transite vers un réseau virtuel. Une grande zone représente le réseau virtuel et contient tous les services Azure internes. À l’intérieur de la limite de réseau virtuel sur le côté gauche, le diagramme montre une disposition verticale des services PaaS Azure privés qui incluent App Service, Azure SQL Database, Stockage Azure et App Configuration. Chacun de ces services se connecte au réseau virtuel via Private Link. Sur le côté droit du réseau virtuel, le diagramme montre les instances App Service et d’autres ressources de calcul qui communiquent via l’infrastructure de réseau virtuel interne plutôt que sur l’Internet public pour atteindre les services PaaS. Les lignes pointillées qui ont des flèches connectent ces services internes pour afficher les chemins de communication privés qui circulent entre les services au sein du réseau virtuel. À droite, Azure Bastion apparaît et inclut une zone de raccourci pour illustrer l’accès administratif aux ressources internes sans exposition directe à Internet. Toutes les flèches qui connectent les services à l’intérieur du réseau virtuel restent dans la limite du réseau pour souligner qu’aucun service interne n’expose un point de terminaison public.

Pour que le modèle d’application web fiable configure un réseau en tant que périmètre de sécurité, il doit utiliser :

• Private Link pour tous les services qui le prennent en charge.
• Azure Front Door Premium comme seul point de terminaison public accessible sur Internet.
• Zones de saut pour accéder aux services via Azure Bastion.
• Agents de build auto-hébergés qui peuvent accéder aux services.

Une autre exigence réseau courante pour les applications stratégiques consiste à restreindre le trafic de sortie pour empêcher l’exfiltration des données. Limitez le trafic de sortie en acheminant tout le trafic quittant le sous-réseau via un appareil de pare-feu où le trafic est filtré avant de passer à son tronçon suivant.

Déploiement et test

Les temps d’arrêt causés par des versions erronées ou une erreur humaine peuvent être un problème pour une charge de travail qui doit toujours être disponible. Voici quelques domaines clés à prendre en compte :

• Déploiements sans temps d’arrêt
• Déploiements bleu-vert éphémères
• Analyse du cycle de vie des composants individuels et groupés
• Validation continue

déploiements sans temps d’arrêt sont essentiels pour les 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 critique 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 tampons testés de bout en bout avant que le trafic ne soit routé de manière incrémentielle vers eux. Une fois que tout le trafic est acheminé vers le nouveau tampon, les anciens tampons sont désactivés et supprimés.

Pour plus d’informations, consultez Déploiement et test pour les charges de travail stratégiques sur Azure.

Étapes suivantes

• parcours d’apprentissage : Créer des charges de travail stratégiques sur Azure
• projet Challenge : concevoir une application web stratégique
• module Learn : Concevoir un modèle d’intégrité pour votre charge de travail stratégique

Ressources associées

• Architecture critique sur Azure
• validation continue avec azure Load Testing et Azure Chaos Studio

Cet article explique comment déployer des applications web critiques à l’aide d’Azure App Service. L’architecture utilise le modèle d’application web fiable comme point de départ. Utilisez cette architecture si vous avez une charge de travail héritée et souhaitez adopter des services PaaS (Platform as a Service).

modèle d’application web fiable pour .NET fournit des conseils pour mettre à jour ou réplatformer les applications web que vous déplacez vers le cloud. Cette approche vous aide à réduire les modifications de code requises et à cibler un objectif de niveau de service (SLO) de 99,9%. Les charges de travail critiques ont des exigences élevées en matière de fiabilité et de disponibilité. Pour atteindre un SLO de 99,95%, 99,99%, ou supérieur, vous devez appliquer des modèles de conception stratégiques supplémentaires et une rigueur opérationnelle. Cet article décrit les domaines techniques clés et la façon d’introduire et d’implémenter 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 de charge de travailWell-Architected Framework stratégiques.

Les sections suivantes décrivent comment :

• Passez en revue une charge de travail existante pour comprendre ses composants, ses flux utilisateur et système, ainsi que les exigences de disponibilité et d’extensibilité.
• Développez et implémentez une architecture d’unité d’échelle pour optimiser l’extensibilité de bout en bout grâce à la compartimentation et à normaliser le processus d’ajout et de suppression de capacité.
• Implémentez des unités d’échelle sans état, éphémères ou des tampons de déploiement pour activer la scalabilité et les déploiements sans temps d’arrêt.
• Déterminez si vous pouvez fractionner la charge de travail en composants pour préparer l’extensibilité. Les composants individuels sont requis pour l’extensibilité et le découplage des flux.
• Préparez-vous à distribution mondiale en déployant une charge de travail dans plusieurs régions Azure afin d’améliorer la proximité du client et de préparer les pannes régionales potentielles.
• Dissocier les composants et implémenter 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 .

Le diagramme montre une architecture d’application web critique qui s’étend sur deux régions Azure et utilise le modèle d’application web fiable. En haut, le diagramme montre deux groupes d’utilisateurs. Les utilisateurs du centre d’appels sur la gauche se connectent via l’ID Microsoft Entra, et les clients Relecloud se connectent directement à droite. Les deux groupes d’utilisateurs se connectent à Azure Front Door et à un pare-feu d’applications web (WAF), qui servent de point d’entrée global. Le trafic passe d’Azure Front Door à deux déploiements régionaux parallèles. Chaque région existe dans un groupe de ressources Web Apps. Dans chaque région, l’architecture contient plusieurs couches. La couche supérieure comprend les composants Azure Front Door et pare-feu. Sous cette couche, chaque région a une section de configuration qui inclut Azure Key Vault et Azure App Configuration. La couche intermédiaire contient la couche applicative qui inclut les applications web pour le serveur frontal web et les applications web pour l’API web. Les deux applications web se connectent à Application Insights pour la télémétrie. Chaque région inclut également un composant de déploiement de code. La couche réseau contient un sous-réseau App Service d’API, un sous-réseau App Service frontal et un sous-réseau de point de terminaison privé. Les connexions Azure Private Link lient les services aux sous-réseaux de point de terminaison privé. Les points de terminaison privés fournissent l’accès aux deux services de données. Entre les deux régions, le diagramme montre les zones DNS et Azure Managed Redis dans une position centrale. Les lignes en pointillés affichent le flux de trafic réseau entre les composants. Les flèches indiquent la direction des utilisateurs via Azure Front Door et vers le bas dans les couches d’application vers les services de données. L’architecture illustre la haute disponibilité par le biais de la redondance régionale, de la sécurité via des points de terminaison privés et de la distribution globale via des services Azure gérés dans plusieurs régions.

Téléchargez un fichier Visio de cette architecture.

La zone rouge représente une unité d’échelle avec les services mis à l’échelle ensemble. Pour les mettre à l’échelle ensemble, optimisez la taille, la référence SKU et les adresses IP disponibles de chaque service. Par exemple, le nombre maximal de requêtes qu’Azure App Configuration fournit correspond au nombre de requêtes par seconde qu’une unité d’échelle fournit. Lorsque vous ajoutez plus de capacité dans une région, vous devez également ajouter d’autres unités d’échelle individuelles.

Ces unités d’échelle individuelles n’ont pas de dépendances les unes sur les autres et communiquent uniquement avec les services partagés en dehors de l’unité d’échelle individuelle. Vous pouvez utiliser ces unités d’échelle dans une déploiement bleu-vert en déployant de nouvelles unités d’échelle, en validant qu’elles fonctionnent correctement et en déplaçant progressivement le trafic de production vers eux.

Dans ce scénario, les unités d’échelle sont temporaires, ce qui améliore les processus de déploiement et fournit une scalabilité dans et entre les régions. Lorsque vous effectuez cette approche, stockez uniquement les données système d’enregistrement persistantes dans la base de données, car la base de données est répliquée dans la région secondaire.

Utilisez Azure Managed Redis au sein ou en même temps qu’une unité d’échelle pour stocker l’état d’application auxiliaire comme les données de cache, l’état de session, les compteurs de limite de débit, les indicateurs de fonctionnalité et les métadonnées de coordination au sein de l’unité d’échelle. La géoréplication active permet aux données Redis de répliquer de manière asynchrone entre les régions afin d’améliorer la résilience et de réduire les objectifs de temps de récupération pendant les scénarios de basculement régionaux. Cette fonctionnalité s’applique généralement à l’état auxiliaire qui doit survivre aux pannes régionales, tandis que les données de cache entièrement régénérables restent locales dans une unité d’échelle.

Lorsque les unités d’échelle sont remplacées ou supprimées, les applications doivent être en mesure de se reconnecter de manière transparente au point de terminaison Redis. Concevez des données mises en cache de l’une des manières suivantes :

• État régénéré, qui inclut les entrées de cache que vous pouvez remplir à nouveau sans affecter la disponibilité

• État auxiliaire durable, que les fonctionnalités de disponibilité, de persistance et de géoréplication de votre cache protègent

Application Insights est exclu de l’unité d’échelle. Excluez les services qui stockent ou surveillent les données. Séparez-les dans leur propre groupe de ressources par leur propre cycle de vie.

Lorsque vous remplacez une unité d’échelle ou déployez-en une nouvelle, conservez les données historiques et utilisez une instance pour chaque région.

Pour plus d’informations, consultez conception d’applications de charges de travail stratégiques sur Azure.

Composants

Cette architecture utilise les composants suivants.

• App Service est une plateforme entièrement managée pour la création, le déploiement et la mise à l’échelle d’applications web. Dans cette architecture, App Service sert de plateforme d’hébergement d’applications au sein de chaque unité d’échelle. Il fournit l’infrastructure de calcul pour les applications web stratégiques qui ont des exigences de haute disponibilité et d’extensibilité.

• Azure Managed Redis est une plateforme de données en mémoire, entièrement managée basée sur Redis Enterprise. Dans cette architecture, Azure Managed Redis offre un accès à faible latence à l’état d’application auxiliaire au sein ou en même temps que chaque unité d’échelle, comme la mise en cache, les données de session, la limitation de débit, les indicateurs de fonctionnalités et la coordination distribuée. Il prend en charge le clustering, les zones de disponibilité, la persistance facultative et la géoréplication active, ce qui le rend adapté aux charges de travail stratégiques.

• App Configuration est un service qui gère de manière centralisée les paramètres d’application et les indicateurs de fonctionnalité. Dans cette architecture, App Configuration stocke les paramètres de configuration de l’application dans l’unité d’échelle. Sa capacité est directement corrélée au nombre de requêtes par seconde que chaque unité d’échelle peut gérer.

• Azure SQL est une collection de services de base de données SQL managés basés sur le moteur de base de données SQL Server. Dans cette architecture, Azure SQL sert de base de données principale qui stocke les données persistantes et est répliqué dans des régions secondaires.

• Application Insights est un service de gestion des performances des applications qui fournit des fonctionnalités de supervision et d’analytique. Dans cette architecture, Application Insights collecte les données de télémétrie à partir de l’application. Il est exclu des unités de mise à l’échelle pour maintenir son propre cycle de vie pour la conservation des données historiques et la surveillance des empreintes croisées.

Alternatives

Dans le modèle d’application web fiable, vous pouvez :

• Utilisez Azure Kubernetes Service (AKS) au lieu d’App Service. Cette option fonctionne bien pour les charges de travail complexes qui ont un grand nombre de microservices. AKS offre davantage de contrôle sur l’infrastructure sous-jacente et permet des configurations multiniveau complexes.
• Conteneuriser la charge de travail. App Service prend en charge la conteneurisation, mais 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 considérations relatives à la plateforme d’applications pour les charges de travail stratégiques sur Azure.

Considérations relatives à la haute disponibilité

Quelle que soit la plateforme d’application que vous choisissez, nous vous recommandons de hiérarchiser l’utilisation des zones de disponibilité pour les charges de travail de production.

groupes à haute disponibilité répartir les déploiements entre plusieurs domaines d’erreur et de mise à jour au sein d’un centre de données. zones de disponibilité répartir les déploiements entre différents centres de données au sein d’une région Azure. Les zones de disponibilité sont souvent hiérarchisées, mais la stratégie que vous utilisez dépend de votre charge de travail. Par exemple, les charges de travail sensibles à la latence ou chatty peuvent tirer parti de la hiérarchisation des groupes à haute disponibilité. Si vous répartissez la charge de travail entre les zones de disponibilité, elle peut augmenter la latence et le coût du trafic interzone. Lorsque vous utilisez des zones de disponibilité, assurez-vous que tous les services d’une 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 données que vous choisissez affecte l’architecture globale de la charge de travail, en particulier la prise en charge de la plateforme pour les modèles de déploiement actif-actif ou actif-passif. Dans le modèle d’application web fiable, Azure SQL sert de plateforme de données relationnelles principale. Azure SQL ne prend pas en charge en mode natif les déploiements actifs qui ont des écritures simultanées dans plusieurs régions. Par conséquent, ce modèle suit généralement une stratégie active-passive au niveau de la couche de base de données. Une approche active/active partielle est possible au niveau de l’application en déployant des réplicas en mode lecture seule dans plusieurs régions tout en dirigeant toutes les opérations d’écriture vers une seule région primaire.

Le diagramme montre une architecture de réplication des données pour une application web stratégique qui se déploie dans deux régions Azure et utilise une stratégie de base de données active-passive. En haut du diagramme, le trafic utilisateur entre via Azure Front Door, qui sert de point d’entrée global et d’équilibreur de charge. En dessous d’Azure Front Door, l’architecture se divise en deux déploiements régionaux parallèles étiquetés Région 1 à gauche et Région 2 à droite. Chaque région contient un niveau d’application identique qui possède des instances App Service qui hébergent les couches d’application web et d’API. Dans le centre entre les deux régions, Azure Managed Redis sert de couche de mise en cache partagée qui s’étend sur les deux régions et prend en charge la géoréplication active pour l’état d’application auxiliaire. En bas de chaque région, les instances Azure SQL Database forment la couche de persistance des données. La base de données SQL dans la région 1 sert de base de données principale qui a des fonctionnalités de lecture-écriture. La base de données SQL dans la région 2 sert de réplique en lecture seule. Une ligne en pointillés connecte les deux instances de base de données pour représenter la relation de réplication asynchrone. Toutes les opérations d’écriture des deux niveaux d’application régionaux sont directes vers la base de données primaire dans la région 1. Le réplica en lecture seule dans la région 2 gère localement les opérations de lecture. Cette configuration illustre un modèle de base de données actif-passif où une seule région accepte les écritures alors que les deux régions servent le trafic de lecture. Cette approche permet une haute disponibilité et une distribution géographique et maintient la cohérence des données via un point de terminaison d’écriture unique.

Plusieurs bases de données sont courantes dans les architectures complexes, telles que les architectures de microservices qui ont une base de données pour chaque service. Plusieurs bases de données permettent l’adoption d’une base de données d’écriture multiple principale 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 prendre en compte les exigences non fonctionnelles et les facteurs tels que la cohérence, l’opéraabilité, le coût et la complexité. Permettre aux services individuels d’utiliser des magasins de données distincts et des technologies de données spécialisées pour répondre à leurs exigences uniques. Pour plus d’informations, consultez considérations relatives à la plateforme de données pour les charges de travail stratégiques sur Azure.

Plateforme de mise en cache

Dans les charges de travail à forte écriture ou celles nécessitant une latence d’écriture très faible, écrire directement dans la base de données relationnelle sur le chemin de la requête peut créer un goulot d’étranglement en termes d'évolutivité ou de latence. Dans ces scénarios, introduisez Azure Managed Redis en tant que plateforme de données de la couche Application pour accélérer le débit d’écriture et protéger la base de données système d’enregistrement.

Lorsque vous effectuez cette approche, Azure Managed Redis sert de cible d’écriture initiale pour les domaines de données sélectionnés, tandis que les données persistent de manière asynchrone dans Azure SQL à l’aide d’un modèle d’écriture-behind ou d’écriture différée . Cette conception permet à l’application d’absorber les rafales d’écritures qui ont une faible latence tout en conservant Azure SQL comme système d’enregistrement faisant autorité. Les cas d’usage classiques incluent les mises à jour de session, les compteurs, la limitation du débit, les transitions d’état, l’agrégation de télémétrie et d’autres données qui peuvent tolérer une cohérence éventuelle.

Azure Managed Redis prend également en charge la géoréplication active, ce qui permet aux données sauvegardées par Redis de répliquer de manière asynchrone entre les régions. Lorsqu’elle est appliquée de manière sélective, la géoréplication active permet à des catégories spécifiques d’état d’application de participer aux conceptions d’applications actives, même lorsque la base de données relationnelle principale reste active-passive. Cette fonctionnalité peut réduire considérablement les RTO (Recovery Time Objective) pendant les scénarios de basculement régionaux.

En plus de la mise en cache en écriture différée, les charges de travail critiques utilisent souvent la mise en cache prérécupération ou la mise en cache en lecture anticipée pour précharger des données de manière proactive dans Redis géré par Azure en fonction des modèles d'accès prédéfinis, des travaux planifiés ou des événements de modification. La prérécupération réduit la latence de démarrage à froid pour les nouvelles unités d’échelle et améliore la latence de fin pendant les pics de trafic, ce qui est particulièrement important lorsque les unités d’échelle sont éphémères.

Définir un modèle d’intégrité

Dans les charges de travail multiniveau complexes réparties entre plusieurs centres de données et régions géographiques, vous devez définir un modèle d’intégrité.

Pour définir un modèle d’intégrité :

• Définir des flux utilisateur et système
• Spécifier et comprendre les dépendances entre les services
• Comprendre l’effet que les pannes ou une dégradation des performances sur l’un des services peuvent avoir sur la charge de travail globale
• Surveillez et visualisez l’expérience client pour permettre une surveillance appropriée et améliorer les actions manuelles et automatisées.

Le diagramme montre un flux de dépendances qui illustre la façon dont une défaillance d’un composant unique cascade par le biais d’une architecture d’application stratégique. Azure Front Door apparaît en haut. Deux sections d’unité d’échelle apparaissent ci-dessous. Chaque unité d’échelle contient Azure App Service, Azure App Configuration, Azure Key Vault et Azure SQL Database. Dans la première section, une flèche rouge avec un point X d’Azure Front Door vers App Service pour indiquer une panne. Une autre flèche rouge avec un point X d’App Service vers App Configuration. Dans la deuxième section, une flèche pointe d’Azure Front Door vers App Service pour afficher le routage normal du trafic.

Le diagramme précédent montre comment une panne ou une dégradation d’un composant unique, comme App Configuration, peut entraîner une dégradation potentielle des performances pour le client. Lorsque vous séparez des composants en unités d’échelle, il vous permet d’arrêter l’envoi du trafic à la partie affectée de l’application, tel qu’une unité d’échelle affectée ou la région complète.

Les critères permettant de déterminer l’intégrité d’une unité d’échelle sont définis dans le modèle d’intégrité. Ce modèle est ensuite connecté au point de terminaison d’intégrité de l’unité d’échelle, ce qui permet à l’équilibreur de charge global d’interroger l’état d’intégrité d’une unité d’échelle et d’utiliser ces informations pour les décisions de routage.

Pour plus d’informations, consultez Modélisation et observation de l’intégrité des charges de travail stratégiques sur Azure.

Sécurité et mise en réseau

Les charges de travail critiques ont des exigences strictes en matière de mise en réseau et de sécurité. Appliquez une diligence en particulier aux charges de travail migrées à partir d’un environnement local, car toutes les pratiques de sécurité locales établies se traduisent par un environnement cloud. Nous vous recommandons de réévaluer les exigences de sécurité pendant la migration de l’application.

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, les services PaaS Azure peuvent utiliser Azure Private Link pour implémenter le réseau comme périmètre de sécurité. Private Link permet de s’assurer que les services sont accessibles uniquement à partir d’un réseau virtuel. Tous les services sont ensuite accessibles via des points de terminaison privés uniquement. Le diagramme suivant montre comment le seul point de terminaison public accessible sur Internet est Azure Front Door.

Le diagramme montre une architecture de sécurité réseau qui implémente un périmètre réseau via Private Link et des points de terminaison privés, où Azure Front Door sert de composant public unique accessible sur Internet. En haut à gauche du diagramme, les utilisateurs externes de l’Internet public apparaissent comme point d’entrée. Les flèches circulent de ces utilisateurs vers Azure Front Door, positionnées au centre supérieur, qui sert de point de terminaison public unique qui accepte le trafic entrant à partir d’Internet. Une icône de limite cloud sépare l’Internet public de l’environnement Azure pour indiquer le périmètre de sécurité. À partir d’Azure Front Door, le trafic transite vers un réseau virtuel. Une grande zone représente le réseau virtuel et contient tous les services Azure internes. À l’intérieur de la limite de réseau virtuel sur le côté gauche, le diagramme montre une disposition verticale des services PaaS Azure privés qui incluent App Service, Azure SQL Database, Stockage Azure et App Configuration. Chacun de ces services se connecte au réseau virtuel via Private Link. Sur le côté droit du réseau virtuel, le diagramme montre les instances App Service et d’autres ressources de calcul qui communiquent via l’infrastructure de réseau virtuel interne plutôt que sur l’Internet public pour atteindre les services PaaS. Les lignes pointillées qui ont des flèches connectent ces services internes pour afficher les chemins de communication privés qui circulent entre les services au sein du réseau virtuel. À droite, Azure Bastion apparaît et inclut une zone de raccourci pour illustrer l’accès administratif aux ressources internes sans exposition directe à Internet. Toutes les flèches qui connectent les services à l’intérieur du réseau virtuel restent dans la limite du réseau pour souligner qu’aucun service interne n’expose un point de terminaison public.

Pour que le modèle d’application web fiable configure un réseau en tant que périmètre de sécurité, il doit utiliser :

• Private Link pour tous les services qui le prennent en charge.
• Azure Front Door Premium comme seul point de terminaison public accessible sur Internet.
• Zones de saut pour accéder aux services via Azure Bastion.
• Agents de build auto-hébergés qui peuvent accéder aux services.

Une autre exigence réseau courante pour les applications stratégiques consiste à restreindre le trafic de sortie pour empêcher l’exfiltration des données. Limitez le trafic de sortie en acheminant tout le trafic quittant le sous-réseau via un appareil de pare-feu où le trafic est filtré avant de passer à son tronçon suivant.

Déploiement et test

Les temps d’arrêt causés par des versions erronées ou une erreur humaine peuvent être un problème pour une charge de travail qui doit toujours être disponible. Voici quelques domaines clés à prendre en compte :

• Déploiements sans temps d’arrêt
• Déploiements bleu-vert éphémères
• Analyse du cycle de vie des composants individuels et groupés
• Validation continue

déploiements sans temps d’arrêt sont essentiels pour les 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 critique 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 tampons testés de bout en bout avant que le trafic ne soit routé de manière incrémentielle vers eux. Une fois que tout le trafic est acheminé vers le nouveau tampon, les anciens tampons sont désactivés et supprimés.

Pour plus d’informations, consultez Déploiement et test pour les charges de travail stratégiques sur Azure.

Étapes suivantes

• parcours d’apprentissage : Créer des charges de travail stratégiques sur Azure
• projet Challenge : concevoir une application web stratégique
• module Learn : Concevoir un modèle d’intégrité pour votre charge de travail stratégique

Ressources associées

• Architecture critique sur Azure
• validation continue avec azure Load Testing et Azure Chaos Studio