Fiabilité
Le pilier Fiabilité comprend la fiabilité est la capacité d'une charge de travail à exécuter la fonction prévue correctement et systématiquement au moment attendu. elle renvoie aussi à la capacité d'exploiter et de tester la charge de travail tout au long de son cycle de vie.
Le pilier fiabilité fournit une vue d'ensemble des principes de conception, des bonnes pratiques et des questions. Vous pouvez trouver des directives normatives sur l'implémentation dans le livre blanc Pilier Fiabilité.
Principes de conception
Il existe five principes de conception pour le pilier fiabilité dans le cloud :
-
Reprise automatique après une panne: En contrôlant les indicateurs de performance clés (KPI) d'une charge de travail, vous pouvez déclencher l'automatisation en cas de dépassement d'un seuil. Ces KPI doivent couvrir la valeur commerciale et non des aspects techniques du fonctionnement du service. Cela permet la création de notifications automatiques, le suivi des pannes et l'exécution de processus de récupération automatique qui contournent ou corrigent les pannes. Une automatisation plus sophistiquée rend possible l'anticipation et la correction des pannes avant qu'elles ne se produisent.
-
Test des procédures de reprise: Dans un environnement sur site, des tests sont souvent nécessaires pour prouver que la charge de travail fonctionne dans un scénario particulier. Ces tests ne sont généralement pas utilisés pour valider les stratégies de récupération. Dans le cloud, vous pouvez tester de quelle façon votre charge de travail cesse de fonctionner et valider vos procédures de récupération. Vous pouvez utiliser l'automatisation pour simuler différentes pannes ou recréer les scénarios qui ont déjà conduit à des pannes. Cette approche permet de réduire les risques en exposant les chemins de défaillance que vous pouvez tester et corriger avant qu'un scénario de défaillance réelle ne se produise.
-
Mise à l'échelle horizontale pour augmenter la disponibilité de la charge de travail agrégée: Remplacez une ressource volumineuse par plusieurs petites ressources pour réduire l'impact d'une panne unique sur la charge de travail globale. Répartissez les demandes entre plusieurs ressources plus petites pour garantir qu'elles ne partagent pas un point de panne commun.
-
Une capacité réellement adaptée à vos besoins: Une cause courante de défaillance des charges de travail sur site est la saturation des ressources, c'est-à-dire lorsque les demandes imposées à une charge de travail dépassent la capacité de cette dernière (c'est souvent l'objectif des attaques par déni de service). Dans le cloud, vous pouvez contrôler la demande et l'utilisation de la charge de travail. Vous pouvez aussi automatiser l'ajout ou la suppression de ressources afin de maintenir le niveau optimal de satisfaction de la demande sans surallocation ou sous-allocation. Des limites demeurent, mais certains quotas peuvent être contrôlés et d'autres gérés (consultez Gestion des quotas et contraintes de service).
-
Gestion des modifications de l'automatisation: Les modifications apportées à votre infrastructure doivent être faites à l'aide de l'automatisation. Les modifications qui doivent être gérées incluent celles apportées à l'automatisation et qui peuvent ensuite être suivies et vérifiées.
Définition
Il existe four domaines de bonnes pratiques pour le pilier fiabilité dans le cloud :
Pour la fiabilité, vous devez commencer par les bases, c'est-à-dire un environnement où les quotas de service et la topologie réseau s'adaptent à la charge de travail. L'architecture de la charge de travail du système distribué doit être conçue pour prévenir et atténuer les défaillances. La charge de travail doit gérer les modifications au niveau de la demande ou des exigences. Elle doit être conçue pour détecter les défaillances et se réparer automatiquement.
Bonnes pratiques
Bases
Les exigences de base sont celles dont le champ d'application s'étend au-delà d'une seule charge de travail ou d'un seul projet. Avant de concevoir l'architecture d'un système, les exigences de base qui influent sur la fiabilité doivent être mises en place. Par exemple, vous devez avoir une bande passante réseau suffisante pour votre centre de données.
Avec AWS, la plupart de ces exigences en matière de fondation sont déjà intégrées ou sont susceptibles d'être satisfaites en fonction des besoins. Le cloud est conçu pour être presque illimité. Il est donc de la responsabilité d'AWS de satisfaire l'exigence d'une capacité suffisante de mise en réseau et de calcul, ce qui vous laisse la liberté de modifier la taille des ressources et les allocations à la demande.
Les questions suivantes sont axées sur ces quelques considérations relatives au pilier fiabilité.
| REL 1: Comment gérez-vous les quotas et les contraintes de service ? |
| REL 2: Comment planifiez-vous la topologie de votre réseau ? |
Pour les architectures de charge de travail basées sur le cloud, il existe des quotas de service (également appelés Service Limits). Ces quotas visent à empêcher la mise en service accidentelle de plus de ressources que nécessaire et à limiter les taux de requêtes sur les opérations d'API pour protéger les services contre les abus. Les charges de travail existent souvent dans plusieurs environnements. Vous devez surveiller et gérer ces quotas pour tous les environnements de charge de travail. Il s'agit notamment de plusieurs environnements cloud (accessibles publiquement et privés) et peuvent inclure votre infrastructure de centre de données existante. Les plans doivent tenir compte de facteurs liés au réseau : connectivité intrasystème et intersystème, gestion des adresses IP publiques, gestion des adresses IP privées et résolution des noms de domaine.
Architecture de charge de travail
Une charge de travail fiable commence par des décisions de conception initiales pour le logiciel et l'infrastructure. Vos choix d'architecture ont un impact sur votre comportement de charge de travail sur les cinq piliers Well-Architected. Pour des raisons de fiabilité, vous devez suivre des modèles spécifiques.
Avec AWS, les développeurs de charges de travail ont le choix de langues et de technologies à utiliser. Les kits SDK AWS éliminent la complexité du codage en fournissant des API propres au langage pour les services AWS. Ces kits SDK, ainsi que le choix des langages, permettent aux développeurs de mettre en œuvre les bonnes pratiques de fiabilité répertoriées ici. Les développeurs peuvent également découvrir comment Amazon crée et exploite des logiciels dans la bibliothèque Amazon Builders' Library.
Les questions suivantes sont axées sur ces quelques considérations relatives au pilier fiabilité.
Les systèmes distribués s'appuient sur des réseaux de communication pour interconnecter des composants tels que des serveurs ou des services. Votre charge de travail doit fonctionner de manière fiable malgré la perte de données ou la latence dans ces réseaux. Les composants du système distribué doivent fonctionner d'une manière qui n'a pas d'impact négatif sur les autres composants ou la charge de travail.
Gestion des modifications
Les modifications apportées à votre charge de travail ou à son environnement doivent être anticipées et prises en compte pour assurer un fonctionnement fiable de la charge de travail. Les modifications incluent celles imposées à votre charge de travail telles que les pics de demande, ainsi que celles de l'intérieur comme les déploiements de fonctions et les correctifs de sécurité.
Avec AWS, vous pouvez surveiller le comportement d'une charge de travail et automatiser la réponse problèmes liés aux KPI. Par exemple, votre charge de travail peut ajouter des serveurs supplémentaires à mesure que des utilisateurs supplémentaires s'y ajoutent. Vous pouvez contrôler les personnes qui ont l'autorisation d'apporter des modifications à la charge de travail et auditer l'historique de ces modifications.
Les questions suivantes sont axées sur ces quelques considérations relatives au pilier fiabilité.
Lorsque vous concevez l'architecture d'une charge de travail de manière à ajouter ou supprimer automatiquement des ressources en réponse à l'évolution de la demande, cela accroît la fiabilité et garantit que la réussite commerciale ne devient pas un poids. Une fois la surveillance en place, votre équipe est automatiquement avertie lorsque les KPI cessent de correspondre aux valeurs attendues. La journalisation automatique des modifications apportées à votre environnement vous permet d'auditer et d'identifier rapidement les actions susceptibles d'avoir un impact sur la fiabilité. Les contrôles de la gestion des modifications permettent de s'assurer que vous appliquez les règles offrant la fiabilité dont vous avez besoin.
Gestion des pannes
Les pannes sont à prévoir dans un système présentant un niveau de complexité raisonnable. Il y a fiabilité lorsque la charge de travail a connaissance des défaillances au fur et à mesure qu'elles se produisent et que des mesures sont prises pour éviter l'impact sur la disponibilité. Les charges de travail doivent être en mesure de résister aux défaillances et de résoudre automatiquement les problèmes.
Avec AWS, vous pouvez tirer profit de l'automatisation pour réagir aux données de surveillance. Par exemple, lorsqu'une métrique particulière franchit un seuil, vous pouvez déclencher une action automatique pour corriger le problème. De même, plutôt que de tenter de diagnostiquer et de corriger une ressource défaillante qui fait partie de votre environnement de production, vous pouvez la remplacer par une nouvelle ressource et exécuter l'analyse de cette ressource hors production. Comme le Cloud vous permet de maintenir les versions temporaires d'un système complet à bas coût, vous pouvez utiliser les tests automatiques pour vérifier les processus complets de récupération.
Les questions suivantes sont axées sur ces quelques considérations relatives au pilier fiabilité.
Sauvegardez régulièrement vos données et testez vos fichiers de sauvegarde pour vous assurer de pouvoir récupérer aussi bien après des erreurs logiques que des erreurs physiques. La clé de la gestion des pannes réside dans des tests réguliers et automatiques des charges de travail afin de créer des pannes, et dans l'observation de la façon dont ces charges reprennent. Effectuez ces opérations régulièrement et assurez-vous que de tels tests sont également déclenchés après des modifications significatives de la charge de travail. Suivez activement les KPI comme l'objectif de délai de reprise (RTO) et l'objectif de point de reprise (RPO) pour évaluer la résilience d'une charge de travail (notamment au cours de scénarios de test de panne). Le suivi des KPI vous aidera à identifier et à atténuer les points de défaillance uniques. L'objectif est de tester intégralement vos processus de reprise de charge de travail de telle sorte que vous soyez assuré de récupérer l'ensemble de vos données et de continuer à servir vos clients, même en présence de problèmes persistants. Vos processus de reprise doivent être aussi bien maîtrisés que vos processus de production habituels.
Ressources
Consultez les ressources suivantes pour en savoir plus sur nos bonnes pratiques relatives au pilier Fiabilité.
Reliability Pillar: AWS Well-ArchitectedAWS Well-Architected Reliability Labs
The Amazon Builders' Library: How Amazon builds and operates software
AWS Documentation
AWS Global Infrastructure
AWS Auto Scaling: How Scaling Plans Work
Implementing Microservices on AWS
What Is AWS Backup?