Application web multirégion hautement disponible

Cet exemple d’architecture est basé sur l’exemple d’architecture d’application web de base et l’étend pour afficher :

• Des pratiques éprouvées pour améliorer la scalabilité et la performance d’une application web Azure App Service
• Découvrez comment exécuter une application Azure App Service dans plusieurs régions afin de bénéficier d’une haute disponibilité

Architecture

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

Workflow

Ce flux de travail traite les aspects multi-régions de l’architecture et s’appuie sur l’application web de base.

• Régions primaires et secondaires. Cette architecture utilise deux régions pour garantir une meilleure disponibilité. L’application est déployée dans chaque région. Pendant les opérations normales, le trafic réseau est routé vers la région primaire. Si la région primaire n’est plus disponible, le trafic est routé vers la région secondaire.
• Front Door. Azure Front Door est l’équilibreur de charge recommandé pour les implémentations multi-régions. Il s’intègre au pare-feu d’applications web (WAF) pour se protéger contre les attaques courantes et utilise la fonctionnalité de mise en cache de contenu native de Front Door. Dans cette architecture, Front Door est configuré pour le routage prioritaire, qui envoie tout le trafic vers la région primaire, sauf si elle n’est plus disponible. Si la région primaire n’est plus disponible, Front Door achemine le trafic vers la région secondaire.
• Géoréplication des comptes Stockage, SQL Database et/ou Azure Cosmos DB.

Components

Technologies clés utilisées pour implémenter cette architecture :

• Microsoft Entra ID est un service de gestion des identités et des accès cloud qui permet aux employés d’accéder aux applications cloud développées pour votre organisation.
• DNS Azure est un service d’hébergement pour les domaines DNS qui offre une résolution de noms à l’aide de l’infrastructure Microsoft Azure. En hébergeant vos domaines dans Azure, vous pouvez gérer vos enregistrements DNS avec les mêmes informations d’identification, les mêmes API, les mêmes outils et la même facturation que vos autres services Azure. Pour utiliser un nom de domaine personnalisé, tel que contoso.com, créez des enregistrements DNS qui mappent le nom de domaine personnalisé sur l’adresse IP. Pour plus d’informations, consultez Configurer un nom de domaine personnalisé dans Azure App Service.
• Azure Content Delivery Network est une solution globale pour la distribution rapide de contenu à haut débit en mettant en cache le contenu sur des nœuds physiques stratégiquement placés dans le monde entier.
• Azure Front Door est un équilibreur de charge de couche 7. Dans cette architecture, il achemine les requêtes HTTP vers le serveur web frontal. Front Door fournit également un pare-feu d'applications web (WAF) qui protège l'application contre les vulnérabilités et exploitations courantes. Front Door est également utilisé pour une solution Content Delivery Network (CDN) dans cette conception.
• Azure AppService est une plateforme complètement managée qui permet de créer et de déployer des applications cloud. Il vous permet de définir un ensemble de ressources de calcul pour une application web à exécuter, déployer des applications web et configurer des emplacements de déploiement.
• Azure Function Apps peut être utilisé pour exécuter des tâches en arrière-plan. Les fonctions sont appelées par un déclencheur, comme un événement de minuteur ou un message placé dans la file d’attente. Pour les tâches avec état exécutées sur le long terme, utilisez Durable Functions.
• Stockage Azure est une solution de stockage cloud pour les scénarios de stockage de données modernes qui offre un stockage hautement disponible, hautement évolutif, durable et sécurisé pour divers objets de données dans le cloud.
• Azure Cache pour Redis est un service de mise en cache hautes performances qui fournit un magasin de données en mémoire pour une récupération plus rapide des données, en fonction de l’implémentation open source du cache Redis.
• Azure SQL Database est une base de données relationnelle en tant que service du cloud. SQL Database partage sa base de code avec le moteur de base de données Microsoft SQL Server.
• Azure Cosmos DB est une base de données d’API multi-modèle, entièrement managée, à faible latence et multi-requête distribuée à l’échelle mondiale pour la gestion des données à grande échelle.
• Recherche Azure AI peut être utilisée pour ajouter des fonctionnalités de recherche telles que des suggestions de recherche, une recherche approximative et une recherche spécifique à la langue. Recherche Azure est généralement utilisé conjointement avec un autre magasin de données, surtout si le magasin de données principal requiert la cohérence stricte. Dans cette approche, stockez les données faisant autorité dans l’autre magasin de données et l’index de recherche dans Recherche Azure. Recherche Azure peut également servir à consolider un index de recherche unique à partir de plusieurs magasins de données.

