Cadre Amazon ElastiCache Well-Architected - Pilier Fiabilité - Amazon ElastiCache

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.

Cadre Amazon ElastiCache Well-Architected - Pilier Fiabilité

PF 1 : Comment prenez-vous en charge les déploiements d'architecture haute disponibilité ?

Introduction au niveau de la question : la compréhension de l'architecture haute disponibilité d'Amazon ElastiCache vous permettra de fonctionner de manière résiliente lors d'événements de disponibilité.

Avantage au niveau de la question : la configuration de vos clusters ElastiCache de manière à les rendre résilients aux pannes garantit une meilleure disponibilité de vos déploiements ElastiCache.

  • [Obligatoire] Déterminez le niveau de fiabilité dont vous avez besoin pour votre cluster ElastiCache. Les différentes charges de travail sont soumises à des normes de résilience différentes, qu'il s'agisse de charges de travail entièrement éphémères ou de charges de travail essentielles à la mission. Définissez les besoins pour chaque type d'environnement que vous exploitez, tel que le développement, le test et la production.

    Moteur de mise en cache : Memcached ou ElastiCache for Redis

    1. Memcached ne fournit aucun mécanisme de réplication et est principalement utilisé pour les charges de travail éphémères.

    2. ElastiCache for Redis propose les fonctionnalités haute disponibilité décrites ci-dessous.

  • [Meilleure pratique] Pour les charges de travail nécessitant une haute disponibilité, utilisez ElastiCache for Redis en mode cluster avec au moins deux réplicas par partition, même pour les charges de travail exigeant un faible débit qui ne nécessitent qu'une seule partition.

    1. Lorsque le mode cluster est activé, la configuration Multi-AZ est activée automatiquement.

      Multi-AZ minimise les interruptions en effectuant des basculements automatiques du nœud primaire vers les réplicas, en cas de maintenance planifiée ou non planifiée, et en atténuant les défaillances de la zone de disponibilité.

    2. Pour les charges de travail partitionnées, un minimum de trois partitions permet une récupération plus rapide en cas de basculement, car le protocole Cluster de Redis exige que la majorité des nœuds primaires soient disponibles pour atteindre le quorum.

    3. Configurez deux réplicas ou plus selon la disponibilité.

      Le fait de disposer de deux réplicas améliore la capacité de mise à l’échelle en lecture ainsi que la disponibilité en lecture dans les scénarios où un réplica est en cours de maintenance.

    4. Utilisez des types de nœuds basés sur Graviton2 (nœuds par défaut dans la plupart des régions).

      Amazon ElastiCache for Redis a optimisé les performances sur ces nœuds. Vous bénéficiez ainsi de meilleures performances en termes de réplication et de synchronisation, ce qui se traduit par une disponibilité globale améliorée.

    5. Surveillez et dimensionnez correctement pour faire face aux pics de trafic anticipé : en cas de forte charge, le moteur ElastiCache for Redis peut ne plus répondre, ce qui affecte sa disponibilité. BytesUsedForCache et DatabaseMemoryUsagePercentage sont de bons indicateurs de votre utilisation de la mémoire, alors que ReplicationLag indique l'état de votre réplication en fonction de votre taux d'écriture. Vous pouvez utiliser ces métriques pour déclencher la mise à l'échelle du cluster.

    6. Assurez la résilience côté client en effectuant des tests à l'aide de l'API Failover avant un événement de basculement de production.

    [Ressources] :

PF 2 : Comment atteignez-vous vos objectifs de point de reprise (RPO) avec ElastiCache ?

Introduction au niveau de la question : comprenez à quoi correspond le RPO de la charge de travail pour prendre des décisions éclairées concernant les stratégies de sauvegarde et de récupération d'ElastiCache.

