Choix de la taille de votre nœud

La taille de nœud que vous sélectionnez pour votre cluster a un impact sur les coûts, les performances et la tolérance aux pannes.

Choix de la taille de votre nœud

Pour découvrir les avantages des processeurs Graviton, consultez Processeur AWS Graviton.

Répondez aux questions suivantes pour mieux définir le type de nœud minimum dont vous avez besoin pour votre implémentation Redis :

• Vous attendez-vous à des charges de travail limitées en termes de débit avec plusieurs connexions client ?

  Si tel est le cas et si vous exécutez Redis version 5.0.6 ou ultérieure, vous pouvez obtenir un meilleur débit et une latence inférieure avec notre fonctionnalité d’E/S améliorées, où les CPU disponibles sont utilisés pour décharger les connexions client, pour le compte du moteur Redis. Si vous utilisez Redis version 7.0.4 ou ultérieure, en plus de la fonctionnalité d’E/S améliorées, vous bénéficierez d’une accélération supplémentaire grâce au multiplexage E/S amélioré, dans lequel chaque thread d’E/S du réseau dédié achemine les commandes de plusieurs clients vers le moteur Redis, tirant ainsi parti de la capacité de Redis à traiter efficacement les commandes par lots. Dans ElastiCache for Redis v7.1 et ultérieure, nous avons étendu la fonctionnalité de threads d’E/S améliorées afin de gérer également la logique de la couche de présentation. Par couche de présentation, nous entendons que les threads d’E/S améliorées lisent désormais non seulement les entrées du client, mais les analysent également au format de commande binaire Redis. Elles sont ensuite transférées au thread principal pour exécution, ce qui permet un gain de performance. Pour plus de détails, reportez-vous au billet de blog et à la page des versions prises en charge.

• Avez-vous des charges de travail qui accèdent régulièrement à un faible pourcentage de leurs données ?

  Si tel est le cas et que vous utilisez le moteur Redis version 6.2 ou ultérieure, vous pouvez tirer parti de la hiérarchisation des données en choisissant le type de nœud r6gd. Avec la hiérarchisation des données, les données les moins récemment utilisées sont stockées sur le SSD. Lorsqu’il est récupéré, il y a un faible coût de latence, qui est équilibré par des économies de coûts. Pour de plus amples informations, veuillez consulter Mise à niveau des données.

  Pour de plus amples informations, veuillez consulter Types de nœuds pris en charge.

• Quelle est la quantité totale de mémoire dont vous avez besoin pour vos données ?

  Pour obtenir une estimation générale, prenez la taille des éléments que vous souhaitez mettre en cache. Multipliez cette taille par le nombre d'éléments que vous voulez conserver dans le cache en même temps. Pour obtenir une estimation raisonnable de la taille des éléments, commencez par sérialiser vos éléments de cache, puis comptez les caractères. Divisez ensuite ce nombre sur le nombre de partitions dans votre cluster.

  Pour de plus amples informations, veuillez consulter Types de nœuds pris en charge.

• Quelle version de Redis exécutez-vous ?

  Avec les versions de Redis antérieures à 2.8.22, vous devez réserver davantage de mémoire pour le basculement, les instantanés, la synchronisation et la promotion d'un réplica vers les opérations principales. En effet, vous devez disposer d'une mémoire suffisante pour toutes les écritures qui se produisent au cours du processus.

  Les versions 2.8.22 et ultérieures de Redis ont recours à un processus d'enregistrement sans la fonction fork qui requiert moins de mémoire disponible que le processus précédent.

  Pour plus d’informations, consultez les ressources suivantes :

  • Implémentation de la sauvegarde et de la synchronisation

  • S'assurer d'avoir suffisamment de mémoire pour créer un instantané Redis

• S'agit-il d'une application d'écriture intensive ?

  Les applications d'écriture intensive nécessitent une plus grande capacité de mémoire disponible, la mémoire non utilisée par les données , lors de la création des instantanés ou d'un basculement. Chaque fois que le processus BGSAVE est exécuté, vous devez disposer d'une mémoire suffisante qui n'est pas utilisée par les données pour accueillir toutes les écritures qui se produisent au cours du processus BGSAVE. Par exemple, lors de la prise d'un instantané, lors de la synchronisation d'un cluster principal avec un réplica dans un cluster et lors de l'activation de la fonctionnalité de fichier annexe uniquement (AOF). Autre exemple : lors de la promotion d'un réplica en instance principale (si le mode Multi-AZ est activé). Le pire des cas est lorsque toutes vos données sont réécrites pendant le processus. Dans ce cas, vous devez disposer d'une taille d'instance de nœud avec deux fois plus de mémoire que pour les données uniquement.

  Pour en savoir plus, consultez S'assurer d'avoir suffisamment de mémoire pour créer un instantané Redis.