Détails du scénario

Plusieurs approches générales permettent de bénéficier d’une haute disponibilité dans l’ensemble des régions :

• Mode actif/passif avec serveur de secours : le trafic est dirigé vers une région, tandis que l’autre région est en attente sur le serveur de secours. Le serveur de secours signifie que l’instance App Service de la région secondaire est allouée et fonctionne en permanence.

• Mode actif/passif avec reprise progressive : le trafic est dirigé vers une région, tandis que l’autre région est en attente sur le centre de données de reprise progressive. La reprise progressive signifie que l’instance App Service de la région secondaire n’est pas allouée tant qu’elle n’est pas nécessaire pour le basculement. La mise en œuvre de cette approche se révèle moins coûteuse, mais nécessite davantage de temps en cas de défaillance.

• Mode actif/actif : les deux régions sont actives, et la charge de travail des demandes est équilibrée entre les régions. Si une région devient indisponible, elle est retirée de la rotation.

Cette référence est axée sur le mode actif/passif avec serveur de secours. Pour plus d’informations sur la conception de solutions qui utilisent les autres approches, consultez les approches d’application App Service multirégion pour la récupération d’urgence.

Cas d’usage potentiels

Ces cas d’usage peuvent tirer parti d’un déploiement sur plusieurs régions :

• Concevoir un plan de continuité d’activité et de reprise d’activité pour les applications métier.

• Déployer des applications stratégiques s’exécutant sur Windows ou Linux.

• Améliorer l’expérience utilisateur en gardant les applications disponibles.

Recommandations

Vos exigences peuvent différer de celles de l’architecture décrite ici. Utilisez les recommandations de cette section comme point de départ.

Association régionale

De nombreuses régions Azure sont associées à une autre région dans la même zone géographique. Certaines régions n’ont pas de région jumelée. Pour plus d’informations sur les régions jumelées, consultez l’article Continuité des activités et récupération d’urgence (BCDR) : régions jumelées d’Azure.

Si votre région primaire a une paire, envisagez d’utiliser la région jumelée comme région secondaire (par exemple, USA Est 2 et USA Centre). Cette approche offre les avantages suivants :

• En cas d’interruption de service générale, la récupération d’au moins une région de chaque paire est prioritaire.
• Les mises à jour planifiées du système Azure sont déployées dans les régions associées de manière séquentielle afin de minimiser les temps d’arrêt possibles.
• Dans la plupart des cas, les paires régionales appartiennent à la même zone géographique afin de répondre aux exigences en matière de résidence des données.

Si votre région primaire n’a pas de paire, tenez compte des facteurs suivants lors de la sélection d’une région secondaire :

• Réduisez la latence en sélectionnant des régions qui sont géographiquement proches de vos utilisateurs.
• Répondez aux exigences de résidence des données en sélectionnant des régions situées dans des zones géographiques dans lesquelles vous pouvez stocker et traiter des données.

Que vos régions soient jumelées ou non associées, assurez-vous que les deux régions prennent en charge tous les services Azure nécessaires pour votre application. Consultez Services par région.

Groupes de ressources

Envisagez de placer la région primaire, la région secondaire et Front Door dans des groupes de ressources distincts. Cette allocation vous permet de gérer les ressources déployées dans chaque région sous la forme d’une collection unique.

Applications App Service

