REL10-BP02 Sélection des emplacements appropriés pour votre déploiement multisite - Framework AWS Well-Architected

REL10-BP02 Sélection des emplacements appropriés pour votre déploiement multisite

Résultat escompté : pour une haute disponibilité, déployez toujours (si possible) vos composants de charge de travail sur plusieurs zones de disponibilité (AZ). Pour les charges de travail avec des exigences de résilience extrêmes, évaluez soigneusement les options pour une architecture multi-région.

Diagramme illustrant un déploiement de base de données multi-AZ résilient avec sauvegarde vers une autre région AWS

Déploiement d’une base de données multi-AZ résiliente avec sauvegarde dans une autre région AWS

Anti-modèles courants :

  • Choisir de concevoir une architecture multi-région alors qu’une architecture multi-AZ répond aux exigences.

  • Ne pas tenir compte des dépendances entre les composants de l’application si les exigences en matière de résilience et d’emplacements multiples diffèrent entre ces composants.

Avantages liés au respect de cette bonne pratique : pour la résilience, vous devez utiliser une approche qui crée des niveaux de défense. Une couche protège contre les perturbations de petite envergure et courantes en créant une architecture hautement disponible à l’aide de plusieurs AZ. Une autre couche de défense est destinée à protéger contre les événements rares tels que les catastrophes naturelles généralisées et les perturbations au niveau régional. Cette deuxième couche implique de concevoir l’architecture de votre application pour qu’elle s’étende sur plusieurs Régions AWS.

  • La différence entre une disponibilité de 99,5 % et une disponibilité de 99,99 % est de plus de 3,5 heures par mois. La disponibilité attendue d’une charge de travail ne peut atteindre les « quatre neuf » que si elle se trouve dans plusieurs zones de disponibilité.

  • En exécutant votre charge de travail dans plusieurs AZ, vous pouvez isoler les pannes d’alimentation, de refroidissement et de mise en réseau, ainsi que la plupart des catastrophes naturelles telles que les incendies et les inondations.

  • La mise en œuvre d’une stratégie multi-région pour votre charge de travail permet de la protéger contre les catastrophes naturelles généralisées qui affectent une grande région géographique d’un pays, ou les défaillances techniques à l’échelle régionale. Sachez que la mise en œuvre d’une architecture multi-région peut être très complexe et n’est généralement pas requise pour la plupart des charges de travail.

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élévé

Directives d’implémentation

Dans le cas d’une catastrophe basée sur l’interruption ou la perte partielle d’une zone de disponibilité, la mise en œuvre d’une charge de travail hautement disponible dans plusieurs zones de disponibilité au sein d’une seule Région AWS ​​permet d’atténuer les effets des catastrophes naturelles et techniques. Chaque Région AWS est composé de plusieurs zones de disponibilité, chacune isolée des défaillances des autres zones et séparée par une distance significative. Cependant, dans le cas d’une catastrophe incluant le risque de perdre plusieurs composants de la zone de disponibilité (composants qui sont à une distance importante les uns des autres), vous devez implémenter des options de reprise après sinistre pour vous prémunir contre les défaillances à l’échelle de la région. Pour les charges de travail nécessitant une résilience extrême (infrastructure critique, applications liées à la santé, infrastructure du système financier, etc.), une stratégie multi-région peut être nécessaire.

