Multi-AZ et architectures tolérantes aux pannes

Tout le sujet précédent supposait que l'infrastructure reste là où vous l'avez posée. Mettre une flotte à l'échelle, ajouter des readers, préchauffer un cache : rien de tout cela n'aide si le bâtiment où vivent les instances perd son alimentation. La compétence 2.2 du guide d'examen porte sur cette hypothèse elle-même, et elle commence par la plus petite unité de panne à laquelle AWS a donné un nom.

Une zone de disponibilité est un lieu réel

Une zone de disponibilité, c'est un ou plusieurs datacenters distincts à l'intérieur d'une Région, avec sa propre alimentation, son refroidissement, son réseau et sa connectivité physique. Pas une partition logique, pas une étiquette de baie. AWS en exploite plus de 100 dans le monde.

Deux chiffres définissent le comportement des zones, et les deux sont des décisions de conception, pas des accidents :

• Jusqu'à environ 100 km d'écart. Assez loin pour qu'une inondation, un incendie, une tornade, une coupure du réseau électrique ou une fibre sectionnée ait peu de chances d'en toucher deux à la fois. Les zones ne partagent ni groupes électrogènes, ni équipements de refroidissement, ni postes électriques, et AWS échelonne ses propres déploiements de services entre les zones d'une Région pour qu'un mauvais rollout ne puisse pas atterrir partout en même temps.
• Une latence de quelques millisecondes entre elles. Assez près pour répliquer une écriture de base de données de façon synchrone vers une autre zone et committer quand même assez vite pour une charge OLTP.

Ce couple explique à lui seul pourquoi Multi-AZ fonctionne. Si les zones étaient à 5 km, une tempête régionale en emporterait plusieurs d'un coup. Si elles étaient à 1 000 km, la réplication synchrone ajouterait des dizaines de millisecondes à chaque commit et personne ne l'activerait. La distance est choisie pour rendre la redondance entre zones à la fois utile et abordable.

Le nom d'une zone est aussi propre à votre compte. us-east-1a chez vous et us-east-1a chez un collègue désignent en général des zones physiques différentes, parce qu'AWS randomise le mapping pour répartir la charge. L'identifiant stable est l'AZ ID (use1-az1), et c'est lui que vous comparez quand vous partagez des subnets entre comptes avec AWS RAM.

Zonal, régional, global : la classification qui décide de tout

Voici l'idée fausse qui produit le plus de pannes surprises : « AWS est hautement disponible, donc ma charge de travail l'est aussi. » AWS fait tourner ses services sur plusieurs zones. Cela ne veut pas dire que les ressources précises que vous avez créées vivent dans plus d'une.

Chaque ressource AWS occupe exactement l'une de trois portées, et la portée vous dit ce qu'une panne de zone lui fait.

Lisez ce tableau comme une checklist opérationnelle, pas comme une liste de définitions. Chaque ressource zonale de votre architecture est une question : que se passe-t-il quand sa zone disparaît ? Un service régional a déjà répondu pour vous. Un service zonal, non.

Deux entrées méritent un regard plus attentif, parce qu'elles piègent :

• Un volume EBS est zonal, mais son snapshot est régional. Vous ne pouvez pas attacher un volume de us-east-1a à une instance de us-east-1b. Vous pouvez créer un nouveau volume dans us-east-1b à partir du snapshot de ce volume, parce que les données de snapshot sont répliquées sur toutes les zones de la Région. Cette asymétrie est la façon de déplacer du stockage bloc entre zones, et c'est un détail d'examen apprécié.
• Un load balancer est régional, mais ses nœuds sont zonaux. Vous activez un ALB ou un NLB dans des subnets précis, et AWS place un nœud de load balancer dans chacune de ces zones. Activez-le dans une seule zone et vous avez construit une dépendance mono-zone sous un nom qui a l'air régional. Un ALB exige des subnets dans au moins 2 zones exactement pour cette raison.

Faire survivre l'étage de calcul : router n'est pas capacitaire

Posez un Auto Scaling group sur trois zones derrière un ALB et vous avez résolu le problème de routage. Quand une zone tombe, l'ALB cesse d'envoyer des requêtes vers ses cibles unhealthy, et l'ASG marque ces instances unhealthy puis les remplace. Cette partie est automatique.