Nous vous recommandons de créer l’application web et l’API web en tant qu’applications App Service distinctes. Vous pouvez ainsi les exécuter dans des plans App Service distincts et donc les mettre à l’échelle indépendamment l’une de l’autre. Si vous n’avez pas besoin de ce niveau de scalabilité dès le départ, vous pouvez déployer les applications sur le même plan et les déplacer ultérieurement dans des plans distincts si cela est nécessaire.

Configuration de Front Door

Routage. Front Door prend en charge plusieurs mécanismes de routage. Pour le scénario décrit dans cet article, utilisez le routage par priorité. Lorsque cette méthode de routage est configurée, Front Door envoie toutes les requêtes à la région primaire, sauf si le point de terminaison de cette région devient inaccessible. À ce moment-là, les requêtes basculent automatiquement vers la région secondaire. Définissez le pool d’origine avec différentes valeurs de priorité, 1 pour la région active et 2 (ou plus) pour la région de secours ou passive.

Sonde d’intégrité. Front Door utilise une sonde HTTPS pour superviser la disponibilité de chaque back-end. Cette sonde offre à Front Door un test de réussite/échec pour le basculement vers la région secondaire. Elle envoie une requête à un chemin d’URL spécifié. Si la sonde obtient une réponse autre que 200 dans le délai d’expiration imparti, elle échoue. Vous pouvez configurer la fréquence des sondes d’intégrité, le nombre d’échantillons requis pour l’évaluation et le nombre d’échantillons réussis requis pour que l’origine soit marquée comme saine. Si Front Door marque l’origine comme dégradée, il bascule sur l’autre origine. Pour plus d'informations, consultez Sondes d'intégrité.

Une bonne pratique consiste à créer un chemin d’accès à la sonde d’intégrité dans l’origine de votre application pour signaler l’intégrité globale de l’application. La sonde d'intégrité doit vérifier les dépendances critiques telles que les applications App Service, la file d'attente de stockage et SQL Database. Sinon, la sonde risque de signaler une origine intègre alors que des parties critiques de l’application sont défaillantes. En revanche, n’utilisez pas la sonde d’intégrité pour vérifier des services de priorité inférieure. Par exemple, si un service de messagerie tombe en panne, l’application peut basculer vers un second fournisseur ou simplement différer l’envoi des e-mails. Pour plus d'informations sur ce modèle de conception, consultez Modèle Supervision de point de terminaison d'intégrité.

La sécurisation des origines à partir d’Internet est un élément essentiel de l’implémentation d’une application accessible publiquement. Reportez-vous à Implémentation d’entrée réseau sécurisée pour en savoir plus sur les modèles de conception et d’implémentation recommandés par Microsoft pour sécuriser les communications d’entrée de votre application avec Front Door.

CDN. Utilisez la fonctionnalité CDN native de Front Door pour mettre en cache du contenu statique. L’avantage principal d’un CDN est qu’il réduit la latence pour l’utilisateur ; en effet, le contenu est mis en cache sur un serveur Edge de périphérie qui est géographiquement proche de l’utilisateur. CDN peut également réduire la charge qui pèse sur l’application, car ce trafic n’est pas géré par l’application. Front Door offre également une accélération de site dynamique, ce qui vous permet d’offrir une meilleure expérience utilisateur globale pour votre application web que celle qui serait disponible avec uniquement la mise en cache de contenu statique.

SQL Database

Utilisez la géoréplication active et les groupes de basculement automatique pour rendre vos bases de données résilientes. La géoréplication active vous permet de répliquer vos bases de données à partir de la région primaire dans une ou plusieurs (jusqu’à quatre) autres régions. Les groupes de basculement automatique s’appuient sur la géoréplication active en vous permettant de basculer vers une base de données secondaire sans modifier le code de vos applications. Les basculements peuvent être effectués manuellement ou automatiquement, selon les définitions de stratégie que vous créez. Pour utiliser des groupes de basculement automatique, vous devez configurer vos chaînes de connexion avec la chaîne de connexion de basculement créée automatiquement pour le groupe de basculement, plutôt que les chaînes de connexion des bases de données individuelles.

