Architecture active-active multirégion

Même avec des zones de disponibilité, une charge de travail déployée dans une seule région Azure peut être touchée par une panne régionale — un événement rare, mais possible, causé par une catastrophe majeure, une violente tempête ou une défaillance d’infrastructure à grande échelle. Pour atteindre les niveaux de disponibilité les plus élevés, les entreprises déploient leurs charges de travail dans au moins deux régions Azure, ce qui permet à l’application de continuer à servir les utilisateurs même si une région entière devient indisponible.

Il existe deux principaux modèles multirégions :

• Actif-actif — les ressources des deux régions traitent simultanément le trafic réel. Cette approche maximise la disponibilité et peut également réduire la latence en dirigeant les utilisateurs vers la région la plus proche.
• Actif-passif — les ressources de la région secondaire sont en attente et ne reçoivent du trafic qu’après un basculement. Cette approche coûte moins cher, mais le temps de récupération est plus long.

Pour obtenir la disponibilité la plus élevée, l’approche actif-actif est à privilégier.

Azure Traffic Manager est un équilibreur de charge global basé sur DNS qui répartit le trafic entre des points de terminaison situés dans différentes régions Azure (ou sur site). Il utilise des sondes d’intégrité pour surveiller chaque point de terminaison et des méthodes de routage (performances, pondération, priorité, emplacement géographique, valeurs multiples) pour décider où envoyer le trafic. Dans une configuration actif-actif, utilisez la méthode de routage fondée sur les performances afin d’envoyer les utilisateurs vers la région saine la plus proche.

Traffic Manager prend en charge plusieurs méthodes de routage adaptées à différents scénarios :

• Performances — dirige le trafic vers le point de terminaison présentant la latence la plus faible (idéal pour l’actif-actif)
• Pondération — répartit le trafic selon un pourcentage de pondération (utile pour les déploiements progressifs)
• Priorité — envoie tout le trafic vers le point de terminaison principal, avec un basculement vers le secondaire (actif-passif)
• Emplacement géographique — dirige les utilisateurs en fonction de leur emplacement géographique (souveraineté des données)

Dans une architecture actif-actif, les données doivent être répliquées entre les régions afin que les utilisateurs de chacune d’elles lisent des données cohérentes. Voici quelques options :

• Azure SQL Database avec réplication géographique — réplique secondaire accessible en lecture dans une autre région
• Azure Cosmos DB avec écritures multirégions — toutes les régions acceptent simultanément les opérations d’écriture
• Azure Storage avec GRS — réplication asynchrone vers une région secondaire

Le choix dépend de vos exigences en matière de cohérence et de disponibilité des écritures.

Azure Cosmos DB est particulièrement adapté aux architectures actif-actif, car il prend en charge les écritures multirégions : toutes les régions configurées peuvent accepter simultanément des opérations d’écriture. Cosmos DB utilise des niveaux de cohérence configurables (de forte à éventuelle) pour gérer la synchronisation des réplicas. Dans les scénarios actif-actif, la cohérence de session ou la cohérence à obsolescence limitée sont des choix courants qui offrent un équilibre entre performances et exactitude.

Traffic Manager et Azure Front Door proposent tous deux un équilibrage de charge global, mais à des niveaux différents :

• Traffic Manager est basé sur DNS : il redirige le client vers le point de terminaison régional approprié, mais la connexion est établie directement avec ce point de terminaison. Il fonctionne au niveau DNS.
• Azure Front Door est un proxy anycast : il termine la connexion du client sur un point de présence mondial, puis transmet la requête à l’origine. En plus du routage, il fournit un WAF, le déchargement SSL et la mise en cache.

Microsoft désigne des paires de régions pour chaque région Azure : une région secondaire située dans la même zone géographique, mais suffisamment éloignée pour résister aux catastrophes régionales. Lors de la conception d’architectures multirégions, utilisez si possible la région appairée comme région secondaire. Pendant la maintenance planifiée de la plateforme, une seule région d’une paire est mise à jour à la fois, ce qui réduit les perturbations simultanées.

Dans les déploiements actif-actif, les requêtes d’un utilisateur peuvent être traitées par des régions différentes. Si votre application stocke l’état de session en mémoire sur le serveur web, cela peut provoquer des problèmes lorsque l’utilisateur change de région. La solution consiste à utiliser un magasin de sessions distribué, par exemple Azure Cache for Redis avec réplication géographique, afin que les données de session soient accessibles depuis n’importe quelle région.

Une architecture actif-actif coûte plus cher qu’un déploiement dans une seule région, car vous exécutez une copie complète de votre infrastructure dans au moins deux régions. Les coûts supplémentaires comprennent le transfert de données entre régions, la réplication géographique des bases de données, ainsi que les frais de Traffic Manager ou de Front Door. Réalisez une analyse coûts-avantages : pour les charges de travail critiques, le coût d’une interruption de service dépasse généralement de loin celui de la deuxième région.

Une architecture actif-actif doit être testée régulièrement afin de garantir son bon fonctionnement lorsqu’elle est nécessaire. Les outils d’ingénierie du chaos tels que Azure Chaos Studio vous permettent d’injecter des défaillances — par exemple, en arrêtant toutes les machines virtuelles d’une région — et d’observer la réaction du système. Des tests réguliers confirment que les sondes d’intégrité de Traffic Manager détectent les défaillances, que le basculement s’effectue dans votre RTO et que les données restent cohérentes entre les régions.

Testez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que l’architecture actif-actif déploie simultanément des ressources opérationnelles dans plusieurs régions afin de maximiser la disponibilité, qu’Azure Traffic Manager achemine le trafic à l’aide de méthodes fondées sur les performances, la priorité, la pondération ou l’emplacement géographique, et que la réplication des données (écritures multirégions de Cosmos DB, réplication géographique de SQL) est essentielle à la cohérence entre les régions. Nous allons maintenant étudier les sondes d’intégrité et les modèles de dégradation progressive.