Ce qui n'est pas automatique, c'est d'avoir quelque part où envoyer le trafic. Déroulez les chiffres.

Vous faites tourner 6 instances sur 3 zones, 2 par zone, et chaque instance absorbe 20 % du trafic de pointe. À la pointe, vous utilisez 6 x 20 = 120 % de ce dont vous avez besoin, ce qui ressemble à une marge confortable. L'AZ-B tombe :

Instances survivantes : 4
Capacité :              4 x 20 % = 80 % de la pointe
Manque :                20 % de la pointe, jusqu'à ce que les remplaçantes démarrent et passent les health checks

Pendant plusieurs minutes, vous jetez ou retardez une requête sur cinq. Le load balancer a parfaitement fait son travail et le site est quand même dégradé.

La règle générale : dimensionnez pour la perte d'une zone entière, ce que l'on écrit AZ+1.

Voilà la raison concrète pour laquelle AWS recommande trois zones plutôt que deux. Deux zones font coûter la redondance le double ; trois zones la font coûter moitié plus.

Le principe derrière le tableau s'appelle la stabilité statique : le système doit continuer de fonctionner correctement sans avoir besoin de changer quoi que ce soit quand une panne survient. Lancer des instances de remplacement pendant un incident de zone est une opération de control plane, et les control planes ont des objectifs de disponibilité plus bas que les data planes, précisément parce qu'ils font un travail plus complexe. Pire, une panne de zone est exactement le moment où tous les autres clients de la Région réclament eux aussi de la capacité. Une conception qui doit faire du scale out pour survivre a rendu sa récupération dépendante du moment le plus chargé de la vie du control plane. Une conception statiquement stable a déjà la capacité en marche.

Deux réglages décident de la régularité de la répartition :

• Le cross-zone load balancing laisse un nœud de load balancer d'une zone envoyer du trafic vers des cibles de toutes les zones, et pas seulement de la sienne. Il est activé par défaut sur ALB (et désactivable par target group) et désactivé par défaut sur NLB. Désactivé, avec un nombre de cibles inégal par zone, une zone avec 2 cibles reçoit la même part de trafic qu'une zone avec 8, et chacune de ces 2 cibles travaille quatre fois plus.
• Health checks ELB contre health checks ASG. Par défaut, un Auto Scaling group ne surveille que les status checks EC2, qui disent que l'instance tourne, pas que votre application répond. Activez les health checks ELB sur l'ASG pour qu'une cible qui échoue au check HTTP du load balancer soit remplacée au lieu de rester là à renvoyer des erreurs.

L'étage de données : trois façons de survivre à une zone

Le calcul est remplaçable. Les données ne le sont pas, donc la couche base de données a sa propre réponse, et RDS vous donne trois formes aux propriétés très différentes.

Le déploiement Multi-AZ DB instance est le classique et le plus souvent testé. RDS garde un standby dans une seconde zone, y réplique chaque commit de façon synchrone, et à la panne bascule le CNAME DNS derrière votre endpoint vers le standby promu. Votre application garde la même chaîne de connexion et n'a qu'à se reconnecter. Deux conséquences découlent du mot « synchrone » :

• La latence d'écriture et de commit augmente par rapport à du Single-AZ, parce que chaque commit attend la seconde zone. C'est le prix que vous payez pour la durabilité.
• Le standby n'est pas un serveur de secours que vous pouvez utiliser. Il n'accepte aucune connexion. Si un énoncé demande de décharger des lectures, la réponse est un read replica ou un Multi-AZ DB cluster, jamais le standby.

Aurora prend un autre chemin : le cluster volume lui-même s'étend sur trois zones et garde six copies de vos données, donc la réplication au niveau des instances n'existe pas. Perdre une zone retire des instances mais pas le stockage, et c'est pourquoi un reader Aurora est promu si vite.

Les dépendances mono-zone qu'on laisse traîner

Même une architecture multi-zones soignée garde en général quelques goulets zonaux. Voici ceux qui valent un audit :

