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.

Résilience chez Amazon ElastiCache

L'infrastructure AWS mondiale est construite autour des AWS régions et des zones de disponibilité. AWS Les régions fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées par un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d'une zone de disponibilité à l'autre sans interruption. Les zones de disponibilité sont plus hautement disponibles, tolérantes aux pannes et évolutives que les infrastructures traditionnelles à un ou plusieurs centres de données.

Pour plus d'informations sur AWS les régions et les zones de disponibilité, consultez la section Infrastructure AWS mondiale.

Outre l'infrastructure AWS mondiale, Amazon ElastiCache propose plusieurs fonctionnalités pour répondre à vos besoins en matière de résilience et de sauvegarde des données.

Atténuation des défaillances

Lorsque vous planifiez votre ElastiCache implémentation Amazon, vous devez planifier de manière à ce que les défaillances aient un impact minimal sur votre application et vos données. Les rubriques dans cette section présentent les approches que vous pouvez entreprendre pour éviter d'éventuelles défaillances de vos applications et données.

Atténuation des défaillances avec Memcached

Lorsque vous exécutez le moteur Memcached, vous pouvez réduire au minimum l'impact d'un échec à l'aide des options suivantes. Il existe deux types de défaillances à prendre en compte dans vos plans d'atténuation des risques d'échec : les défaillances de nœud et les défaillances de zone de disponibilité.

Atténuation des défaillances de nœuds

Les caches sans serveur atténuent automatiquement les défaillances des nœuds grâce à une architecture multi-AZ répliquée de sorte que les défaillances des nœuds soient transparentes pour votre application. Afin d’atténuer l’impact d’une défaillance de nœud dans un cluster auto-conçu, répartissez vos données mises en cache sur plusieurs nœuds. Étant donné que les clusters auto-conçus ne prennent pas en charge la réplication, une défaillance de nœud entraînera toujours une perte de données de votre cluster.

Lorsque vous créez votre cluster Memcached, vous pouvez le créer avec 1 à 60 nœuds, ou plus sur demande spéciale. Le partitionnement de vos données sur un plus grand nombre de nœuds signifie que vous perdrez moins de données en cas de défaillance d'un nœud. Par exemple, si vous partitionnez vos données sur 10 nœuds, n'importe quel nœud simple stocke environ 10 % de vos données mises en cache. Dans ce cas, une défaillance de nœud perd environ 10 % de votre cache qui doit être remplacé lorsque le nœud de remplacement est créé et mis en service. Si les mêmes données ont été mis en cache dans 3 nœuds plus grands, la défaillance d'un nœud serait perdrait environ 33 % de vos données mises en cache.

Pour plus d'informations sur la spécification du nombre de nœuds dans un cluster Memcached, consultez Création d'un cluster Memcached (console).

Atténuation des défaillances des zones de disponibilité

Les caches sans serveur atténuent automatiquement les défaillances des zones de disponibilité grâce à une architecture multi-AZ répliquée de sorte que les défaillances des zones de disponibilité soient transparentes pour votre application.

Afin d’atténuer l’impact d’une défaillance de zone de disponibilité dans un cluster auto-conçu, recherchez vos nœuds dans le plus grand nombre possible de zones de disponibilité. Dans le cas peu probable d'une défaillance de la zone Z, vous perdrez les données mises en cache dans cette zone, et non les données mises en cache dans l'autre. AZs

Pourquoi un si grand nombre de nœuds ?

Si ma région a seulement 3 zones de disponibilité, pourquoi ai-je besoin de plus de 3 nœuds si je perds environ un tiers de mes données en cas de défaillance des zones de disponibilité ?

C'est une excellente question. Gardez à l'esprit que nous essayons d'atténuer deux types de défaillances distincts, au niveau du nœud et au niveau de la zone de disponibilité. Vous avez raison, si vos données sont réparties dans les zones de disponibilité et que l'une des zones échoue, vous perdrez uniquement les données mises en cache de cette zone, quel que soit votre nombre de nœuds. Toutefois, si un nœud échoue, le fait d'avoir plusieurs nœuds permet de réduire la proportion des données mises en perdues.

Il n'y a pas de « formule magique » pour déterminer le nombre de nœuds idéal qu'un cluster doit avoir. Vous devez mesurer l'impact de la perte de données par rapport à la probabilité d'une défaillance, par rapport au coût, et tirer vos propres conclusions.

Pour plus d'informations sur la spécification du nombre de nœuds dans un cluster Memcached, consultez Création d'un cluster Memcached (console).

Pour plus d’informations sur les régions et les zones de disponibilité, consultez Régions et zones de disponibilité.

Atténuer les défaillances lors de l'exécution de Valkey ou Redis OSS

Lorsque vous exécutez un OSS moteur Valkey ou Redis, vous disposez des options suivantes pour minimiser l'impact d'une défaillance d'un nœud ou d'une zone de disponibilité.

Atténuation des défaillances de nœuds

Les caches sans serveur atténuent automatiquement les défaillances des nœuds grâce à une architecture multi-AZ de sorte que les défaillances des nœuds soient transparentes pour votre application. Les clusters auto-conçus doivent être configurés de manière appropriée pour atténuer la défaillance d’un nœud individuel.

Pour atténuer l'impact des défaillances des OSS nœuds Valkey ou Redis sur les clusters conçus par vos soins, vous disposez des options suivantes :