Azure Cosmos DB

Azure Cosmos DB prend en charge la géoréplication entre les régions en mode actif-actif avec plusieurs régions d'écriture. Vous pouvez également désigner une région en tant que région accessible en écriture et les autres régions en tant que réplicas en lecture seule. Dans l’éventualité d’une panne régionale, vous pouvez procéder à un basculement en désignant une autre région d’écriture. Le Kit de développement logiciel (SDK) client envoie automatiquement des requêtes d’écriture à la région accessible en écriture ; vous n’avez donc pas besoin de mettre à jour la configuration du client après un basculement. Pour plus d'informations, consultez Distribution de données globales avec Azure Cosmos DB.

Stockage

Pour le service Stockage Azure, utilisez un stockage géographiquement redondant avec accès en lecture (RA-GRS). Dans le cadre d’un stockage RA-GRS, les données sont répliquées vers une région secondaire. Vous disposez d’un accès en lecture seule aux données de la région secondaire par le biais d’un point de terminaison distinct. Le basculement initié par l’utilisateur vers la région secondaire est pris en charge pour les comptes de stockage géorépliqués. Le lancement d’un basculement de compte de stockage met automatiquement à jour les enregistrements DNS pour faire du compte de stockage secondaire le nouveau compte de stockage principal. Les basculements ne doivent être entrepris que lorsque cela est jugé nécessaire. Cette exigence est définie par le plan de récupération d’urgence de votre organisation. Vous devez aussi tenir compte des implications décrites dans la section Considérations ci-dessous.

En cas de panne régionale ou de sinistre, l’équipe Stockage Azure peut décider de procéder à un géobasculement vers la région secondaire. Pour ces types de basculements, aucune action n’est requise de la part du client. La restauration automatique vers la région primaire est également gérée par l’équipe de stockage Azure dans ces cas.

Dans certains cas, la réplication d’objet pour les objets blob de blocs est une solution de réplication suffisante pour votre charge de travail. Cette fonctionnalité de réplication vous permet de copier des objets blob de blocs individuels du compte de stockage principal dans un compte de stockage de votre région secondaire. L’avantage de cette approche est un contrôle granulaire sur les données qui sont répliquées. Vous pouvez définir une stratégie de réplication pour un contrôle plus granulaire des types d’objets blob de blocs répliqués. Voici quelques exemples de définitions de stratégie :

• Seuls les objets blob de blocs ajoutés après la création de la stratégie sont répliqués
• Seuls les objets blob de blocs ajoutés après une date et une heure données sont répliqués
• Seuls les objets blob de blocs correspondant à un préfixe donné sont répliqués.

Le stockage de file d’attente est référencé comme une option de messagerie alternative à Azure Service Bus pour ce scénario. Mais si vous utilisez le stockage de file d’attente pour votre solution de messagerie, les conseils ci-dessus sur la géoréplication s’appliquent ici car le stockage de file d’attente réside sur des comptes de stockage. Toutefois, il est important de comprendre que les messages ne sont pas répliqués dans la région secondaire et que leur état est inextricable de la région.

Azure Service Bus

Afin de bénéficier de la résilience la plus élevée offerte pour Azure Service Bus, utilisez le niveau Premium pour vos espaces de noms. Le niveau Premium utilise des zones de disponibilité, ce qui rend vos espaces de noms résilients aux pannes du centre de données. En cas de sinistre généralisé affectant plusieurs centres de données, la fonctionnalité de géo-reprise d’activité après sinistre incluse avec le niveau Premium peut vous aider à récupérer. La fonctionnalité de géo-reprise d’activité après sinistre garantit que la totalité de la configuration d’un espace de noms (files d’attente, rubriques, abonnements et filtres) est répliquée en continu d’un espace de noms principal vers un espace de noms secondaire quand ils sont couplés. Elle permet également de lancer à tout moment un basculement ponctuel vers l’espace de noms secondaire. L’action de basculement fait pointer le nom d’alias choisi pour l’espace de noms vers l’espace de noms secondaire, puis arrête le jumelage. Le basculement est presque instantané une fois lancé.