• La NAT gateway. Créée dans un subnet, donc dans une zone. Routez tous les subnets privés à travers une seule NAT gateway et la panne d'une zone coupe l'accès internet sortant de tout le VPC. Déployez-en une par zone et donnez à chaque subnet privé une route table qui pointe sur la gateway de sa propre zone. Cela supprime aussi les frais de transfert entre zones, donc la conception résiliente est souvent la moins chère.
• EFS One Zone. Classe de stockage moins chère, et le nom est l'avertissement. EFS Standard réplique entre zones ; One Zone, non.
• Les volumes instance store. Physiquement attachés à l'hôte. Pas seulement zonaux : liés à la vie de l'instance. Arrêter l'instance perd les données.
• Une instance RDS Single-AZ avec un read replica dans une autre zone. Cela ressemble à du Multi-AZ sur un schéma, mais le réplica est asynchrone et la promotion est une opération manuelle qui prend des minutes. C'est un plan de reprise, pas un mécanisme de failover.
• Un load balancer activé dans un seul subnet. Vu plus haut, et facile à créer par accident dans un environnement de test qui devient plus tard la production.

Ce que Multi-AZ ne fait pas

Multi-AZ protège contre une panne d'infrastructure dans une zone. C'est une promesse précise et limitée. Elle ne fait rien contre :

• La corruption logique. Un DELETE sans clause WHERE se réplique de façon synchrone vers le standby en quelques millisecondes. Les deux copies sont désormais aussi fausses l'une que l'autre. La récupération passe par une restauration point-in-time ou un snapshot.
• La suppression accidentelle. Supprimer l'instance de base de données supprime aussi son standby.
• Les événements à l'échelle d'une Région. Toutes les zones du tableau ci-dessus vivent dans une seule Région. Survivre à la perte d'une Région est une autre architecture, et la dernière leçon de ce sujet couvre les quatre façons de la bâtir.
• Un mauvais déploiement. Du code neuf qui renvoie du HTTP 500 le renvoie à l'identique dans les trois zones.

Voici la façon la plus nette de tenir cette frontière en tête : Multi-AZ est de la haute disponibilité, et cela protège contre ce qui casse. Les sauvegardes et la réplication inter-Régions sont de la reprise après sinistre, et cela protège contre ce qui est faux. L'examen sépare les deux avec constance, et votre conception devrait faire pareil.

Conseils pour l'examen

• Les formules « survivre à la panne d'une zone de disponibilité », « haute disponibilité » et « failover automatique » désignent Multi-AZ. Les formules « suppression accidentelle », « corruption de données », « restaurer à un instant donné » et « panne de Région » désignent les sauvegardes ou une stratégie de reprise, et Multi-AZ y est la mauvaise réponse même si elle a l'air protectrice.
• Toute réponse qui lit depuis le standby d'un Multi-AZ DB instance est fausse. L'option existe pour être rejetée. Décharger des lectures, c'est un read replica ou un Multi-AZ DB cluster.
• Chiffres à retenir : failover Multi-AZ DB instance en 60 à 120 secondes, failover Multi-AZ DB cluster généralement sous 35 secondes, stockage Aurora à 6 copies sur 3 zones, ALB exigeant au moins 2 zones.
• Quand un énoncé décrit une panne qui a tout emporté malgré plusieurs zones, cherchez une dépendance zonale partagée. La NAT gateway unique est le cas classique ; le load balancer sur un seul subnet est l'autre.
• Cross-zone load balancing : activé par défaut sur ALB, désactivé par défaut sur NLB. Nombre de cibles inégal par zone plus cross-zone désactivé égale charge inégale.
• Si une question demande quelle capacité faire tourner dans chaque zone, la réponse attendue est : assez pour que les zones restantes portent toute la charge sans faire de scale out. C'est la stabilité statique, et sa justification est qu'Auto Scaling est une opération de control plane.

La règle de décision à emporter : pour chaque ressource de votre architecture, nommez sa portée. Une ressource zonale a besoin d'une sœur dans une autre zone et de quelque chose qui contourne la panne ; une ressource régionale a déjà réglé la question. Tout ce qui est dans cette leçon garde une charge de travail en marche à travers une panne d'infrastructure, et rien de tout cela n'aide quand ce sont les données elles-mêmes qui sont fausses. C'est l'objet de la leçon suivante, et elle commence par le mécanisme qui se trouve sous chaque sauvegarde AWS : le snapshot.