Atténuation des défaillances - Amazon ElastiCache for Redis

Atténuation des défaillances

Lors de la mise en œuvre d'Amazon ElastiCache, vous devez bien la planifier afin que les défaillances aient un impact minimal sur vos applications 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 Redis

Lorsque vous exécutez le moteur Redis, vous pouvez réduire au minimum l'impact d'une défaillance au niveau d'un nœud ou d'une zone de disponibilité à l'aide des options suivantes.

Atténuation des défaillances de nœuds

Afin de réduire l'impact des défaillances de nœud Redis, vous avez les options suivantes :

Atténuation des défaillances : Fonctionnalité AOF Redis

Lorsque la fonctionnalité AOF est activée pour Redis, chaque fois que les données sont écrites sur votre cluster Redis, un enregistrement de transaction correspondant est écrit dans un fichier de type AOF Redis. Si votre processus Redis redémarre, ElastiCache crée un cluster de remplacement et le met en service. Vous pouvez ensuite exécuter la fonctionnalité AOF dans le cluster pour le remplir à nouveau avec des données.

Certains des inconvénients liés à l'utilisation de la fonctionnalité AOF de Redis pour atténuer les défaillances de cluster sont les suivants :

  • Cette procédure est longue.

    La création et la mise en service un cluster peuvent prendre plusieurs minutes. Selon la taille du tampon de sortie AOF, son exécution dans le cluster prend encore plus de temps lorsque votre application ne peut pas accéder à votre cluster pour accéder à ses données. Cela force votre application à accéder à la base de données directement.

     

  • L'AOF peut devenir gros.

    Etant donné que chaque écriture dans votre cluster est écrite dans un enregistrement de la transaction, les fichiers de type AOF peuvent devenir plus volumineux plus que le fichier .rdb pour le jeu de données en question. Étant donné qu'Elasticache s'appuie sur le stockage d'instance local, qui est limité en taille, l'activation de la fonctionnalité AOF risque de provoquer des problèmes d'espace disque. Vous pouvez éviter des problèmes d'espace disque en utilisant un groupe de réplication avec Multi-AZ activé.

     

  • L'utilisation de la fonctionnalité AOF ne peut pas vous protéger contre tous les scénarios de défaillance.

    Par exemple, si un nœud échoue en raison d'une panne matérielle sur un serveur physique sous-jacent, ElastiCache met en service un nouveau nœud sur un serveur différent. Dans ce cas, le fichier AOF n'est pas disponible et ne peut pas être utilisé pour récupérer les données.

Pour de plus amples informations, veuillez consulter Append only files (AOF) dans ElastiCache for Redis.

Atténuation des défaillances : Groupes de réplication Redis

Un groupe de réplication Redis se compose d'un nœud principal unique que votre application peut lire ou à partir duquel elle peut écrire, et 1 à 5 nœuds de réplica 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.

Cas d'échec d'un réplica en lecture

  1. ElastiCache détecte l'échec du réplica en lecture.

  2. ElastiCache met le nœud défaillant hors ligne.

  3. ElastiCache lance et met en service un nœud de remplacement de la même zone de disponibilité.

  4. La nouveau nœud est synchronisé sur le nœud principal.

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

Redis Multi-AZ

Vous pouvez activer Multi-AZ sur vos groupes de réplication Redis. 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.

Lorsque Multi-AZ est activé

  1. ElastiCache détecte la défaillance du nœud principal.

  2. ElastiCache promeut le nœud de réplica en lecture avec le moindre décalage de réplication au rang de nœud principal.

  3. La synchronisation des autres réplicas avec le nouveau nœud principal se produit.

  4. ElastiCache active un réplica en lecture dans la zone de disponibilité du réplica principal en échec.

  5. La synchronisation du nouveau nœud avec le réplica principal nouvellement promu se produit.

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 Réduction des temps d'arrêt dans ElastiCache for Redis avec Multi-AZ.

Lorsque Multi-AZ est désactivé

  1. ElastiCache détecte la défaillance du nœud primaire.

  2. ElastiCache met le nœud primaire hors ligne.

  3. ElastiCache crée et met en service un nouveau nœud principal pour remplacer le nœud principal en échec.

  4. ElastiCache synchronise le nouveau nœud principal avec l'un des réplicas existants.

  5. Lorsque la synchronisation est terminée, le nouveau nœud fonctionne en tant que nœud principal du cluster.

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 meilleure protection, nous vous recommandons de lancer les nœuds de votre groupe de réplication dans des zones de disponibilité différentes (AZ). 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é

Afin de minimiser l'impact d'un échec de zone de disponibilité, recherchez vos nœuds dans le plus grand nombre possible de zones de disponibilité.

Quel que soit le nombre de nœuds, 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 vos données de cache. Toutefois, si vous recherchez vos nœuds dans plusieurs zones de disponibilité, une défaillance au niveau d'une zone de disponibilité n'entraînera que la perte des nœuds figurant dans cette 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. Dans la mesure où vos données ne sont pas partitionnées sur des nœuds Redis, vous ne perdrez des données que lorsque le nœud principal ne sera plus accessible.

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

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

Recommendations

Vous devez 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 de l'impact des défaillances

Afin de limiter l'impact d'une défaillance de nœud, nous vous recommandons d'utiliser plusieurs nœuds dans chaque partition et de les répartir entre plusieurs zones de disponibilité.

Lors de l'exécution de Redis, nous vous recommandons d'activer Multi-AZ sur votre groupe de réplication afin que ElastiCache bascule automatiquement vers un réplica en cas de défaillance du nœud principal.

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. La répartition de vos nœuds de manière uniforme dans les zones de disponibilité réduira l'impact d'une défaillance peu probable des zones de disponibilité.

Autres précautions

Si vous exécutez Redis, outre ce qui est indiqué plus haut, 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 cluster en cas de défaillance ou d'endommagement. Pour de plus amples informations, veuillez consulter Backup et restauration d'ElastiCache for Redis .