Choix de la taille de votre nœud - Amazon ElastiCache
Taille du nœud (Valkey et RedisOSS)Taille du nœud (Memcached)

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.

Choix de la taille de votre nœud

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

Taille du nœud (Valkey et RedisOSS)

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

Répondre aux questions suivantes peut vous aider à déterminer le type de nœud minimal dont vous avez besoin pour votre implémentation de Valkey ou Redis OSS :

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

    Si tel est le cas et que vous utilisez Redis OSS version 5.0.6 ou supérieure, vous pouvez obtenir un meilleur débit et une meilleure latence grâce à notre fonctionnalité d'E/S améliorée, qui, le cas échéantCPUs, est utilisée pour décharger les connexions client, au nom du moteur Redis. OSS Si vous utilisez Redis OSS version 7.0.4 ou supérieure, en plus des E/S améliorées, vous bénéficierez d'une accélération supplémentaire grâce au multiplexage des E/S amélioré, où chaque thread d'E/S réseau dédié achemine les commandes de plusieurs clients vers le OSS moteur Redis, en tirant parti de la capacité de OSS Redis à traiter efficacement les commandes par lots. Dans ElastiCache (RedisOSS) v7.1 et versions ultérieures, nous avons étendu la fonctionnalité améliorée des threads d'E/S pour également gérer la logique de la couche de présentation. Par couche de présentation, nous voulons dire que les threads d'E/S améliorés lisent désormais non seulement les entrées du client, mais les analysent également au format de commande OSS binaire Redis, qui est ensuite transmise 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 OSS 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 dans. 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 Hiérarchisation des données ElastiCache.

    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 OSS utilisez-vous ?

    OSSLes versions de Redis antérieures à la version 2.8.22 vous obligent à réserver davantage de mémoire pour le basculement, le snapshot, la synchronisation et la promotion d'une réplique 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 OSS versions 2.8.22 et ultérieures de Redis utilisent un processus de sauvegarde sans fourche qui nécessite moins de mémoire disponible que le processus précédent.

    Pour plus d’informations, consultez les ressources suivantes :

  • 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 une réplique d'un cluster et lors de l'activation de la fonctionnalité d'ajout de fichier () AOF uniquement. 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 que vous disposez de suffisamment de mémoire pour créer un instantané Valkey ou Redis OSS.

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

    Cluster Valkey ou Redis OSS (mode cluster désactivé)

    Si vous implémentez un cluster Valkey ou Redis OSS (mode cluster désactivé), votre type de nœud doit être capable d'accueillir toutes vos données ainsi que la surcharge nécessaire, comme décrit dans le bullet 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.

    Valkey ou Redis OSS (mode cluster activé) avec plusieurs partitions

    Si vous implémentez un cluster Valkey ou Redis OSS (mode cluster activé) avec plusieurs partitions, le type de nœud doit être capable d'accueillir des 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 vous permettent de placer des ressources telles qu'un ElastiCache cluster dans plusieurs emplacements proches de vos utilisateurs. 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

Pendant que votre cluster est en cours d'exécution, vous pouvez surveiller l'utilisation de la mémoire, l'utilisation du processeur, les accès au cache et les mesures relatives aux erreurs de cache publiées sur 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 CPU de mémoire plus grandes.

Lorsque vous surveillez CPU l'utilisation, n'oubliez pas que Valkey et Redis OSS fonctionnent en un seul thread. Multipliez donc l'CPUutilisation déclarée par le nombre de CPU cœurs pour obtenir cette utilisation réelle. Par exemple, un processeur à quatre cœurs CPU signalant un taux d'utilisation de 20 % est en fait le seul cœur que OSS Redis exécute à 80 % d'utilisation.

Taille du nœud (Memcached)

Les clusters Memcached contiennent un ou plusieurs nœuds avec les données du cluster partitionnées sur les nœuds. Pour cette raison, les besoins en mémoire du cluster et la mémoire d'un nœud sont liés, mais pas identiques. Vous pouvez atteindre la capacité de mémoire de cluster souhaitée, soit en utilisant un petit nombre de nœuds de grande taille ou plusieurs nœuds de petite taille. En outre, à mesure que vos besoins changent, vous pouvez ajouter des nœuds ou en supprimer du cluster, et donc ne payer que pour ce dont vous avez besoin.

La capacité de mémoire totale de votre cluster est calculée en multipliant le nombre de nœuds du cluster par la RAM capacité de chaque nœud après déduction de la surcharge du système. La capacité de chaque nœud est basée sur le type de nœud.