Étapes d’implémentation

  1. Évaluez votre charge de travail et déterminez si les besoins de résilience peuvent être satisfaits par une approche multi-AZ (Région AWS unique) ou s’ils nécessitent une approche multi-région. La mise en œuvre d’une architecture multi-région pour répondre à ces exigences ajoute de la complexité. Par conséquent, examinez attentivement votre cas d’utilisation et ses exigences. Les exigences de résilience peuvent presque toujours être satisfaites avec une seule Région AWS. Tenez compte des exigences possibles suivantes lorsque vous déterminez si vous devez utiliser plusieurs régions :

    1. Reprise après sinistre (DR) : dans le cas d’une catastrophe basée sur l’interruption ou la perte partielle d’une zone de disponibilité, la mise en œuvre d’une charge de travail hautement disponible dans plusieurs zones de disponibilité au sein d’une seule Région AWS ​​permet d’atténuer les effets des catastrophes naturelles et techniques. Dans le cas d’une catastrophe incluant le risque de perdre plusieurs composants de la zone de disponibilité (composants qui sont à une distance importante les uns des autres), vous devez implémenter des options de reprise après sinistre entre plusieurs régions pour vous prémunir contre les catastrophes naturelles et les incidents techniques à l’échelle de la région.

    2. Haute disponibilité : une architecture multi-région (utilisant plusieurs AZ dans chaque région) peut être utilisée pour atteindre une disponibilité supérieure à quatre 9 (> 99,99 %).

    3. Localisation en piles : lors du déploiement d’une charge de travail auprès d’une audience mondiale, vous pouvez déployer des piles localisées dans différentes Régions AWS pour répondre aux besoins des audiences dans ces régions. La localisation peut inclure la langue, la devise et les types de données stockées.

    4. Proximité avec les utilisateurs : lors du déploiement d’une charge de travail auprès d’une audience mondiale, vous pouvez réduire la latence en déployant des piles dans les Régions AWS à proximité de l’endroit où se trouvent les utilisateurs finaux.

    5. Résidence des données : certaines charges de travail sont soumises à des exigences en matière de résidence des données, où les données de certains utilisateurs doivent rester à l’intérieur des frontières d’un pays spécifique. En fonction de la réglementation en question, vous pouvez choisir de déployer une pile entière, ou uniquement les données, dans la Région AWS au sein de ces frontières.

  2. Voici quelques exemples de fonctionnalités multi-AZ fournies par les services AWS :

    1. Pour protéger les charges de travail à l’aide d’EC2 ou d’ECS, déployez un équilibreur de charge Elastic devant les ressources de calcul. Elastic Load Balancing fournit ensuite la solution pour détecter les instances dans les zones défectueuses et acheminer le trafic vers les zones saines.

    2. Dans le cas d’instances EC2 exécutant des logiciels commerciaux prêts à l’emploi qui ne prennent pas en charge l’équilibrage de charge, vous pouvez bénéficier d’une forme de tolérance aux pannes grâce à la en œuvre une méthodologie de reprise après sinistre multi-AZ.

    3. Pour les tâches Amazon ECS, déployez votre service uniformément sur trois AZ pour atteindre un juste équilibre entre disponibilité et coût.

    4. Pour les tâches qui n’entrent pas dans le cadre d’Aurora Amazon RDS, vous pouvez choisir Multi-AZ comme option de configuration. En cas de défaillance de l’instance de base de données principale, Amazon RDS promeut automatiquement une base de données de secours pour recevoir le trafic dans une autre zone de disponibilité. Des réplicas en lecture multi-région peuvent également être créés pour améliorer la résilience.

  3. Voici quelques exemples de fonctionnalités multi-régions fournies par les services AWS :

    1. Pour les charges de travail Amazon S3, où la disponibilité multi-AZ est fournie automatiquement par le service, envisagez des points d’accès multi-régions si un déploiement multirégion est nécessaire.

    2. Pour les tables DynamoDB, où la disponibilité multi-AZ est fournie automatiquement par le service, vous pouvez facilement convertir les tables existantes en tables globales pour tirer parti de plusieurs régions.

    3. Si votre charge de travail repose sur des Application Load Balancers ou des Network Load Balancers, utilisez AWS Global Accelerator pour améliorer la disponibilité de votre application en dirigeant le trafic vers plusieurs régions qui contiennent des points de terminaison sains.

    4. Pour les applications qui tirent parti d’EventBridge AWS, envisagez des bus interrégionaux pour transférer les événements vers d’autres régions que vous sélectionnez.

    5. Pour les bases de données Amazon Aurora, considérez les bases de données globales Aurora, qui couvrent plusieurs régions AWS. Les clusters existants peuvent également être modifiés pour ajouter de nouvelles régions.

    6. Si votre charge de travail comprend des clés de chiffrement AWS Key Management Service (AWS KMS), déterminez si les clés multi-régions sont appropriées pour votre application.

    7. Pour d’autres fonctionnalités de service AWS, consultez cette série de blogues sur la création d’une application multi-régionale avec la série Services AWS

Niveau d’effort du plan d’implémentation : modéré à élevé

Ressources

Documents connexes :

Vidéos connexes :

Exemples connexes :