Azure AI Search

Dans la recherche IA, la disponibilité est obtenue via plusieurs réplicas, tandis que la continuité d’activité et la récupération d’urgence (BCDR) sont obtenues via plusieurs services de recherche.

Dans la recherche IA, les réplicas sont des copies de votre index. Le fait d’avoir plusieurs réplicas permet à Azure AI Search d’effectuer des redémarrages et une maintenance sur un réplica, tandis que l’exécution des requêtes se poursuit sur d’autres réplicas. Pour plus d’informations sur l’ajout de réplicas, consultez Ajouter ou enlever des réplicas et des partitions.

Vous pouvez utiliser Zones de disponibilité avec Azure AI Search en ajoutant deux réplicas ou plus à votre service de recherche. Chaque réplica sera placé dans une zone de disponibilité distincte au sein de la région.

Pour connaître les considérations relatives à la continuité d’activité et reprise d’activité, reportez-vous à la documentation Plusieurs services dans des régions géographiques distinctes.

Cache Azure pour Redis

Bien que tous les niveaux de Azure Cache pour Redis offrent une réplication Standard pour une haute disponibilité, le niveau Premium ou Enterprise est recommandé pour fournir un niveau de résilience et de récupération plus élevé. Passez en revue Haute disponibilité et récupération d’urgence pour obtenir la liste complète des fonctionnalités et options de résilience et de récupération pour ces niveaux. Vos besoins métier déterminent le niveau le mieux adapté à votre infrastructure.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité. Tenez compte des points suivants lors de la conception d'une haute disponibilité dans les différentes régions.

Azure Front Door

Azure Front Door procède à un basculement automatique si la région primaire devient indisponible. Quand Front Door déclenche un basculement, l’application est inaccessible aux clients pendant un certain temps (généralement entre 20 et 60 secondes). Ce laps de temps dépend des facteurs suivants :

• Fréquence des sondes d'intégrité. Plus les envois de sondes d’intégrité sont fréquents, plus vite Front Door peut détecter les temps d’arrêt ou le retour à un état sain de l’origine.
• Configuration de la taille de l'échantillon. Cette configuration permet de contrôler le nombre d’échantillons nécessaires à la sonde d’intégrité pour détecter que l’origine est devenue inaccessible. Si cette valeur est trop faible, des problèmes intermittents peuvent provoquer des faux positifs.

Front Door est un point de défaillance possible dans le système. Si le service échoue, les clients ne peuvent pas accéder à votre application pendant le temps d’arrêt. Passez en revue le Contrat de niveau de service (SLA) pour Front Door et déterminez si Front Door peut à lui seul répondre à vos besoins métier en haute disponibilité. Si tel n’est pas le cas, pensez à ajouter une autre solution de gestion du trafic en guise de procédure de secours. Si le service Front Door échoue, changez vos enregistrements de nom canonique (CNAME) dans DNS pour pointer vers l’autre service de gestion du trafic. Cette opération doit être effectuée manuellement, et votre application reste inaccessible tant que ces modifications DNS n’ont pas été propagées.

Les niveaux Azure Front Door Standard et Premium combinent les fonctionnalités d’Azure Front Door (classique), d’Azure CDN Standard de Microsoft (classique) et d’Azure WAF dans une seule plateforme. L’utilisation d’Azure Front Door Standard ou Premium réduit les points de défaillance et active un contrôle, une surveillance et une sécurité améliorés. Pour plus d’informations, consultez Vue d’ensemble du niveau d’Azure Front Door.

Base de données SQL

L’objectif de point de récupération (RPO) et l’objectif de délai de récupération estimé (RTO) de SQL Database sont décrits dans Vue d’ensemble de la continuité d’activité avec Azure SQL Database.

N’oubliez pas que la géoréplication active double de fait le coût de chaque base de données répliquée. Les bases de données de bac à sable, de test et de développement ne sont généralement pas recommandées pour la réplication.