cluster_capacity = number_of_nodes * (node_capacity - system_overhead)

Le nombre de nœuds de dans le cluster est un facteur clé dans la disponibilité de votre cluster Memcached. La défaillance d'un nœud simple peut avoir un impact sur la disponibilité de votre application et sur la charge de votre base de données backend. Dans ce cas, fournit un ElastiCache remplacement pour un nœud défaillant et celui-ci est repeuplé. Pour réduire cet impact sur la disponibilité, répartissez votre mémoire et votre capacité de calcul sur un plus grand nombre de nœuds de plus petite capacité, plutôt que d'utiliser un plus petit nombre de nœuds de grande capacité.

Dans un scénario où vous avez besoin de 35 Go de mémoire cache, vous pouvez utiliser l'une des configurations suivantes :

  • 11 nœuds cache.t2.medium avec 3,22 Go de mémoire et 2 threads chacun = 35,42 Go et 22 threads.

  • 6 nœuds cache.m4.large avec 6,42 Go de mémoire et 2 threads chacun = 38,52 Go et 12 threads.

  • 3 nœuds cache.r4.large avec 12,3 Go de mémoire et 2 threads chacun = 36,90 Go et 6 threads.

  • 3 nœuds cache.m4.xlarge avec 14,28 Go de mémoire et 4 threads chacun = 42,84 Go et 12 threads.

Comparaison des options de nœuds
Type de nœud Mémoire en Go Cœurs Coût horaire* Nœuds nécessaires Mémoire totale (en GiB) Nombre total de cœurs Coût mensuel
cache.t2.medium 3,22 2 0,068 USD 11 35,42 22 538,56 $
cache.m4.large 6,42 2 0,156 USD 6 38,52 12 673,92 $
cache.m4.xlarge 14,28 4 0,311 USD 3 42,84 12 671,76 USD
cache.m5.xlarge 12,93 4 0,311 USD 3 38,81 12 671,76 USD
cache.m6g.large 6,85 2 0,147$ 6 41,1 12 635$
cache.r4.large 12.3 2 0,228 USD 3 36,9 6 492,48 USD
cache.r5.large 13,07 2 0,216 $ 3 39,22 6 466,56 $
cache.r6g.large 13,07 2 0,205$ 3 42,12 6 442$
* Coût horaire par nœud à compter du 8 octobre 2020.
Coût mensuel pour une utilisation à 100 % pendant 30 jours (720 heures).

Ces options permettent d'avoir la même capacité de mémoire, mais une capacité de calcul et un coût différents. Pour comparer les coûts de vos options spécifiques, consultez Amazon ElastiCache Pricing.

Pour les clusters Memcached, une partie de la mémoire disponible sur chaque nœud de est utilisée pour la surcharge de connexion. Pour plus d'informations, consultez Surcharge de la connexion Memcached

L'utilisation de plusieurs nœuds nécessitera la répartition des clés sur tous ces nœuds. Chaque nœud a son propre point de terminaison. Pour faciliter la gestion des terminaux, vous pouvez utiliser ElastiCache la fonction Auto Discovery, qui permet aux programmes clients d'identifier automatiquement tous les nœuds d'un cluster. Pour de plus amples informations, veuillez consulter Identifiez automatiquement les nœuds de votre cluster (Memcached).

Dans certains cas, vous n'êtes peut-être pas certain de la capacité dont vous avez besoin. Si c'est le cas, pour les tests, nous vous recommandons de commencer par un nœud cache.m5.large. Surveillez ensuite l'utilisation de la mémoire, CPU l'utilisation et le taux de réussite du cache à l'aide des ElastiCache métriques publiées sur Amazon CloudWatch. Pour plus d'informations sur CloudWatch les mesures relatives à ElastiCache, voirSurveillance de l'utilisation à l'aide de CloudWatch métriques. Pour la production et les charges de travail plus importantes, les nœuds R5 offrent les meilleures performances et le meilleur rapport RAM qualité-prix.

Si votre cluster n'a pas le taux de réussite souhaité, vous pouvez facilement ajouter d'autres nœuds, ce qui accroît la mémoire disponible totale de votre cluster.

Si votre cluster est limité CPU mais qu'il a un taux de réussite suffisant, configurez un nouveau cluster avec un type de nœud qui fournit une puissance de calcul supérieure.