Concevoir une architecture distribuée géographiquement
Azure est un système mondial. En concevant une architecture qui est présente dans plusieurs régions Azure, nous pouvons créer une application qui résiste aux sinistres même s’ils s’étendent à toute une région.
Votre portail de suivi des expéditions est scalable, car il est conçu à l’aide d’une gamme de ressources Azure qui peuvent être mises à l’échelle. Il est également résilient à un grand nombre de défaillances car ses composants peuvent avoir plusieurs instances. Toutefois, votre conseil d’administration est préoccupé par le fait qu’un sinistre à grande échelle pourrait entraîner une interruption, car le portail se trouve entièrement dans la région Azure USA Est. Vous souhaitez proposer une architecture modifiée pouvant basculer vers une autre région en cas de défaillance de la région USA Est.
Ici, nous apprenons à ajuster l’architecture de notre application afin qu’elle prenne en charge une application distribuée géographiquement. Nous voyons également pourquoi cette architecture est avantageuse pour les applications critiques pour l’entreprise.
Architecture d’application web d’origine
Examinons la conception architecturale du portail de suivi et les composants utilisés dans la solution. Après avoir compris l’utilisation de tous les éléments, nous pouvons examiner la prise en charge de chacun de ces composants dans des scénarios de géoredondance.
La conception du portail de suivi repose sur l’architecture de référence illustrée dans le diagramme suivant.
Notez que notre application utilise un seul groupe de ressources Azure. Ce groupe de ressources nous permet de regrouper et de manager toutes nos ressources de manière logique, et il simplifie la gestion. Nous avons choisi de déployer ce groupe de ressources dans la région USA Est. Même si le groupe de ressources ne nous contraint pas à utiliser la même région Azure pour les ressources incluses, nous avons décidé d’utiliser la région USA Est pour toutes les ressources déployées dans notre application.
Notre application utilise trois catégories de ressources Azure. Examinons chaque catégorie et voyons quelles ressources sont en cours d’utilisation.
Composants réseau
Le portail de suivi utilise les services de mise en réseau suivants.
| Service | Description |
|---|---|
| Azure DNS | Nous avons configuré Azure DNS pour héberger nos enregistrements DNS dans Azure. Azure DNS nous permet de manager nos enregistrements DNS avec nos informations d’identification Azure dans le portail Azure. |
| Application Gateway | Nous avons configuré l’équilibreur de charge Application Gateway pour équilibrer le trafic entre plusieurs instances du front-end web. Ce service est localisé dans une région Azure. |
| Azure CDN | Nous avons configuré Azure CDN pour optimiser la distribution du contenu statique non sécurisé, tel que le graphisme du contenu de notre site web. Ce service mondial met en cache du contenu statique à des points de présence disséminés partout dans le monde. |
Composants d’application
Le portail de suivi utilise les services suivants pour prendre en charge les exigences liées au code, au cache et au stockage intermédiaire.
| Service | Description |
|---|---|
| Microsoft Entra ID | Les utilisateurs accèdent au portail de suivi avec des comptes Microsoft Entra. L’annuaire et le compte sont automatiquement répliqués dans le monde entier. |
| Azure App Service | Le portail de suivi utilise deux services d’application Azure. Le premier exécute un ensemble de pages web dynamiques, et le second une API web. |
| Applications de fonctions Azure | Le portail de suivi utilise des applications de fonctions Azure pour exécuter toutes les tâches en arrière-plan. Certaines de ces tâches s’exécutent selon une planification régulière, tandis que d’autres opèrent sur les messages placés dans une file d’attente. |
| Files d’attente Stockage Azure | Le portail de suivi utilise des files d’attente Stockage Azure avec les applications de fonctions Azure. Le portail de suivi place les messages générés dans la file d’attente, à partir de laquelle les applications de fonctions traitent ces messages. |
| Cache Redis | Le portail de suivi utilise un cache Redis entre le service d’application front-end et les systèmes de stockage de données pour optimiser les performances des requêtes. |
| Stockage Blob Azure | Le contenu statique, tel que les fichiers graphiques et vidéo, est conservé sous forme d’objets blob (Binary Large Objects) dans un compte Stockage Azure et est remis via Azure CDN. |
| Recherche Azure | Nous avons activé Recherche Azure sur le portail de suivi. La Recherche Azure nous permet d’effectuer des recherches dans tout le contenu et de fournir des suggestions de recherche et des résultats de recherche approximative à nos utilisateurs. |
Composants de stockage de données
Le portail de suivi utilise les services de stockage persistant suivants.
| Service | Description |
|---|---|
| Azure SQL Database | Nous stockons les données relationnelles, telles que les détails des commandes et des clients, dans Azure SQL Database. |
| Cosmos DB | Nous stockons les données semi-structurées, y compris notre catalogue de produits, dans Cosmos DB. |
Problèmes liés à l’architecture d’origine
L’architecture existante du portail de suivi est conçue pour permettre la scalabilité et la disponibilité.
Par exemple, si la demande est élevée et que les réponses aux demandes web des utilisateurs sont lentes, vous pouvez envisager d’ajouter d’autres instances de l’application web front-end dans le service d’application. Ici, la passerelle d’application peut router les demandes vers ces instances créées.
Toutefois, il existe des scénarios dans lesquels notre conception architecturale est susceptible de rencontrer des difficultés, voire d’échouer. Examinons chaque scénario afin d’avoir une meilleure compréhension de l’impact sur le portail de suivi.
Défaillances régionales
Certains événements significatifs ont le potentiel d’interrompre l’intégralité d’une région Azure. Les centres de données Azure sont conçus pour être hautement résilients, mais un événement météorologique grave, comme un ouragan ou une inondation, peut perturber le service de la région.
Ces événements sont des occurrences inhabituelles, et de nombreuses entreprises estiment qu’elles peuvent supporter ce risque. Toutefois, la désactivation du portail de suivi à la suite d’une défaillance régionale est un risque tellement élevé que l’équipe dirigeante de l’entreprise a décidé de l’éliminer.
Contrats de niveau de service
La plupart des services Azure offrent un Contrat de niveau de service (SLA) ou une garantie de temps d’activité. Quand nous concevons une architecture d’application composée de plusieurs services Azure, nous calculons le SLA global pour l’application sous la forme d’un composite de tous les SLA des services.
Vous calculez ce SLA en multipliant les SLA des services de composants. Par exemple, supposons que notre application se compose d’Azure App Service (SLA de 99,95 %) et de Microsoft Entra ID (SLA de 99,9 %). Le SLA final calculé est de 99,85 %.
Si ce pourcentage de temps d’activité n’est pas suffisant pour notre application, nous pouvons faire en sorte que celle-ci bascule vers une autre région.
Composants mondiaux, régionaux et configurables
Dans notre conception, certains composants sont mondiaux par défaut et ne sont pas vulnérables à une défaillance régionale.
Certains composants sont confinés dans une seule région, par exemple, la passerelle d’application. Nous devons sélectionner un autre service pour ces types de composants.
Certains composants peuvent être configurés pour prendre en charge plusieurs régions. Par exemple, nous pouvons utiliser l’option Stockage géoredondant (GRS) dans le compte Stockage Azure qui stocke le contenu statique. GRS réplique les objets blob dans une autre région.
Le tableau suivant indique quels composants sont mondiaux, régionaux et configurables.
| Composant | Prise en charge de plusieurs régions | Commentaires |
|---|---|---|
| Azure DNS | Mondiale | Aucune modification n’est nécessaire. |
| Application Gateway | Régionale | Chaque instance d’Application Gateway se trouve dans une seule région. |
| Azure CDN | Mondiale | Aucune modification n’est nécessaire, et le contenu est mis en cache à l’échelle mondiale par défaut. |
| Microsoft Entra ID | Global | Aucune modification n’est nécessaire. |
| Azure App Service | Régionale | Chaque instance de l’application se trouve dans une seule région. |
| Applications de fonctions Azure | Régionale | Chaque instance de l’application de fonction se trouve dans une seule région. |
| Files d’attente Stockage Azure | Configurable | Vous pouvez choisir de répliquer un compte Stockage Azure dans plusieurs régions. |
| Cache Redis Azure | Régionale | Chaque instance du cache se trouve dans une seule région. |
| Stockage Blob Azure | Configurable | Vous pouvez choisir de répliquer un compte Stockage Azure dans plusieurs régions. |
| Recherche Azure | Régionale | Chaque instance du service de recherche se trouve dans une seule région. |
| Azure SQL Database | Configurable | Vous pouvez utiliser la géoréplication pour synchroniser les données dans plusieurs régions. |
| Azure Cosmos DB | Configurable | Vous pouvez utiliser la géoréplication pour synchroniser les données dans plusieurs régions. |
Architecture distribuée proposée
Après investigation, vous proposez l’architecture illustrée dans le diagramme suivant.
Dans cette conception, il existe une région active (USA Est) et une région de secours (USA Ouest). La région USA Est gère toutes les demandes des composants dans des circonstances ordinaires. Si un sinistre provoque une défaillance régionale, l’application bascule sur la région USA Ouest.
Examinons, à un niveau général, la façon dont vous avez modifié l’architecture d’origine. Nous explorons ces modifications plus en détail dans les unités ultérieures.
Réseau
Azure DNS et Azure CDN étant par défaut des systèmes mondiaux, ils sont déjà résilients aux défaillances régionales. Nous les laissons en place.
Quand nous créons une passerelle d’application Azure, nous attribuons le service à une seule région. Nous éliminons cette vulnérabilité en remplaçant ce service par Azure Front Door. Front Door peut interroger plusieurs services d’application et gérer le basculement d’App Service de la région USA Est vers la région USA Ouest.
Services d’application
Microsoft Entra ID est un système mondial et ne nécessite aucune modification.
Les comptes Stockage Azure peuvent être configurés pour répliquer le contenu dans plusieurs régions. Nous utilisons l’une des options de stockage géoredondant pour changer notre configuration.
Les autres composants, y compris le service d’application, les applications de fonctions, le cache Redis et Recherche Azure, sont régionaux. Nous créons des instances dupliquées de ces composants dans la région USA Ouest au sein de notre nouvelle conception architecturale. Dans cette conception, la nouvelle région peut prendre le relais quand un basculement se produit.
Stockage des données
Azure SQL Database et Azure Cosmos DB prennent en charge la géoréplication des données dans d’autres régions. Nous configurons ces services de façon à répliquer les données de la région USA Est vers les services équivalents dans la région USA Ouest.
Paires régionales
Une région Azure est une zone avec une seule zone géographique qui contient un ou plusieurs centres de données Azure. Toutes les régions sont associées aux autres régions dans la même zone géographique. Au sein de ces paires, les mises à jour et la maintenance planifiée sont effectuées sur une seule région à la fois. En cas de défaillance affectant plusieurs régions, au moins une région dans chaque paire est prioritaire pour une récupération rapide.
La bonne pratique consiste à placer une architecture à deux régions pour votre application sur les deux régions dans une paire régionale. Par exemple, la région USA Est est associée à la région USA Ouest. La conception que nous proposons utilise USA Est pour sa région active et USA Ouest pour sa région de secours.