Modèles Multi-AZ pour les services avec état

Les services avec état — bases de données, caches, systèmes de fichiers — sont les composants les plus difficiles à rendre hautement disponibles, car ils contiennent des données qui doivent survivre aux pannes. Si une base de données située dans une seule AZ tombe en panne, toute votre application perd son magasin de données. La réponse d’AWS consiste à utiliser des déploiements Multi-AZ, dans lesquels le service conserve un réplica synchrone ou quasi synchrone dans une deuxième zone de disponibilité, capable de prendre rapidement le relais lorsque le serveur principal tombe en panne.

RDS Multi-AZ conserve un réplica de secours synchrone dans une AZ différente. Chaque écriture effectuée sur le serveur principal est répliquée de manière synchrone avant la confirmation de sa réussite — cela signifie une perte de données nulle (RPO=0), mais entraîne une légère augmentation de la latence d’écriture. Lorsque le serveur principal tombe en panne, RDS met automatiquement à jour le point de terminaison DNS pour qu’il pointe vers le serveur de secours en 60 à 120 secondes. Votre application doit uniquement se reconnecter au même point de terminaison ; aucune modification du code n’est nécessaire.

Amazon Aurora va plus loin avec Multi-AZ grâce à une couche de stockage distribuée partagée qui réplique automatiquement les données dans trois AZ, en six copies. Les instances Aurora sont sans état : elles lisent et écrivent dans ce stockage partagé. Lorsque le Writer Aurora PRIMARY tombe en panne, une Read Replica située dans une autre AZ est promue au rôle de Writer en moins de 30 secondes. Cette opération est plus rapide que le basculement Multi-AZ de RDS, et les données restent toujours cohérentes entre les AZ sans réplication explicite vers une instance Standby.

ElastiCache for Redis prend en charge Multi-AZ grâce aux groupes de réplication. Un nœud PRIMARY accepte les écritures et les réplique de manière Asynchronous vers des Replicas de lecture situées dans d’autres AZ. Lorsque le nœud PRIMARY tombe en panne, ElastiCache promeut automatiquement une Replica au rôle de PRIMARY. Pour Redis avec le mode cluster Enabled, les données sont réparties entre plusieurs groupes de nœuds, chacun possédant son propre PRIMARY et ses Replicas dans différentes AZ ; cela fournit à la fois la HA et la montée en charge horizontale.

Amazon Elastic File System (EFS) est Multi-AZ par nature : il s’agit d’un service régional qui stocke les données de manière redondante dans plusieurs AZ au sein d’une région. Vous créez des cibles de montage dans le sous-réseau de chaque AZ, et les instances EC2 de n’importe quelle AZ peuvent monter le système de fichiers via leur cible de montage locale. Aucune configuration Multi-AZ manuelle n’est nécessaire. EFS fournit un stockage de fichiers partagé POSIX auquel plusieurs instances réparties dans différentes AZ peuvent accéder simultanément.

Les Elastic Load Balancers sont eux-mêmes Multi-AZ : ALB et NLB déploient des nœuds d’équilibrage de charge dans chaque AZ que vous indiquez. Avec l’équilibrage de charge Cross-Zone Enabled (valeur par défaut pour ALB), chaque nœud d’équilibrage de charge répartit le trafic de manière uniforme entre toutes les cibles enregistrées dans toutes les AZ, et pas uniquement dans sa propre AZ. Ainsi, même si toutes les instances d’une AZ tombent en panne, l’équilibreur de charge continue de servir le trafic via les instances des AZ restantes.

Une erreur courante consiste à déployer un seul NAT Gateway dans une AZ, tandis que les sous-réseaux privés des autres AZ y acheminent leur trafic. Si cette AZ tombe en panne, toutes les instances privées perdent leur accès à Internet. Le modèle Multi-AZ correct consiste à déployer un NAT Gateway par AZ et à configurer la table de routage privée de chaque AZ pour acheminer 0.0.0.0/0 via son propre NAT Gateway. Cela élimine le NAT Gateway comme SPOF inter-AZ et réduit les coûts de transfert de données inter-AZ.

DynamoDB est un service entièrement géré qui réplique automatiquement les données dans trois AZ d’une région ; vous ne configurez pas Multi-AZ manuellement. Chaque écriture est stockée de manière durable dans les trois AZ avant que le succès ne soit renvoyé. DynamoDB est donc tolérant aux pannes au niveau des AZ dès sa mise en service. C’est pourquoi DynamoDB est souvent la base de données recommandée lorsque la question d’examen met l’accent sur la haute disponibilité avec une charge opérationnelle minimale.

Lors d’un basculement Multi-AZ de RDS, les Applications qui maintiennent des Connections persistantes peuvent rencontrer des erreurs lorsque l’Endpoint change. RDS Proxy se place entre votre Application et RDS et maintient un pool de Connections vers la base de données. Pendant le basculement, RDS Proxy réachemine automatiquement les requêtes vers le nouveau PRIMARY, ce qui réduit l’impact du basculement de 60 à 120 secondes à moins de 30 secondes pour les Applications utilisant l’Endpoint du proxy. RDS Proxy est également utile avec les fonctions Lambda qui créent de nombreuses Connections de courte durée.

Comprendre les modes de réplication est essentiel pour choisir les modèles Multi-AZ. La réplication Synchronous (RDS Multi-AZ, EFS) garantit un RPO=0, car chaque écriture est confirmée dans les deux AZ avant le renvoi du succès. En contrepartie, la latence d’écriture est légèrement plus élevée. La réplication Asynchronous (Replicas Redis d’ElastiCache, RDS Read Replicas) offre une latence d’écriture plus faible, mais accepte un léger retard de réplication ; certaines données peuvent donc être perdues si le PRIMARY tombe en panne avant la fin de la réplication.

Vous devez tester régulièrement le basculement Multi-AZ afin de valider vos hypothèses de RTO. Pour RDS, vous pouvez déclencher un basculement à l’aide de l’option Reboot with failover de la console ou du CLI. Surveillez CloudWatch pour la métrique FailedSQLServerAgentJobsCount et consultez les journaux de votre Application afin de vérifier qu’elle se reconnecte correctement. Documentez la durée réelle du basculement : elle peut différer de celle indiquée dans la documentation AWS selon la classe de votre instance et votre charge de travail.

Évaluez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que RDS Multi-AZ utilise une réplication Synchronous avec un basculement DNS automatique, qu’Aurora utilise une couche de stockage partagée dans trois AZ pour accélérer le basculement, et qu’EFS et DynamoDB sont intrinsèquement Multi-AZ, sans configuration manuelle. Déployez un NAT Gateway par AZ pour éviter les SPOF inter-AZ. Nous allons maintenant étudier les modèles multi-régions Active-Active et Active-Passive.