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.

Si vous avez besoin de plus de 60 nœuds dans un cluster Memcached, ou de plus de 300 nœuds au total dans une AWS région, remplissez le formulaire de demande d'augmentation de ElastiCache limite à l'adresse https://aws.amazon.com/contact-us/ elasticache-node-limit-request/.

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 l'éventualité peu probable d'un tel échec, vous perdrez les données mises en cache dans cette zone, et pas les données mises en cache dans les autres zones de disponibilité.

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é.

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

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. 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é. Ce processus est automatique pour les caches sans serveur.