Avantage au niveau de la question : la mise en place d'une stratégie de RPO peut améliorer la continuité des activités en cas de scénario de reprise après sinistre. La conception de vos politiques de sauvegarde et de restauration peut vous aider à atteindre vos objectifs de point de reprise (RPO) pour vos données ElastiCache. ElastiCache for Redis propose des fonctionnalités d’instantanés qui sont stockées dans Amazon S3, ainsi qu'une politique de conservation configurable. Ces instantanés sont pris au cours d'une fenêtre de sauvegarde définie et sont gérés automatiquement par le service. Si votre charge de travail nécessite une granularité de sauvegarde supplémentaire, vous avez la possibilité de créer jusqu'à 20 sauvegardes manuelles par jour. Les sauvegardes créées manuellement ne sont pas soumises à une politique de conservation de service et peuvent être conservées indéfiniment.

  • [Obligatoire] Comprenez et documentez le RPO de vos déploiements ElastiCache.

    • Sachez que Memcached ne propose aucun processus de sauvegarde.

    • Passez en revue les fonctionnalités de sauvegarde et de restauration d'ElastiCache.

  • [Meilleure pratique] Mettez en place un processus bien communiqué pour la sauvegarde de votre cluster.

    • Lancez des sauvegardes manuelles selon vos besoins.

    • Passez en revue les politiques de conservation pour les sauvegardes automatiques.

    • Notez que les sauvegardes manuelles seront conservées indéfiniment.

    • Planifiez vos sauvegardes automatiques pendant les périodes de faible utilisation.

    • Effectuez des opérations de sauvegarde sur des réplicas en lecture afin de minimiser l'impact sur les performances du cluster.

  • [Bonne pratique] Tirez parti de la fonctionnalité de sauvegarde planifiée d'ElastiCache pour sauvegarder régulièrement vos données pendant une fenêtre définie.

    • Testez régulièrement les restaurations à partir de vos sauvegardes.

  • [Ressources] :

PF 3 : Comment répondez-vous aux exigences de reprise après sinistre (DR) ?

Introduction au niveau de la question : la reprise après sinistre est un aspect important de toute planification de la charge de travail. ElastiCache for Redis propose plusieurs options pour implémenter la reprise après sinistre en fonction des exigences de résilience des charges de travail. Avec l’entrepôt de données global d’Amazon ElastiCache for Redis, vous pouvez écrire dans votre cluster ElastiCache for Redis dans une région et rendre les données disponibles en lecture à partir de deux autres clusters de réplicas entre régions, ce qui permet des lectures à faible latence et une reprise après sinistre entre les régions.

Avantage au niveau de la question : la compréhension et la planification de divers scénarios de sinistre peuvent garantir la continuité des activités. Les stratégies de reprise après sinistre doivent être équilibrées en termes de coût, d'impact sur les performances et de risque de perte de données.

  • [Obligatoire] Développez et documentez des stratégies de reprise après sinistre pour tous vos composants ElastiCache en fonction des exigences de charge de travail. ElastiCache est unique en ce sens que certains cas d'utilisation sont totalement éphémères et ne nécessitent aucune stratégie de reprise après sinistre, tandis que d'autres sont à l'opposé et nécessitent une stratégie de reprise après sinistre extrêmement robuste. Toutes les options doivent être évaluées par rapport à l'optimisation des coûts : une meilleure résilience exige de plus grandes quantités d'infrastructure.

    Découvrez les options de reprise après sinistre disponibles au niveau régional et multirégional.

    • Les déploiements multi-AZ sont recommandés pour se prémunir contre les pannes de zone de disponibilité. Veillez à effectuer le déploiement en ayant activé le mode Cluster dans les architectures multi-AZ, avec un minimum de 3 zones de disponibilité disponibles.

    • L’entrepôt de données global est recommandé pour se prémunir contre les défaillances régionales.

  • [Meilleure pratique] Activez l’entrepôt de données global pour les charges de travail qui nécessitent une résilience au niveau de la région.

    • Prévoyez un basculement vers la région secondaire en cas de dégradation du cluster principal.

    • Testez le processus de basculement multirégional avant un basculement en production.

    • Surveillez la métrique ReplicationLag pour comprendre l'impact potentiel de la perte de données lors des événements de basculement.

  • [Ressources] :

PF 4 : Comment planifiez-vous efficacement les basculements ?

Introduction au niveau de la question : l’activation de Multi-AZ avec basculements automatiques est une meilleure pratique pour ElastiCache. Dans certains cas, ElastiCache for Redis remplace les nœuds primaires dans le cadre des opérations de maintenance. Par exemple, lors d’événements de maintenance planifiée et dans le cas improbable d'une défaillance du nœud ou d’un problème avec la zone de disponibilité. La réussite des basculements dépend à la fois d'ElastiCache et de la configuration de votre bibliothèque cliente.