Azure Cosmos DB

Pour Azure Cosmos DB, l'objectif de point de récupération (RPO) et l'objectif de délai de récupération (RTO) sont configurables via les niveaux de cohérence utilisés, qui permettent de faire des compromis entre la disponibilité, la durabilité des données et le débit. Azure Cosmos DB fournit un RTO minimum de 0 pour un niveau de cohérence souple multimaître, ou un RPO de 0 pour une cohérence forte avec un seul maître. Pour en savoir plus sur les niveaux de cohérence d’Azure Cosmos DB, consultez Niveaux de cohérence et durabilité des données dans Azure Cosmos DB.

Stockage

Le stockage géo-redondant avec accès en lecture fournit un stockage durable, mais il est important de prendre en compte les facteurs suivants lorsque vous envisagez d’effectuer un basculement :

• Anticiper la perte de données : La réplication des données vers la région secondaire est effectuée de manière asynchrone. Par conséquent, en cas de géobasculement, attendez-vous à une perte de données si les modifications apportées au compte principal n’ont pas été entièrement synchronisées avec le compte secondaire. Vous pouvez vérifier la propriété Heure de la dernière synchronisation du compte de stockage secondaire pour voir la dernière fois que les données de la région primaire ont été écrites avec succès dans la région secondaire.

• Planifiez votre objectif de délai de récupération (RTO) en conséquence : En général, le basculement vers la région secondaire prend environ une heure. Votre plan de reprise d’activité doit donc en tenir compte lors du calcul de vos paramètres de RTO.

• Planifiez soigneusement la restauration automatique : Il est important de comprendre que lorsqu’un compte de stockage bascule, les données du compte principal d’origine sont perdues. Il est donc risqué de tenter une restauration automatique vers la région primaire sans planification minutieuse. Une fois le basculement terminé, le nouveau serveur principal (dans la région de basculement) est configuré pour le stockage localement redondant (LRS). Vous devez le reconfigurer manuellement en tant que stockage géorépliqué pour lancer la réplication vers la région primaire, puis laisser suffisamment de temps pour permettre la synchronisation des comptes.

• Les défaillances passagères, telles qu’une indisponibilité du réseau, n’entraînent pas un basculement du stockage. Concevez votre application de façon à la rendre résistante aux défaillances passagères. Les options d'atténuation sont les suivantes :

  • lecture à partir de la région secondaire ;
  • basculement temporaire vers un autre compte de stockage pour les nouvelles opérations d’écriture (par exemple, pour la mise en file d’attente des messages) ;
  • copie des données de la région secondaire vers un autre compte de stockage ;
  • fourniture de fonctionnalités réduites jusqu’à la restauration automatique du système.

Pour plus d’informations, consultez Que faire en cas de panne du stockage Azure.

Pour connaître les considérations relatives à l’utilisation de la réplication d’objet pour les objets blob de blocs, reportez-vous aux prérequis et mises en garde concernant la réplication d’objets.

Azure Service Bus

Il est important de comprendre que la fonctionnalité de géo-reprise d’activité après sinistre incluse dans le niveau Azure Service Bus Premium permet une continuité instantanée des opérations avec la même configuration. Toutefois, elle ne réplique pas les messages conservés dans les files d’attente, les abonnements aux rubriques ou les files d’attente de lettres mortes. Par conséquent, une stratégie d’atténuation est nécessaire pour garantir un basculement sans heurts vers la région secondaire. Pour obtenir une description détaillée des autres considérations et stratégies d’atténuation, reportez-vous aux points importants à prendre en compte et à la documentation sur les considérations relatives à la récupération d’urgence.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Restreindre le trafic entrant Configurez l'application pour qu'elle accepte uniquement le trafic en provenance de Front Door. Tout le trafic passera ainsi par le pare-feu d'applications web avant d'atteindre l'application. Pour plus d'informations, consultez Comment faire pour restreindre l'accès à mon back-end uniquement à Azure Front Door ?

