Concevoir une architecture d’application distribuée géographiquement
- 8 minutes
Lorsque nos composants réseau acheminent les demandes vers plusieurs régions pour atténuer les effets d’une panne régionale, nous devons concevoir des services d’application capables de répondre à ces demandes dans les régions principales et de secours.
Comme mentionné précédemment, nous prévoyons de configurer Azure Front Door avec une affectation de back-end prioritaire. Nous affectons la région USA Est comme région principale et la région USA Ouest comme région de secours. Lorsqu’une défaillance régionale se produit, les requêtes sont acheminées vers le service d’application dans la région fonctionnelle. Nous devons configurer des ressources dans chaque région pour prendre en charge ces basculements pour l’accès utilisateur, le stockage répliqué et le code d’application.
Icis, nous examinons les services d’application dans 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 (système d'identification de Microsoft)
Dans notre portail de suivi des expéditions, les utilisateurs peuvent suivre la livraison de leurs achats en entrant un numéro de suivi. Toutefois, les utilisateurs réguliers peuvent s'inscrire pour devenir membres afin d'accéder à des fonctionnalités avancées, telles que la rapidité de livraison et d'autres statistiques. Nous avons développé le portail de suivi pour stocker des comptes d’utilisateur dans Microsoft Entra ID.
Microsoft Entra ID est conçu comme un système global par défaut. Par conséquent, il n’est pas vulnérable aux défaillances régionales et nous n’avons pas à modifier ce composant du système.
Stockage de Blobs Azure
Le contenu statique, tel que les images et les vidéos, est stocké dans des comptes de stockage Azure en tant qu’objets blob binaires et servis aux utilisateurs via le CDN Azure.
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. Par conséquent, le compte de stockage n’est pas disponible s’il existe une panne régionale dans cette configuration. Tout contenu statique déjà 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 du contenu statique. Il est possible qu’au cours d’une panne, un utilisateur puisse demander un fichier statique qui n’est pas encore dans le cache CDN. Cette demande entraînerait un graphique ou une vidéo qui ne peut pas être affiché.
Nous pouvons éliminer cette possibilité en répliquant le compte de stockage dans plusieurs régions lorsque nous choisissons une option de stockage géoredondante. Une option de réplication en lecture seule est également disponible pour empêcher l’ajout de contenu statique lors d’une panne régionale.
Nous avons deux options à choisir lorsque 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 temps d’attente dont nous avons besoin.
Azure App Service et Azure Function Apps
Notre portail de suivi des expéditions implémente deux services Azure App Services. Le premier App Service héberge une application web qui implémente l’interface web orientée utilisateur, et la deuxième 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 Azure Function.
Dans notre conception d’origine, chaque Azure App Service est localisé dans une seule région Azure. Nous créons un deuxième App Service dans la région secondaire (USA Ouest) et déployons le projet web là-bas pour prendre en charge la nouvelle architecture multirégion. Nous configurons le mode de routage de priorité Azure Front Door pour envoyer des demandes à notre région secondaire lorsque la région primaire n’est pas disponible.
Pour vous assurer que le basculement est 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 nous assurer que nous ne sommes pas confrontés à 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 si un basculement s’est produit.
Chaque requête web est gérée sans avoir d’impact sur l’autre lorsqu’aucun état de session n’est stocké. Si un basculement se produit au milieu de la session d’un utilisateur, le basculement doit être transparent pour l’utilisateur.
Nous apporterons une modification similaire à nos applications Azure Function. Nous créons une instance distincte de la fonction Azure dans la région secondaire et y déployons le même code personnalisé qui s'exécute dans la région primaire.
Important
Lorsque vous déployez une mise à jour vers le code personnalisé dans App Service ou Function App Service, n’oubliez pas de le distribuer à toutes les instances d’App Service. Si vous souhaitez automatiser ce processus, Azure DevOps dispose d’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 de stockage Azure pour gérer les communications entre App Service et l’application de fonction. Lorsque l’application web ou l’API web doit exécuter une tâche en arrière-plan, elle place un message avec toutes les informations requises dans la file d’attente. L’application de fonction surveille la file d’attente des 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 dans les requêtes web de manière ordonnée lorsque nous utilisons une file d’attente de cette façon. Lorsqu’il existe de nombreuses tâches en arrière-plan à exécuter, la file d’attente peut s’accumuler, mais les tâches ne sont pas supprimées. Ils restent dans la file d’attente jusqu’à ce qu’ils soient traités. 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.
N’oubliez pas que nous ne pouvons pas utiliser d’option de redondance d’accès en lecture, car notre file d’attente prend en charge les opérations de lecture et d’écriture. App Service doit ajouter des éléments à la file d’attente, et l’application de fonction doit supprimer les éléments terminés de la file d’attente. Utilisez à la place le stockage géoredondant (GRS) ou le stockage géoredondant interzone (GZRS).
Azure Cache pour Redis
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, car ils demandent des données à partir de notre base de données. Toutes les requêtes supplémentaires 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 n’entraîne pas d’erreurs, mais les performances peuvent temporairement tomber, car les données remplissent le nouveau cache.