HA ou tolérance aux pannes : définitions et compromis

La haute disponibilité (HA) et la tolérance aux pannes (FT) sont deux objectifs de fiabilité distincts que les architectes confondent souvent. La haute disponibilité signifie qu’un système connaît un temps d’arrêt minimal : il peut tolérer des pannes, mais de brèves interruptions peuvent survenir pendant la récupération. La tolérance aux pannes signifie qu’un système continue de fonctionner sans aucune interruption, même lorsque des composants tombent en panne, grâce à des chemins entièrement redondants qui prennent instantanément le relais.

La disponibilité se mesure comme un pourcentage de temps de fonctionnement sur une année. Une disponibilité de 99,9 % (trois neuf) correspond à environ 8,7 heures d’indisponibilité par an, tandis que 99,99 % (quatre neuf) n’autorise que 52,6 minutes. 99,999 % (cinq neuf) n’autorise que 5,26 minutes. Chaque neuf supplémentaire nécessite généralement davantage de redondance, d’automatisation et de coûts. L’examen SAA-C03 vous demande souvent d’identifier l’architecture qui répond à un objectif de disponibilité donné.

Une architecture hautement disponible tolère la panne d’un composant en détectant automatiquement celle-ci et en basculant vers un remplacement sain en quelques secondes ou minutes. Parmi les exemples figurent RDS Multi-AZ (basculement automatique vers le serveur de secours dans une AZ différente), les Auto Scaling Groups qui remplacent les Instances arrêtées et les Elastic Load Balancers qui redirigent le trafic loin des cibles défaillantes. Une brève interruption survient, mais le système récupère sans intervention manuelle.

Une architecture tolérante aux pannes dispose d’une redondance active : plusieurs composants identiques traitent les requêtes simultanément. Lorsqu’un composant tombe en panne, les autres absorbent instantanément sa charge, sans aucune interruption. Parmi les exemples figurent un ELB actif-actif avec plusieurs Instances EC2, les tables globales DynamoDB qui traitent simultanément les lectures et les écritures dans plusieurs régions, et Aurora avec plusieurs réplicas de lecture. La tolérance aux pannes nécessite davantage de ressources en fonctionnement permanent.

La tolérance aux pannes est nettement plus coûteuse que la haute disponibilité, car elle exige une capacité redondante entièrement provisionnée en permanence. Une instance RDS Multi-AZ hautement disponible double le coût de votre base de données pour un serveur de secours qui ne s’active qu’en cas de panne. Un déploiement Aurora actif-actif multi-région tolérant aux pannes peut coûter quatre fois plus cher, mais élimine toute interruption lors des pannes régionales. Les architectes doivent trouver un équilibre entre le coût de la redondance et le coût métier des interruptions.

Le Recovery Time Objective (RTO) est la durée maximale acceptable pendant laquelle un système peut être indisponible. Les architectures à haute disponibilité visent un RTO faible, généralement de quelques minutes, grâce au basculement automatisé. Les architectures tolérantes aux pannes visent un RTO proche de zéro. Lors de la conception d’une solution HA, vous devez choisir des services et des configurations qui garantissent une récupération dans les limites de votre RTO. Par exemple, RDS Multi-AZ fournit un RTO d’environ 60 à 120 secondes, adapté à de nombreuses exigences de HA.

Un point unique de défaillance (SPOF) est un composant dont la panne entraîne celle de l’ensemble du système. Parmi les SPOFs courants figurent une seule instance EC2 sans ASG, une base de données RDS dans une seule AZ, une seule passerelle NAT ou une seule zone de disponibilité. La suppression des SPOFs est la première étape vers la HA et la FT. L’examen SAA-C03 évalue fréquemment votre capacité à identifier et à supprimer les SPOFs dans des schémas d’architecture donnés.

Atteindre la HA ou la FT est beaucoup plus simple pour les services sans état (comme les serveurs web ou les fonctions Lambda), car n’importe quelle instance peut traiter n’importe quelle requête. Les services avec état (bases de données, caches, systèmes de fichiers) sont plus difficiles : vous devez synchroniser l’état entre les réplicas, gérer le retard de réplication et garantir la cohérence lors du basculement. Les services AWS tels qu’EFS (système de fichiers partagé), ElastiCache avec des groupes de réplication et Aurora (stockage partagé) sont conçus pour simplifier la HA des services avec état.

Les modèles HA courants sur AWS comprennent : 1) Équilibrage de charge Multi-AZ — répartir les Instances EC2 entre plusieurs AZ derrière un ALB. 2) Réplicas de lecture — décharger le trafic de lecture et promouvoir un réplica en cas de DR. 3) S3 pour les ressources sans état — S3 est intrinsèquement HA, avec une durabilité de 11 neuf. 4) Global Accelerator — des adresses IP Anycast statiques qui acheminent le trafic vers des points de terminaison sains dans différentes régions. Chaque modèle échange un coût contre un niveau de disponibilité donné.

Les modèles tolérants aux pannes nécessitent une redondance active partout. Principaux modèles FT : DynamoDB est intrinsèquement tolérant aux pannes : il réplique les données dans trois AZ sans nécessiter de basculement. S3 intègre la FT. Aurora Multi-Master (désormais Aurora Serverless v2 multi-écriture) permet d’effectuer des écritures simultanément dans plusieurs AZ. Kinesis stocke les données dans plusieurs AZ par défaut. Choisir des services gérés intégrant la FT est le moyen le plus économique de parvenir à des architectures sans interruption.

La qualité d’une conception HA ou FT dépend de la qualité de vos tests. AWS recommande d’utiliser AWS Fault Injection Simulator (FIS) pour mener des expériences contrôlées qui arrêtent des Instances, limitent des API ou injectent des pannes réseau. Vous devez vérifier que le basculement s’achève bien dans les limites de votre RTO, qu’aucune donnée n’est perdue au-delà de votre RPO et que les alarmes se déclenchent correctement. Des journées de simulation régulières et des exercices d’ingénierie du chaos révèlent les lacunes de vos hypothèses de résilience avant les incidents de production.

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

Dans cette leçon, vous avez appris que la haute disponibilité réduit les interruptions grâce à une récupération automatisée (RTO de quelques minutes), que la tolérance aux pannes élimine les interruptions grâce à la redondance active (RTO nul) et que le coût augmente considérablement avec chaque niveau de résilience. La suppression des points uniques de défaillance est le fondement des deux approches. Nous allons maintenant étudier les modèles Multi-AZ pour les services avec état.