Piliers de fiabilité et d’efficacité des performances

Le pilier Reliability du Well-Architected Framework garantit qu’une charge de travail exécute correctement et systématiquement la fonction prévue, au moment attendu. Reliability couvre trois domaines : les fondations (limites des services, topologie réseau), l’architecture de la charge de travail (systèmes distribués, évitement des points uniques de défaillance) et la gestion des modifications et des défaillances (surveillance, mise à l’échelle et reprise après défaillance). L’objectif est de concevoir des systèmes qui se rétablissent automatiquement après des interruptions de l’infrastructure ou des services.

AWS applique des quotas de service (anciennement appelés limites) aux ressources afin de protéger tous les clients. Il existe par exemple des limites par défaut pour les instances EC2 par région, pour les VPC et pour les exécutions simultanées Lambda. Si votre charge de travail atteint soudainement un quota, les demandes sont limitées ou rejetées, ce qui provoque des problèmes de fiabilité. Utilisez la console Service Quotas ou le CLI pour consulter les limites actuelles et demander leur augmentation avant d’en avoir besoin. Surveillez les métriques d’utilisation afin de détecter que vous approchez des limites avant qu’elles n’affectent la disponibilité.

Le pilier Reliability met l’accent sur la récupération automatique, sans intervention humaine. AWS fournit plusieurs mécanismes d’auto-rétablissement : EC2 Auto Recovery restaure automatiquement une instance sur le même matériel ou la déplace vers un matériel sain lorsque les vérifications sous-jacentes échouent. Les vérifications d’état ASG arrêtent les instances défaillantes et lancent des remplacements. RDS Multi-AZ bascule automatiquement vers l’instance de secours. Concevez votre architecture de façon à ce que la plupart des scénarios de défaillance déclenchent des actions de récupération automatique enregistrées dans les alarmes CloudWatch.

Le pilier Reliability recommande la mise à l’échelle horizontale (ajouter davantage de petites instances) plutôt que verticale (augmenter la taille des instances) afin d’améliorer la fiabilité. Une seule grande instance constitue un point unique de défaillance. De nombreuses petites instances derrière un répartiteur de charge signifient que la défaillance d’une instance donnée a un impact minimal. AWS Auto Scaling ajuste automatiquement la taille du parc pour répondre à la demande, afin de garantir que vous disposez d’une capacité suffisante sans payer de ressources inactives pendant les périodes creuses.

Le pilier Reliability exige de tester les procédures de récupération et de ne pas supposer qu’elles fonctionnent. Utilisez AWS Fault Injection Simulator (FIS) pour injecter des défaillances dans votre système de manière contrôlée : arrêtez des instances EC2 aléatoires, limitez les appels d’API ou injectez de la latence réseau. Exécutez ces expériences en production, avec des mesures de protection, afin de vérifier que votre surveillance détecte les défaillances, que la mise à l’échelle automatique réagit et que la récupération s’achève dans votre RTO. Les procédures de récupération non testées échouent souvent sous la pression d’un incident réel.

Le pilier Performance Efficiency vise à utiliser efficacement les ressources de calcul pour répondre aux exigences du système et à maintenir cette efficacité lorsque la demande évolue et que les technologies progressent. Principes clés de conception : Démocratiser les technologies avancées — utilisez des services gérés (RDS, SageMaker) plutôt que de tout développer vous-même. Passer à l’échelle mondiale en quelques minutes — déployez dans plusieurs régions avec CloudFormation. Utiliser des architectures sans serveur — éliminez la gestion de l’infrastructure. Expérimenter plus souvent — testez différents types et différentes configurations d’instances.

Performance Efficiency commence par la sélection du type de calcul adapté à votre charge de travail. EC2 propose des dizaines de familles d’instances optimisées pour différents cas d’utilisation : les séries c pour les charges intensives en calcul (encodage vidéo, traitement par lots), les séries r pour les charges intensives en mémoire (bases de données en mémoire, mise en cache), les séries i pour les charges intensives en stockage (NoSQL, entreposage de données) et les séries p/g pour les charges GPU (entraînement ML). Utiliser un type d’instance inadapté signifie payer une capacité inutilisable ou subir une dégradation des performances.

La mise en cache est une technique fondamentale de Performance Efficiency qui réduit la latence et la charge des bases de données. ElastiCache (Redis/Memcached) met en cache en mémoire les résultats des requêtes de base de données, pour un accès en quelques millisecondes. CloudFront met en cache les réponses HTTP dans des emplacements périphériques proches des utilisateurs. La mise en cache d’API Gateway réduit les invocations Lambda en mettant en cache les réponses d’API. DAX (DynamoDB Accelerator) ajoute un cache en mémoire accessible en microsecondes devant DynamoDB. Choisissez la couche de mise en cache adaptée selon l’emplacement du goulot d’étranglement : base de données, API ou diffusion périphérique.

Le choix du stockage a un impact considérable sur les performances. io2 Block Express EBS fournit jusqu’à 256 000 IOPS pour les bases de données hautes performances. gp3 est le choix par défaut pour la plupart des charges de travail, à moindre coût. Instance store fournit le plus grand nombre d’IOPS (NVMe) pour les données temporaires. S3 peut gérer des milliers de demandes par seconde pour le stockage d’objets. EFS fournit un accès partagé aux fichiers POSIX. Adaptez votre stockage au modèle d’E/S : les lectures séquentielles bénéficient de st1 (Throughput Optimised HDD), tandis que les E/S aléatoires nécessitent des volumes SSD.

Performance Efficiency ne se décide pas une seule fois : vous devez surveiller en continu les métriques de performance et réévaluer vos choix à mesure qu’AWS lance de nouveaux services. Utilisez les tableaux de bord CloudWatch pour suivre les percentiles de latence p50, p90 et p99 (et pas uniquement les moyennes, qui masquent la latence de la queue). Utilisez les traces X-Ray pour identifier les parties les plus lentes d’une chaîne de requêtes. Configurez la détection d’anomalies CloudWatch afin d’établir automatiquement une référence et de déclencher des alertes en cas d’écarts de performance anormaux. Consultez régulièrement les annonces AWS : les nouveaux types d’instances offrent souvent de meilleures performances à moindre coût.

Performance Efficiency implique parfois des compromis avec d’autres piliers. Ajouter un cache (ElastiCache) améliore les performances, mais augmente la complexité opérationnelle (compromis avec Operational Excellence) et le coût (compromis avec Cost Optimisation). Utiliser DynamoDB plutôt que RDS améliore les performances à grande échelle, mais exige de repenser votre modèle de données (effort lié à Operational Excellence). Le Well-Architected Framework reconnaît ces compromis et vous demande de les effectuer en connaissance de cause, en documentant votre raisonnement. Dans les questions d’examen, recherchez l’option qui atteint les objectifs de performance avec le moins de charge opérationnelle.

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 : Reliability exige une récupération automatique, une mise à l’échelle horizontale et des tests réguliers des défaillances ; Performance Efficiency exige de sélectionner le type de calcul, de stockage et de base de données adapté à chaque charge de travail ; et la mise en cache à plusieurs couches réduit la latence et la charge des bases de données. Ces deux piliers exigent une surveillance continue et la volonté de réévaluer les décisions d’architecture. Nous allons maintenant explorer les piliers Cost Optimisation et Sustainability.