Atténuation des défaillances : groupes de réplication Valkey ou Redis OSS

Un groupe de OSS réplication Valkey ou Redis est composé d'un seul nœud principal sur lequel votre application peut à la fois lire et écrire, et de 1 à 5 nœuds de réplication en lecture seule. Chaque fois que des données sont écrites sur le nœud principal, elles sont également mises à jour de façon asynchrone sur les nœuds de réplica en lecture.

Pendant ce temps, votre application peut continuer à lire et à écrire en utilisant les autres nœuds.

Valkey ou Redis Multi-AZ OSS

Vous pouvez activer le Multi-AZ sur vos groupes de réplication Valkey ou RedisOSS. Que vous activiez Multi-AZ ou non, un nœud principal défaillant sera détecté et remplacé automatiquement. Ce qui se produit dépend du fait que Multi-AZ soit activé ou pas.

Le basculement vers un nœud de réplica est généralement plus rapide que la création et la mise en service d'un nouveau nœud principal. Cela signifie que votre application peut reprendre l'écriture sur votre nœud principal plus rapidement que si Multi-AZ n'avait pas été activé.

Pour de plus amples informations, veuillez consulter Minimiser les temps d'arrêt ElastiCache en utilisant le multi-AZ avec Valkey et Redis OSS.

Pendant les étapes 1 à 4 de ce processus, votre application ne peut pas écrire sur le nœud principal. Toutefois, votre application peut continuer la lecture à partir de vos nœuds de réplica.

Pour une protection accrue, nous vous recommandons de lancer les nœuds de votre groupe de réplication dans différentes zones de disponibilité (AZs). Si vous procédez ainsi, une défaillance de zone de disponibilité affectera uniquement les nœuds figurant dans cette zone et non ceux des autres zones.

Pour de plus amples informations, veuillez consulter Haute disponibilité avec les groupes de réplication.

Atténuation des défaillances des zones de disponibilité

Les caches sans serveur atténuent automatiquement les défaillances des zones de disponibilité grâce à une architecture multi-AZ répliquée de sorte que les défaillances des zones de disponibilité soient transparentes pour votre application.

Afin d’atténuer l’impact d’une défaillance de zone de disponibilité dans un cluster auto-conçu, recherchez vos nœuds pour chaque partition dans le plus grand nombre possible de zones de disponibilité.

Quel que soit le nombre de nœuds que contient une partition, s’ils sont tous situés dans la même zone de disponibilité, une défaillance catastrophique de la zone de disponibilité entraînera la perte de toutes les données de votre partition. Toutefois, si vous localisez vos nœuds dans plusieurs zonesAZs, en cas de défaillance d'une zone de zone, vous ne perdez que les nœuds de cette zone de zone.

A chaque fois que vous perdez un nœud, vous notez une dégradation des performances puisque les opérations de lecture sont désormais partagées par un plus petit nombre de nœuds. Cette dégradation des performances perdurera tant le nœuds n'auront pas été remplacés.

Pour plus d'informations sur la spécification des zones de disponibilité pour les OSS nœuds Valkey ou Redis, consultez. Création d'un cluster Valkey (mode cluster désactivé) (console)

Pour plus d'informations sur les régions et les zones de disponibilité, consultez Choix des régions et des zones de disponibilité pour ElastiCache.

Recommandations

Nous vous recommandons de créer des caches sans serveur sur des clusters auto-conçus, car vous obtiendrez automatiquement une meilleure tolérance aux pannes sans configuration supplémentaire. Lors de la création d’un cluster auto-conçu, vous devez toutefois prévoir deux types de défaillances : les défaillances au niveau du nœud et les défaillances plus étendues au niveau des zones de disponibilité. Le meilleur plan d'atténuation des risques d'échec traitera deux types de défaillances.

Réduction au maximum de l’impact des défaillances des nœuds

Pour minimiser l'impact d'une panne de nœud lors de l'utilisation de Valkey ou RedisOSS, nous recommandons que votre implémentation utilise plusieurs nœuds dans chaque partition et répartisse les nœuds sur plusieurs zones de disponibilité. Ce processus est automatique pour les caches sans serveur.

Pour les clusters conçus par vos soins sur Valkey ou RedisOSS, nous vous recommandons d'activer le mode multi-AZ sur votre groupe de réplication afin qu'il bascule ElastiCache automatiquement vers une réplique en cas de défaillance du nœud principal.

Si Memcached est exécuté et que vos données sont partitionnées sur plusieurs nœuds, plus les nœuds que vous utilisez seront nombreux, moins la perte de données sera importante en cas de défaillance d'un des nœuds.

Minimiser l'impact des défaillances au niveau des zones de disponibilité

Afin de limiter l'impact d'une défaillance de zone de disponibilité, nous vous recommandons de lancer vos nœuds dans le plus grand nombre de zones de disponibilité disponibles. En répartissant vos nœuds de manière uniforme, AZs vous minimiserez l'impact dans le cas peu probable d'une défaillance de l'AZ. Ce processus est automatique pour les caches sans serveur.

Autres précautions

Si vous utilisez Valkey ou RedisOSS, en plus de ce qui précède, nous vous recommandons de planifier des sauvegardes régulières de votre cluster. Les sauvegardes (instantanés) créent un fichier .rdb, que vous pouvez utiliser pour restaurer votre cache en cas de défaillance ou d’endommagement. Pour de plus amples informations, veuillez consulter Instantané et restauration.