Actif-actif multisite avec Global Tables et Route 53

Multi-Site Active-Active est le niveau le plus élevé de reprise après sinistre : votre application fonctionne à pleine capacité de production dans au moins deux régions AWS simultanément. Contrairement au mode actif-passif, dans lequel un environnement de secours attend de prendre le relais, les deux régions traitent en permanence le trafic réel des utilisateurs. Lorsqu’une région tombe en panne, l’autre absorbe immédiatement 100 % du trafic, sans délai de basculement. Ce modèle réduit également la latence pour les utilisateurs répartis dans le monde entier, en les servant depuis la région la plus proche.

DynamoDB Global Tables constitue le socle de données des architectures actives-actives. Global Tables permet la réplication multi-maître et multi-région : les applications de n’importe quelle région peuvent lire et write dans une table DynamoDB locale, et les modifications sont répliquées vers toutes les autres régions en environ 1 seconde. Vous activez Global Tables en indiquant les régions dans lesquelles la table doit exister. AWS gère automatiquement toute la réplication, la résolution des conflits (priorité au dernier write) et le basculement.

Aurora Global Database fournit des lectures actives-actives, mais des écritures actives-passives. Toutes les régions secondaires servent les lectures avec un retard de réplication inférieur à 1 seconde, tandis que seule la région Primary accepte les écritures. Cette solution convient parfaitement aux applications à forte proportion de lectures qui souhaitent bénéficier de lectures à faible latence partout dans le monde, avec une région Primary clairement définie pour les écritures. En cas de panne régionale de la région Primary, vous pouvez promouvoir une région secondaire au rôle de Primary en moins d’une minute, ce qui permet d’obtenir un RTO faible pour le niveau d’écriture. Comparez cette solution à DynamoDB Global Tables, qui prend en charge les écritures actives-actives dans toutes les régions.

Route 53 dirige le trafic des architectures actives-actives sur plusieurs sites. Utilisez le routage basé sur la latence pour envoyer chaque utilisateur vers la région présentant la latence réseau la plus faible depuis son emplacement. Associez des contrôles d’état à l’enregistrement de chaque région : lorsqu’une région échoue à son contrôle d’état, Route 53 la retire automatiquement des réponses DNS et envoie tout le trafic vers les régions saines restantes. Définissez le TTL DNS sur 60 secondes ou moins afin de réduire le temps nécessaire au basculement des utilisateurs vers la région saine.

Lorsqu’une région tombe en panne dans une configuration active-active, la région survivante doit gérer deux fois (voire davantage) son trafic normal. Votre groupe de mise à l’échelle automatique doit disposer d’une capacité maximale suffisante et de politiques d’augmentation de capacité qui réagissent rapidement. Configurez le TargetTrackingScaling en fonction du nombre de requêtes ALB par cible, afin que l’ASG ajoute automatiquement des instances lorsque le trafic double. Envisagez également le préchauffage : pendant les exercices de basculement, observez la rapidité avec laquelle votre ASG augmente sa capacité et vérifiez qu’il peut atteindre la capacité requise dans le délai correspondant à votre objectif de RTO.

Dans une architecture à une seule région, les sessions utilisateur peuvent être stockées localement sur les serveurs d’application. Dans une architecture active-active multirégion, les utilisateurs peuvent passer d’une région à l’autre lors de requêtes successives, ce qui interrompt les sessions côté serveur. Solutions : 1) sessions sans état — stockez les données de session dans un JWT signé ou un cookie que n’importe quel serveur, dans n’importe quelle région, peut valider. 2) DynamoDB Global Tables pour les sessions — stockez les sessions de manière centralisée, avec un accès en quelques millisecondes depuis n’importe quelle région. 3) ElastiCache avec Global Datastore — utilisez la réplication Redis entre les régions pour le stockage des sessions.

Le principal défi du mode actif-actif avec des écritures multi-maîtres réside dans les conflits d’écriture. Si deux utilisateurs de régions différentes modifient simultanément le même enregistrement, quelle modification doit l’emporter ? DynamoDB Global Tables applique la règle de la priorité au dernier write, en fonction de l’horodatage de l’écriture. Cette approche fonctionne bien dans la plupart des cas, mais peut entraîner une perte de données en cas de mises à jour concurrentes (par exemple, lorsque deux utilisateurs incrémentent simultanément un compteur). Concevez votre modèle de données de façon à éviter les écritures simultanées dans le même élément depuis différentes régions, en utilisant des écritures conditionnelles ou en répartissant la propriété des données par région.

Pour le stockage d’objets en mode actif-actif, utilisez la réplication interrégionale S3 avec réplication bidirectionnelle (disponible pour les buckets dont la gestion des versions est activée). Contrairement à la CRR unidirectionnelle, la réplication bidirectionnelle maintient les deux buckets régionaux synchronisés : les objets écrits dans l’une ou l’autre région sont automatiquement répliqués dans l’autre. Cette configuration est essentielle pour les applications qui écrivent les fichiers importés par les utilisateurs dans le bucket S3 de leur région locale, mais qui doivent rendre ces fichiers accessibles partout dans le monde. Activez le Replication Time Control (RTC) de S3 pour garantir que 99,99 % des objets sont répliqués en moins de 15 minutes.

Utilisez CloudFront avec des groupes d’origines pour créer un CDN actif-actif avec basculement automatique. Configurez une origine Primary (ALB dans us-east-1) et une origine Secondary (ALB dans eu-west-1). CloudFront bascule automatiquement vers l’origine Secondary lorsque l’origine Primary renvoie des erreurs 5xx. Pour les ressources statiques servies depuis S3, configurez des groupes d’origines pointant vers des buckets S3 situés dans plusieurs régions et utilisant une réplication bidirectionnelle. Vous ajoutez ainsi une couche de résilience au niveau du CDN à votre routage actif-actif Route 53.

Les architectures actives-actives nécessitent une surveillance robuste afin de vérifier que les deux régions sont saines et que le trafic est réparti comme prévu. Métriques clés : Route 53 HealthCheckPercentageHealthy par région, DynamoDB ReplicationLatency pour le retard de Global Tables, ALB RequestCount par région afin de vérifier la répartition du trafic, et tableaux de bord CloudWatch intercomptes et interrégions pour disposer d’une vue unifiée. Définissez des alarmes lorsque le retard de réplication dépasse votre seuil de RPO ou lorsque la répartition du trafic devient fortement déséquilibrée.

Le mode actif-actif est adapté lorsque : les utilisateurs sont répartis dans le monde entier et qu’une latence vers une seule région est inacceptable. Le RTO doit être proche de zéro : l’entreprise ne peut tolérer même quelques minutes d’interruption. Un débit d’écriture élevé nécessite de répartir les écritures entre plusieurs régions. Des exigences réglementaires imposent que les données soient traitées dans le pays concerné. Le coût est nettement supérieur à celui des autres niveaux de DR ; choisissez donc le mode actif-actif uniquement lorsque les exigences métier et les considérations économiques le justifient clairement. Pour de nombreuses charges de travail, Warm Standby suffit et coûte beaucoup moins cher.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que DynamoDB Global Tables permet les écritures multi-maîtres entre les régions pour un véritable mode actif-actif, que le routage Route 53 fondé sur la latence et les contrôles d’état dirigent les utilisateurs vers la région saine la plus proche, et que la gestion des sessions doit être sans état ou utiliser un stockage répliqué à l’échelle mondiale en mode actif-actif. Le mode actif-actif fournit un RTO et un RPO proches de zéro, mais à un coût nettement plus élevé. Nous allons maintenant étudier les piliers Excellence opérationnelle et Security du Well-Architected Framework.