Concevoir une architecture d’application distribuée géographiquement
Quand nos composants réseau routent les demandes vers plusieurs régions pour atténuer les effets d’une panne régionale, nous devons concevoir des services d’application qui peuvent répondre à ces demandes dans les régions principale et de secours.
Rappelez-vous que nous prévoyons de configurer Azure Front Door avec l’affectation de back-ends par priorité. Nous attribuons la région USA Est comme région primaire et la région USA Ouest comme région de secours. En cas de défaillance régionale, les demandes sont routées vers le service d’application dans la région non défaillante. Nous devons configurer des ressources dans chaque région afin de prendre en charge ces basculements pour l’accès utilisateur, le stockage répliqué et le code d’application.
Ici, nous examinons les services d’application de notre solution et déterminons s’ils doivent être modifiés pour fonctionner dans une architecture multirégion. Plus précisément, nous examinons Active Directory, le stockage de contenu statique, les applications web, les API web, les files d’attente, les fonctions Azure et les caches de données.
Microsoft Entra ID
Dans notre portail de suivi des expéditions, les utilisateurs peuvent effectuer le suivi de la livraison de leurs achats en entrant un numéro de suivi. Toutefois, les utilisateurs standard peuvent s’inscrire pour accéder à des fonctionnalités avancées, telles que la rapidité de la livraison et autres statistiques. Nous avons développé le portail de suivi pour stocker les comptes d’utilisateur dans Microsoft Entra ID.
Microsoft Entra ID est conçu comme un système mondial par défaut. En tant que tel, il n’est pas vulnérable aux défaillances régionales et nous n’avons pas besoin de modifier ce composant du système.
Stockage Blob Azure
Le contenu statique, tel que les images et les vidéos, est stocké dans des comptes Stockage Azure sous la forme d’objets blob (Binary Large Objects) et fourni aux utilisateurs par le biais d’Azure CDN.
Dans notre conception d’origine, le compte de stockage est contenu dans une seule région, car nous avons choisi d’utiliser le stockage localement redondant (LRS). Nos données sont répliquées uniquement dans un seul centre de données avec LRS. Ainsi, le compte de stockage n’est pas disponible en cas de panne régionale dans cette configuration. Tout contenu statique qui a déjà été mis en cache par le CDN reste disponible pour les utilisateurs.
Il en va de même pour le stockage redondant interzone (ZRS). Même si les données sont répliquées vers différents centres de données dans cette configuration, tous ces centres de données se trouvent toujours dans la même région. Une panne régionale affecte également le compte de stockage dans cette configuration.
Dans notre conception, nous nous appuyons fortement sur notre configuration CDN pour mettre en cache le contenu statique. En cas de panne, il est possible qu’un utilisateur demande un fichier statique qui ne se trouve pas encore dans le cache CDN. Cette demande se traduirait par l’impossibilité d’afficher un graphisme ou une vidéo.
Nous pouvons éliminer cette possibilité en répliquant le compte de stockage dans plusieurs régions quand nous choisissons une option de stockage géoredondant. Une option de réplication en lecture seule est également disponible pour empêcher l’ajout de contenu statique pendant une panne régionale.
Nous avons le choix entre deux options quand nous devons activer la géoredondance. Ces options sont le stockage géoredondant avec accès en lecture (RA-GRS) et le stockage géoredondant interzone avec accès en lecture (RA-GZRS). Le choix que nous faisons dépend de notre budget et du pourcentage de durée de bon fonctionnement dont nous avons besoin.
Azure App Service et applications de fonctions Azure
Notre portail de suivi des expéditions met en œuvre deux services d’application Azure. Le premier service d’application héberge une application web qui implémente l’interface web orientée utilisateur, tandis que le second héberge une API web utilisée par les applications mobiles pour suivre les données d’expédition. Toutes nos tâches en arrière-plan s’exécutent en tant qu’applications de fonctions Azure.
Dans notre conception d’origine, chaque service d’application Azure se trouve dans une seule région Azure. Nous créons un deuxième service d’application dans la région secondaire (USA Ouest) et y déployons le projet web pour prendre en charge la nouvelle architecture multirégion. Nous configurons le mode de routage par priorité d’Azure Front Door pour envoyer les demandes à notre région secondaire quand la région primaire n’est pas disponible.
Pour garantir un basculement aussi fluide que possible, assurez-vous que l’application web ne stocke pas d’informations d’état de session en mémoire. Nous modifions notre site web pour éviter une perte de données. Par exemple, si notre code stocke une liste des expéditions des utilisateurs en mémoire, cette liste est perdue en cas de basculement.
Chaque demande web est gérée sans affecter l’autre quand aucun état de session n’est stocké. Si un basculement se produit au milieu d’une session utilisateur, il doit être transparent pour l’utilisateur.
Nous apportons une modification similaire à nos applications de fonctions Azure. Nous créons une instance distincte de la fonction Azure dans la région secondaire et y déployons le même code personnalisé que celui qui s’exécute dans la région primaire.
Important
Quand vous déployez une mise à jour du code personnalisé dans le service d’application ou d’application de fonction, n’oubliez pas de la distribuer à toutes les instances du service d’application. Si vous souhaitez automatiser ce processus, Azure DevOps propose des outils qui peuvent vous aider.
Files d’attente Stockage Azure
Dans notre architecture monorégion d’origine, nous avons utilisé une file d’attente dans un compte Stockage Azure pour gérer les communications entre le service d’application et l’application de fonction. Quand l’application web ou l’API web doit exécuter une tâche en arrière-plan, elle place un message contenant toutes les informations requises dans la file d’attente. L’application de fonction supervise la file d’attente à la recherche de nouveaux messages et exécute la tâche en arrière-plan en exécutant les requêtes nécessaires sur les magasins de données.
Nous pouvons gérer une demande élevée de requêtes web de façon ordonnée quand nous utilisons une file d’attente de cette manière. Quand il y a de nombreuses tâches en arrière-plan à exécuter, la file d’attente peut croître, mais les tâches ne sont pas supprimées. Elles restent dans la file d’attente jusqu’à ce qu’elles soient traitées. Les applications de fonctions traitent la file d’attente et réduisent sa taille quand la demande tombe. Si la demande persiste, nous augmentons le nombre d’instances de l’application de fonction.
Pour la version multirégion du portail de suivi des expéditions, nous devons nous assurer que les éléments de la file d’attente ne sont pas perdus en cas de basculement. Notre file d’attente est définie dans Stockage Azure et nous pouvons utiliser une option de redondance pour la géoréplication.
Gardez à l’esprit que nous ne pouvons pas utiliser une option de redondance avec accès en lecture, car notre file d’attente prend en charge les opérations de lecture et d’écriture. Le service d’application doit ajouter des éléments à la file d’attente, et l’application de fonction doit en supprimer les éléments terminés. Utilisez à la place le stockage géoredondant (GRS) ou le stockage géoredondant interzone (GZRS).
Cache Redis Azure
Nous utilisons le cache Redis Azure pour optimiser les performances du stockage de données. Redis met en cache tous les résultats de requête générés à partir de nos applications quand elles demandent des données à notre base de données. Les requêtes suivantes pour des données similaires n’ont pas besoin d’une requête de base de données et sont extraites du cache Redis.
Pour l’architecture multirégion, nous créons une instance du cache Redis dans les régions primaire et de secours. Gardez à l’esprit que quand un basculement se produit, le cache Redis dans la région de secours est susceptible d’être vide. Ce cache vide ne provoque pas d’erreurs, mais les performances peuvent provisoirement diminuer, car les données remplissent le nouveau cache.