Partage des ressources Cross-Origin (CORS) Si vous créez un site web et une API en tant qu’applications distinctes, le site web ne peut pas effectuer d’appels AJAX côté client à l’API, sauf si vous activez CORS.

App Services prend en charge CORS, sans que vous ayez besoin d’écrire un code d’application. Consultez Consommer une application API à partir de JavaScript à l'aide de CORS. Ajoutez le site web à la liste des origines autorisées pour l’API.

Chiffrement des bases de données SQLUtilisez Transparent Data Encryption si vous avez besoin de chiffrer les données au repos dans la base de données. Cette fonctionnalité effectue le chiffrement et le déchiffrement en temps réel d’une base de données entière (y compris les sauvegardes et les fichiers journaux des transactions) et ne nécessite aucune modification de l’application. Le chiffrement étant source de latence, il est judicieux de placer les données à sécuriser dans leur propre base de données et d’activer le chiffrement uniquement pour cette base de données.

Identité Quand vous définissez des identités pour les composants de cette architecture, utilisez des identités managées par le système dans la mesure du possible afin de réduire votre besoin de gérer les informations d’identification et les risques inhérents à leur gestion. S’il n’est pas possible d’utiliser des identités managées par le système, vérifiez que chaque identité managée par l’utilisateur existe dans une seule région et qu’elle n’est jamais partagée au-delà des limites de la région.

Pare-feux de service Lors de la configuration des pare-feux de service pour les composants, vérifiez que seuls les services locaux de la région ont accès aux services et que les services autorisent seulement des connexions sortantes, ce qui est explicitement nécessaire pour la réplication et la fonctionnalité de l’application. Envisagez d’utiliser Azure Private Link pour améliorer le contrôle et la segmentation. Pour plus d'informations sur la sécurisation des applications Web, consultez Application Web de base hautement disponible et redondante en zone.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Mise en cache Utilisez la mise en cache pour réduire la charge sur les serveurs traitant du contenu qui ne change pas fréquemment. Chaque cycle de rendu d'une page peut avoir un impact sur les coûts car il consomme des ressources en termes de calcul, de mémoire et de bande passante. Ces coûts peuvent être significativement réduits grâce à la mise en cache, en particulier pour les services de contenu statique, comme les applications JavaScript à page unique et le contenu multimédia en streaming.

Si votre application dispose de contenu statique, utilisez CDN pour réduire la charge sur les serveurs frontaux. Pour les données qui ne changent pas fréquemment, utilisez Azure Cache pour Redis.

ÉtatLes applications sans état configurées pour la mise à l’échelle automatique sont plus économiques que les applications avec état. Pour une application ASP.NET qui utilise l’état de session, stockez-le en mémoire avec Azure Cache pour Redis. Pour plus d'informations, consultez Fournisseur d'état de session ASP.NET pour Azure Cache pour Redis. Une autre option consiste à utiliser Azure Cosmos DB en tant que magasin d'état back-end via un fournisseur d'état de session. Consultez Utiliser Azure Cosmos DB comme fournisseur d’état de session et de mise en cache ASP.NET.

Fonctions Envisagez de placer une application de fonction dans un plan App Service dédié afin que les tâches situées en arrière-plan ne s'exécutent pas sur les instances qui gèrent les requêtes HTTP. Si les tâches situées en arrière-plan s’exécutent par intermittence, envisagez d’utiliser un plan de consommation facturé en fonction du nombre d’exécutions et de ressources utilisées, et non du nombre d’heures.

Pour plus d'informations, consultez la section Coûts de Microsoft Azure Well-Architected Framework.

Utilisez la calculatrice de prix pour estimer les coûts. Les recommandations fournies dans cette section peuvent vous aider à réduire les coûts.

Azure Front Door

Trois niveaux tarifaires sont disponibles pour Azure Front Door : Transferts de données sortants, Transferts de données entrants et Règles d'acheminement. Pour plus d'informations, consultez Tarification d'Azure Front Door. Le tableau des prix n’inclut pas le coût d’accès aux données des services d’origine et le coût de transfert vers Front Door. Ces coûts sont facturés sur la base des frais de transfert de données décrits dans Détails sur les tarifs de bande passante.

