Modèle de responsabilité partagée pour la résilience - Reliability Pillar

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Modèle de responsabilité partagée pour la résilience

La résilience est une responsabilité partagée entre vous AWS et vous. Il est important que vous compreniez comment la reprise après sinistre (DR) et la disponibilité, qui font partie de la résilience, fonctionnent dans le cadre de ce modèle partagé.

AWS responsabilité - Résilience du cloud

AWS est responsable de la résilience de l'infrastructure qui gère tous les services proposés dans le AWS Cloud. Cette infrastructure comprend le matériel, les logiciels, les réseaux et les installations qui exécutent AWS Cloud les services. AWS déploie des efforts commercialement raisonnables pour rendre ces AWS Cloud services disponibles, en veillant à ce que la disponibilité des services respecte ou dépasse les accords de niveau de AWS service (SLAs).

L’infrastructure cloud mondiale AWS est conçue pour permettre aux clients de créer des architectures de charge de travail hautement résilientes. Chacune Région AWS est entièrement isolée et se compose de plusieurs zones de disponibilité, qui sont des partitions d'infrastructure physiquement isolées. Les zones de disponibilité isolent les défaillances susceptibles d’affecter la résilience des charges de travail, en les empêchant d’avoir un impact sur les autres zones de la région. Mais en même temps, toutes les zones d'un Région AWS sont interconnectées par un réseau à bande passante élevée et à faible latence, via une fibre métropolitaine dédiée entièrement redondante, fournissant un réseau à haut débit et à faible latence entre les zones. Tout le trafic entre les zones est chiffré. Les performances du réseau sont suffisantes pour réaliser une réplication synchrone entre les zones. Lorsqu'une application est partitionnéeAZs, les entreprises sont mieux isolées et protégées contre les problèmes tels que les pannes de courant, les éclairs, les tornades, les ouragans, etc.

Responsabilité des clients : résilience dans le cloud

Votre responsabilité est déterminée par les AWS Cloud services que vous sélectionnez. Cela détermine la quantité de travail de configuration que vous devez effectuer dans le cadre de vos responsabilités en matière de résilience. Par exemple, un service tel qu'Amazon Elastic Compute Cloud (AmazonEC2) oblige le client à effectuer toutes les tâches de configuration et de gestion de la résilience nécessaires. Les clients qui déploient des EC2 instances Amazon sont chargés de déployer des EC2instances Amazon sur plusieurs sites (tels que les zones de AWS disponibilité), de mettre en œuvre l'autoréparation à l'aide de services tels que Auto Scaling et d'appliquer les meilleures pratiques en matière d'architecture de charge de travail résiliente pour les applications installées sur les instances. Pour les services gérés, tels qu'Amazon S3 et Amazon DynamoDB, la couche d'infrastructure AWS , le système d'exploitation et les plateformes sont exploités, et les clients accèdent aux points de terminaison pour stocker et récupérer les données. Vous êtes responsable de la gestion de la résilience de vos données, y compris des stratégies de sauvegarde, de gestion des versions et de réplication.

Le déploiement de votre charge de travail sur plusieurs zones de disponibilité Région AWS fait partie d'une stratégie de haute disponibilité conçue pour protéger les charges de travail en isolant les problèmes dans une zone de disponibilité, qui utilise la redondance des autres zones de disponibilité pour continuer à traiter les demandes. Une architecture Multi-AZ s’inscrit également dans une stratégie DR conçue pour mieux isoler et protéger les charges de travail contre des problèmes tels que les pannes de courant, la foudre, les tornades, les tremblements de terre, etc. Les stratégies de DR peuvent également faire appel à de multiples Régions AWS. Par exemple, dans une configuration active/passive, le service de la charge de travail passe de sa région active à sa région DR si la région active ne peut plus répondre aux requêtes.

Graphique illustrant le modèle de résilience partagée.

Responsabilité en matière de résilience dans et hors du cloud pour les clients et AWS.

Vous pouvez utiliser AWS les services pour atteindre vos objectifs de résilience. En tant que client, vous êtes responsable de la gestion des aspects suivants de votre système pour atteindre la résilience dans le cloud. Pour plus de détails sur chaque service en particulier, consultez la documentation AWS.

Réseaux, quotas et contraintes

  • Les bonnes pratiques pour ce domaine du modèle de responsabilité partagée sont décrites en détail dans la section Fondations.

  • Planifiez votre architecture avec une marge de manœuvre suffisante et comprenez les quotas de service et les contraintes des services que vous incluez, en fonction des augmentations de charge attendues, le cas échéant.

  • Concevez la topologie de votre réseau pour qu’elle soit hautement disponible, redondante et évolutive.

Gestion des modifications et résilience opérationnelle

Observabilité et gestion des pannes

Architecture de charge de travail

  • L'architecture de votre charge de travail inclut la manière dont vous concevez des services axés sur des domaines commerciaux, appliquez SOA et distribuez la conception de systèmes pour éviter les défaillances, et intégrez des fonctionnalités telles que la limitation, les nouvelles tentatives, la gestion des files d'attente, les délais d'attente et les leviers d'urgence.

  • Appuyez-vous sur des solutions AWS éprouvées, Amazon Builders’ Library et des modèles sans serveur pour vous aligner sur les bonnes pratiques et accélérer les mises en œuvre.

  • Utilisez l’amélioration continue pour décomposer votre système en services distribués afin d’évoluer et d’innover plus rapidement. Utilisez les conseils relatifs aux microservices AWS et les options de services gérés pour simplifier et accélérer votre capacité à introduire le changement et à innover.

Test continu des infrastructures critiques

  • Pour tester la fiabilité, il faut effectuer des tests au niveau des fonctionnalités, des performances et du chaos, ainsi qu’adopter l’analyse des incidents et les pratiques des jours de jeu afin de développer une expertise en matière de résolution de problèmes mal compris.

  • Pour les applications tout cloud et hybrides, le fait de savoir comment votre application se comporte lorsque des problèmes surviennent ou que des composants tombent en panne permet une reprise rapide et fiable après une panne.

  • Créez et documentez des expériences reproductibles pour comprendre comment votre système se comporte lorsque les objets ne fonctionnent pas comme prévu. Ces tests prouveront l’efficacité de votre résilience globale et fourniront une boucle de rétroaction pour vos procédures opérationnelles avant de vous confronter à des scénarios de panne réels.