• Votre implémentation sera-t-elle un cluster Redis (mode cluster désactivé) ou un cluster Redis (mode cluster activé) avec plusieurs partitions ?

  Cluster Redis (mode cluster désactivé)

  Si vous implémentez un cluster Redis (mode cluster désactivé), votre type de nœud doit être en mesure d'accueillir toutes vos données, plus la surcharge nécessaire, comme décrit dans le point précédent.

  Par exemple, supposons que vous estimez que la taille totale de tous vos articles est de 12 Go. Dans ce cas, vous pouvez utiliser un nœud cache.m3.xlarge avec 13,3 Go de mémoire ou un nœud cache.r3.large avec 13,5 Go de mémoire. Toutefois, vous aurez sans doute besoin de davantage de mémoire pour les opérations BGSAVE. Si votre application est très exigeante en matière d'écriture, doublez les besoins en mémoire pour atteindre au moins 24 Go. Utilisez ainsi un cache.m3.2xlarge disposant de 27,9 Go de mémoire ou un cache.r3.xlarge disposant de 30,5 Go de mémoire.

  Redis (mode cluster activé) avec plusieurs partitions

  Si vous implémentez un cluster Redis (mode cluster activé) avec plusieurs partitions, alors le type de nœud doit être en mesure d'accueillir bytes-for-data-and-overhead / number-of-shards octets de données.

  Par exemple, supposons que vous estimez la taille totale de tous les éléments à 12 Go et que vous ayez deux partitions. Dans ce cas, vous pouvez utiliser un nœud cache.m3.large disposant de 6,05 Go de mémoire (12 Go/2). Toutefois, vous aurez sans doute besoin de davantage de mémoire pour les opérations BGSAVE. Si votre application est très exigeante en matière d'écriture, doublez les besoins en mémoire pour atteindre au moins 12 Go par partition. Utilisez ainsi un cache.m3.xlarge disposant de 13,3 Go de mémoire ou un cache.r3.large disposant de 13,5 Go de mémoire.

• Utilisez-vous des Local Zones ?

  Les zones locales (Local Zones) vous permettent de placer des ressources, par exemple un cluster ElastiCache, dans plusieurs emplacements proches de vos utilisateurs finaux. Toutefois, lorsque vous choisissez la taille de votre nœud, sachez que les tailles de nœud disponibles sont limitées aux suivantes pour le moment, quelles que soient les exigences de capacité :

  • Génération actuelle :

    Types de nœuds M5 : cache.m5.large, cache.m5.xlarge, cache.m5.2xlarge, cache.m5.4xlarge, cache.m5.12xlarge, cache.m5.24xlarge

    Types de nœuds R5: cache.r5.large, cache.r5.xlarge, cache.r5.2xlarge, cache.r5.4xlarge, cache.r5.12xlarge, cache.r5.24xlarge

    Types de nœuds T3 : cache.t3.micro, cache.t3.small, cache.t3.medium

Bien que votre cluster soit en cours d'exécution, vous pouvez surveiller les métriques relatives à l'utilisation de la mémoire et du processeur, à l'accès au cache et aux échecs d'accès au cache publiées dans CloudWatch. Vous remarquerez peut-être que votre cluster n'a pas le taux de succès souhaité ou que les clés sont expulsées trop souvent. Dans ces cas, vous pouvez choisir une taille de nœud différente avec des spécifications de mémoire et un CPU plus grands.

Lors de la surveillance de l'utilisation du processeur, n'oubliez pas que le Redis est mono-thread. Ainsi, multipliez l'utilisation du CPU signalée par le nombre de cœurs du processeur pour obtenir que l'utilisation réelle. Par exemple, un processeur quadri-cœurs signalant un taux d'utilisation de 20 % signifie en réalité que le processus Redis mono-cœur a un taux de 80 %.