Azure Cosmos DB

La tarification d'Azure Cosmos DB repose sur deux facteurs :

• le débit approvisionné ou les unités de requête par seconde (RU/s).

  Deux types de débit peuvent être approvisionnés dans Azure Cosmos DB : standard et mise à l'échelle automatique. Le débit standard alloue les ressources nécessaires pour garantir les RU/s que vous spécifiez. Pour la mise à l'échelle automatique, vous approvisionnez le débit maximum, et Azure Cosmos DB s'adapte instantanément à la charge, avec un minimum de 10 % du débit maximum de la mise à l'échelle automatique. Le débit standard est facturé en fonction du débit approvisionné par heure. Le débit de mise à l'échelle automatique est facturé en fonction du débit maximum consommé par heure.

• Stockage consommé. Un tarif fixe vous est facturé pour la quantité totale de stockage (Go) utilisée pour les données et les index pendant une heure donnée.

Pour plus d’informations, consultez la section sur les coûts dans Microsoft Azure Well-Architected Framework.

Efficacité des performances

Le principal avantage de Azure App Service est la possibilité de mettre à l’échelle votre application en fonction de la charge. Voici quelques considérations à prendre en compte pendant la planification de la mise à l’échelle de votre application.

application App Service

Si votre solution inclut plusieurs applications App Service, envisagez de les déployer sur des plans App Service distincts. Cette approche vous permet de les mettre à l’échelle indépendamment, car elles s’exécutent sur des instances distinctes.

SQL Database

Augmentez la scalabilité d’une base de données SQL en partitionnant celle-ci. Le partitionnement fait référence au partitionnement horizontal de la base de données. Le partitionnement vous permet d'effectuer un scale-out horizontal de la base de données à l'aide d'outils de base de données élastique. Les avantages du partitionnement peuvent être les suivants :

• Meilleur débit de transactions.
• Les requêtes peuvent s’exécuter plus rapidement sur un sous-ensemble des données.

Azure Front Door

Front Door peut effectuer un déchargement SSL ; d'autre part, il réduit le nombre total de connexions TCP grâce à l'application web back-end. La scalabilité est ainsi améliorée car l'application web gère un plus petit volume de négociations SSL et de connexions TCP. Ces gains de performances s'appliquent même si vous transférez les requêtes à l'application web en HTTPS, en raison du haut niveau de réutilisation des connexions.

Recherche Azure

Recherche Azure supprime la surcharge liées aux recherches de données complexes à partir du magasin de données principal, et peut évoluer pour gérer la charge. Consultez Mettre à l'échelle les niveaux de ressources pour interroger et indexer les charges de travail dans Recherche Azure.

Excellence opérationnelle

L’excellence opérationnelle fait référence aux processus opérationnels qui déploient une application et la maintiennent en cours d’exécution en production. Il s’agit d’une extension des conseils de fiabilité de Well-Architected Framework. Ce guide fournit une vue d’ensemble détaillée de l’architecture de la résilience dans votre infrastructure d’application pour vous assurer que vos charges de travail sont disponibles et peuvent récupérer après des défaillances à n’importe quelle échelle. L’un des principes fondamentaux de cette approche consiste à concevoir votre infrastructure d’application pour qu’elle soit hautement disponible, de manière optimale dans plusieurs régions géographiques, comme l’illustre cette conception.

Étapes suivantes

• Explorer en détail Azure Front Door - Méthodes de routage du trafic

• Créer des sondes d’intégrité qui signalent l’intégrité globale de l’application en fonction des modèles de monitoring des points de terminaison

• Activer les groupes de basculement automatique Azure SQL

• Assurer la continuité des activités et la récupération d’urgence à l’aide des régions jumelées Azure

Ressources associées

• Application multiniveau multirégion est un scénario similaire. Il montre une application multiniveau s’exécutant dans plusieurs régions Azure

• Principes de conception pour les applications Azure