Avantage au niveau de la question : en suivant les meilleures pratiques relatives aux basculements d'ElastiCache conjointement avec votre bibliothèque cliente ElastiCache for Redis spécifique, vous pourrez minimiser les interruptions potentielles en cas de basculement.

  • [Obligatoire] Lorsque le mode cluster est désactivé, utilisez les délais d'expiration afin que vos clients détectent s'ils doivent se déconnecter de l'ancien nœud primaire et se reconnecter au nouveau nœud primaire, à l'aide de l'adresse IP du point de terminaison principal mise à jour. Lorsque le mode cluster est activé, la bibliothèque cliente est chargée de détecter les modifications de la topologie du cluster sous-jacent. Cela se fait le plus souvent par le biais des paramètres de configuration de la bibliothèque cliente ElastiCache for Redis, qui vous permettent également de configurer la fréquence et la méthode d'actualisation. Chaque bibliothèque cliente propose ses propres paramètres et des détails supplémentaires sont disponibles dans la documentation correspondante.

    [Ressources] :

  • [Obligatoire] La réussite des basculements dépend de l'intégrité de l'environnement de réplication entre le nœud primaire et le nœud de réplica. Passez en revue et comprenez la nature asynchrone de la réplication Redis, ainsi que les métriques CloudWatch disponibles pour établir un rapport sur le décalage de réplication entre le nœud primaire et le nœud de réplica. Pour les cas d'utilisation nécessitant une meilleure sécurité des données, utilisez la commande Redis WAIT pour forcer les réplicas à accuser réception des écritures avant de répondre aux clients connectés.

    [Ressources] :

  • [Meilleure pratique] Validez régulièrement la réactivité de votre application lors du basculement à l'aide de l'API Test Failover d’ElastiCache.

    [Ressources] :

PF 5 : Vos composants ElastiCache sont-ils conçus pour être mis à l’échelle ?

Introduction au niveau de la question : en comprenant les fonctionnalités de mise à l'échelle et les topologies de déploiement disponibles, vos composants ElastiCache peuvent s'adapter au fil du temps pour répondre à l'évolution des exigences en matière de charge de travail. ElastiCache propose 4 méthodes de mise à l'échelle : diminution/montée en puissance (horizontale) et augmentation/diminution de capacité (verticale).

Avantage au niveau de la question : le respect des meilleures pratiques pour les déploiements d'ElastiCache offre la plus grande flexibilité de mise à l'échelle, tout en respectant le principe Well Architected qui consiste à effectuer une mise à l'échelle horizontale afin de minimiser l'impact des défaillances.

  • [Obligatoire] Comprenez la différence entre les topologies « mode cluster activé » et « mode cluster désactivé ». Dans presque tous les cas, il est recommandé d’effectuer un déploiement en ayant activé le mode Cluster, car il permet de renforcer la capacité de mise à l’échelle au fil du temps. Les composants pour lesquels le mode cluster est désactivé sont limités dans leur capacité à être mis à l’échelle horizontalement en ajoutant des réplicas en lecture.

  • [Obligatoire] Sachez quand et comment procéder à une mise à l'échelle.

    • Pour augmenter le nombre de READIOPS : ajoutez des réplicas.

    • Pour augmenter le nombre de WRITEOPS : ajoutez des partitions (montée en puissance).

    • Pour augmenter le nombre d'E/S sur le réseau : utilisez des instances optimisées pour le réseau, augmentez la capacité.

  • [Meilleure pratique] Déployez vos composants ElastiCache avec le mode Cluster activé, en privilégiant un plus grand nombre de nœuds plus petits plutôt que des nœuds moins nombreux et plus volumineux. Cela limite efficacement le rayon d'explosion d'une défaillance de nœud.

  • [Meilleure pratique] Incluez des réplicas dans vos clusters pour améliorer la réactivité lors des événements de mise à l’échelle.

  • [Bonne pratique] Si le mode cluster est désactivé, utilisez des réplicas en lecture pour augmenter la capacité globale en lecture. ElastiCache prend en charge jusqu'à 5 réplicas en lecture lorsque le mode cluster est désactivé, ainsi que la mise à l'échelle verticale.

  • [Ressources] :