Bonnes pratiques Limites Tarification Surveillance Utilisation de la hiérarchisation des données Restauration des données de la sauvegarde dans des clusters avec la hiérarchisation des données activée

Mise à niveau des données

Les clusters qui comprennent un groupe de réplication et qui utilisent un type de nœud de la famille r6gd ont leurs données hiérarchisées entre la mémoire et le stockage SSD local (disques SSD). La hiérarchisation des données fournit une option de rapport qualité-prix pour les charges de travail Redis en utilisant des disques SSD (Solid State Drive) moins coûteux dans chaque nœud de cluster, en plus du stockage des données en mémoire. Elle est parfaitement adaptée aux charges de travail qui accèdent régulièrement jusqu’à 20 % de leur jeu de données, et pour les applications qui peuvent tolérer une latence supplémentaire lors de l’accès aux données sur SSD.

Sur les clusters avec hiérarchisation des données, ElastiCache contrôle le dernier temps d’accès de chaque élément stocké. Lorsque la mémoire disponible (DRAM) est entièrement consommée, ElastiCache utilise un algorithme utilisé le moins récemment (LRU) pour déplacer automatiquement les éléments rarement consultés de la mémoire vers le SSD. Lorsqu’on accède ensuite aux données SSD, ElastiCache les remet automatiquement et de façon asynchrone en mémoire avant de traiter la demande. Si votre charge de travail n’accède régulièrement qu’à un sous-ensemble de ses données, la hiérarchisation des données est un moyen optimal de mettre à l’échelle votre capacité de manière rentable.

Notez que lors de l'utilisation de la hiérarchisation des données, les clés elles-mêmes restent toujours en mémoire, tandis que le principe du moins récemment utilisé (LRU, Least Recently Used) régit le placement des valeurs en mémoire plutôt que sur le disque. En général, nous recommandons que la taille de vos clés soit inférieure à celle de vos valeurs lorsque vous utilisez la hiérarchisation des données.

La hiérarchisation des données est conçue pour avoir un impact minimal sur les performances des charges de travail des applications. Par exemple, en supposant des valeurs de chaîne de 500 octets, vous pouvez vous attendre à 300 microsecondes de latence supplémentaires en moyenne pour les demandes de données stockées sur le SSD par rapport aux demandes de données en mémoire.

Grâce à la plus grande taille de nœud de hiérarchisation des données (cache.r6gd.16xlarge), vous pouvez stocker jusqu’à 1 pétaoctet dans un seul cluster de 500 nœuds (500 To en utilisant 1 réplica en lecture). La hiérarchisation des données est compatible avec toutes les commandes et structures de données Redis prises en charge dans ElastiCache. Vous n’avez besoin d’aucune modification côté client pour utiliser cette fonction.

Rubriques

Bonnes pratiques
Limites
Tarification
Surveillance
Utilisation de la hiérarchisation des données
Restauration des données de la sauvegarde dans des clusters avec la hiérarchisation des données activée

Bonnes pratiques

Nous recommandons les bonnes pratiques suivantes :

La hiérarchisation des données est parfaitement adaptée aux charges de travail qui accèdent régulièrement jusqu'à 20 % de leur jeu de données, et pour les applications qui peuvent tolérer une latence supplémentaire lors de l'accès aux données sur SSD.
Lors de l'utilisation de la capacité SSD disponible sur les nœuds hiérarchisés en fonction des données, nous recommandons que la taille de la valeur soit supérieure à celle de la clé. Lorsque des éléments sont déplacés entre DRAM et SSD, les clés restent toujours en mémoire et seules les valeurs sont déplacées vers le niveau SSD.

Limites

La hiérarchisation des données présente les limitations suivantes :

Vous ne pouvez utiliser la hiérarchisation des données que sur des clusters faisant partie d’un groupe de réplication.
Le type de nœud que vous utilisez doit appartenir à la famille r6gd, disponible dans les régions suivantes : us-east-2, us-east-1, us-west-2, us-west-1, eu-west-1, eu-central-1, eu-north-1, eu-west-3, ap-northeast-1, ap-southeast-1, ap-southeast-2, ap-south-1, ca-central-1 et sa-east-1.
Le moteur doit être un moteur Redis version 6.2 ou ultérieure.
Vous ne pouvez pas restaurer une sauvegarde d’un cluster r6gd dans un autre cluster sauf s’il utilise également r6gd.
Vous ne pouvez pas exporter une sauvegarde vers Amazon S3 pour les clusters de hiérarchisation des données.
La migration en ligne n'est pas prise en charge pour les clusters exécutés sur le type de nœud r6gd.
La mise à l’échelle n’est pas prise en charge depuis un cluster de hiérarchisation de données (par exemple, un cluster utilisant un type de nœud r6gd) vers un cluster qui n’utilise pas la hiérarchisation des données (par exemple, un cluster utilisant un type de nœud r6g). Pour de plus amples informations, veuillez consulter Mise à l'échelle des clusters ElastiCache for Redis.
La scalabilité automatique n’est pas prise en charge pour les clusters exécutés à l’aide de la hiérarchisation des données. Pour plus d'informations, consultez Auto Scaling des clusters ElastiCache for Redis
La hiérarchisation des données prend uniquement en charge les politiques de mémoire maximale volatile-lru, allkeys-lru et noeviction.
L’enregistrement sans fonction fork n’est pas prise en charge. Pour de plus amples informations, veuillez consulter Implémentation de la sauvegarde et de la synchronisation.
Les éléments de plus de 128 MiB ne sont pas déplacés vers le SSD.

Tarification

Les nœuds R6gd ont une capacité totale 4,8 fois plus élevée (mémoire + SSD) et peuvent vous aider à réaliser des économies de plus de 60 % quand ils s’exécutent au maximum de leur capacité par rapport aux nœuds R6g (mémoire uniquement). Pour plus d’informations, consultez la rubrique Tarification ElastiCache.

Surveillance

ElastiCache for Redis propose des métriques conçues spécifiquement pour contrôler les clusters de performances qui utilisent la hiérarchisation des données. Pour surveiller le ratio d'éléments en DRAM par rapport au SSD, vous pouvez utiliser la métrique CurrItems dans Métriques pour Redis. Vous pouvez calculer le pourcentage comme : (CurrItems avec dimension : Niveau = Mémoire * 100) / (CurrItems sans filtre de dimension). Lorsque le pourcentage d'éléments en mémoire descend en dessous de 5 pour cent, nous vous recommandons d'envisager une montée en puissance pour les clusters en mode cluster activé ou une augmentation d'échelle pour les clusters en mode cluster désactivé. Pour plus d’informations, consultez la rubrique Métriques pour les clusters Redis qui utilisent la hiérarchisation des données à Métriques pour Redis.

Utilisation de la hiérarchisation des données

Lorsque vous créez un cluster dans le cadre d’un groupe de réplication, vous utilisez la hiérarchisation des données en sélectionnant un type de nœud dans la famille r6gd, tel que cache.r6gd.xlarge. La sélection de ce type de nœud active automatiquement la hiérarchisation des données.

Pour plus d'informations sur la création des clusters , consultez Création d'un cluster.

Lorsque vous créez un groupe de réplication à l’aide de AWS CLI, vous utilisez la hiérarchisation des données en sélectionnant un type de nœud de la famille r6gd, tel que cache.r6gd.xlarge et en définissant le paramètre --data-tiering-enabled.

Vous ne pouvez pas désactiver la hiérarchisation des données lorsque vous sélectionnez un type de nœud dans la famille r6gd. Si vous définissez le paramètre --no-data-tiering-enabled, l’opération échouera.

Pour Linux, macOS ou Unix :


aws elasticache create-replication-group \
   --replication-group-id redis-dt-cluster \
   --replication-group-description "Redis cluster with data tiering" \
   --num-node-groups 1 \
   --replicas-per-node-group 1 \
   --cache-node-type cache.r6gd.xlarge \
   --engine redis \   
   --cache-subnet-group-name default \
   --automatic-failover-enabled \
   --data-tiering-enabled

Pour Windows :


aws elasticache create-replication-group ^
   --replication-group-id redis-dt-cluster ^
   --replication-group-description "Redis cluster with data tiering" ^
   --num-node-groups 1 ^
   --replicas-per-node-group 1 ^
   --cache-node-type cache.r6gd.xlarge ^
   --engine redis ^   
   --cache-subnet-group-name default ^
   --automatic-failover-enabled ^
   --data-tiering-enabled

Après avoir exécuté cette opération, une réponse similaire à ceci s’affiche :


{
    "ReplicationGroup": {
        "ReplicationGroupId": "redis-dt-cluster",
        "Description": "Redis cluster with data tiering",
        "Status": "creating",           
        "PendingModifiedValues": {},
        "MemberClusters": [
            "redis-dt-cluster"
        ],
        "AutomaticFailover": "enabled",
        "DataTiering": "enabled",
        "SnapshotRetentionLimit": 0,
        "SnapshotWindow": "06:00-07:00",
        "ClusterEnabled": false,
        "CacheNodeType": "cache.r6gd.xlarge",       
        "TransitEncryptionEnabled": false,
        "AtRestEncryptionEnabled": false
    }
}

Restauration des données de la sauvegarde dans des clusters avec la hiérarchisation des données activée

Vous pouvez restaurer une sauvegarde sur un nouveau cluster avec la hiérarchisation des données activée à l’aide de (Console), (AWS CLI) ou de (API ElastiCache). Lorsque vous créez un cluster à l’aide de types de nœuds de la famille r6gd, la hiérarchisation des données est activée.

Pour restaurer une sauvegarde dans un nouveau cluster avec la hiérarchisation des données activée (console)

Connectez-vous à la AWS Management Console et ouvrez la console ElastiCache à l'adresse https://console.aws.amazon.com/elasticache/.
Dans le volet de navigation de gauche, choisissez Sauvegardes.
Dans la liste des sauvegardes, cochez la case située à gauche du nom de la sauvegarde à restaurer.
Choisissez Restore (Restaurer).
Renseignez la boîte de dialogue Restore Cluster. Veillez à remplir tous les champs obligatoires, ainsi que ceux dont vous ne souhaitez pas conserver la valeur par défaut.
1. ID du cluster : obligatoire. Nom du nouveau cluster.
2. Cluster mode enabled (montée en puissance) (Mode cluster activé (augmentation de la taille des instances)) : choisissez cette option pour un cluster Redis (mode cluster activé).
3. Type de nœud : préciser cache.r6gd.xlarge ou tout autre type de nœud de la famille r6gd.
4. Nombre de partitions : choisissez le nombre de partitions dont vous avez besoin dans le nouveau cluster (API/CLI : groupes de nœuds).
5. Replicas per Shard (Réplicas par partition) : choisissez le nombre de nœuds de réplica en lecture souhaité dans chaque partition.
6. Slots and keyspaces (Emplacements et espaces de clés) : choisissez la répartition des clés entre les partitions. Si vous choisissez de spécifier les répartitions de clés, remplissez le tableau en spécifiant les plages de clés de chaque partition.
7. Zone(s) de disponibilité : spécifiez la façon dont les zones de disponibilité du cluster doivent être sélectionnées.
8. Port : modifiez cette valeur uniquement si vous souhaitez que le nouveau cluster utilise un port différent.
9. Choisir un VPC : choisissez le VPC dans lequel vous souhaitez créer ce cluster.
10. Groupe de paramètres : choisissez un groupe de paramètres vous permettant de disposer d'une mémoire suffisante pour la surcharge Redis correspondant au type de nœud sélectionné.
Lorsque les paramètres vous conviennent, choisissez Create.

Pour plus d'informations sur la création des clusters , consultez Création d'un cluster.

Lorsque vous créez un groupe de réplication à l’aide de l’AWS CLI, la hiérarchisation des données est utilisée par défaut en sélectionnant un type de nœud dans la famille r6gd, tel que cache.r6gd.xlarge et en définissant le paramètre --data-tiering-enabled.

Pour Linux, macOS ou Unix :


aws elasticache create-replication-group \
   --replication-group-id redis-dt-cluster \
   --replication-group-description "Redis cluster with data tiering" \
   --num-node-groups 1 \
   --replicas-per-node-group 1 \
   --cache-node-type cache.r6gd.xlarge \
   --engine redis \   
   --cache-subnet-group-name default \
   --automatic-failover-enabled \
   --data-tiering-enabled \
   --snapshot-name my-snapshot

Pour Linux, macOS ou Unix :


aws elasticache create-replication-group ^
   --replication-group-id redis-dt-cluster ^
   --replication-group-description "Redis cluster with data tiering" ^
   --num-node-groups 1 ^
   --replicas-per-node-group 1 ^
   --cache-node-type cache.r6gd.xlarge ^
   --engine redis ^   
   --cache-subnet-group-name default ^
   --automatic-failover-enabled ^
   --data-tiering-enabled ^
   --snapshot-name my-snapshot

Après avoir exécuté cette opération, une réponse similaire à ceci s’affiche :


{
    "ReplicationGroup": {
        "ReplicationGroupId": "redis-dt-cluster",
        "Description": "Redis cluster with data tiering",
        "Status": "creating",           
        "PendingModifiedValues": {},
        "MemberClusters": [
            "redis-dt-cluster"
        ],
        "AutomaticFailover": "enabled",
        "DataTiering": "enabled",
        "SnapshotRetentionLimit": 0,
        "SnapshotWindow": "06:00-07:00",
        "ClusterEnabled": false,
        "CacheNodeType": "cache.r6gd.xlarge",        
        "TransitEncryptionEnabled": false,
        "AtRestEncryptionEnabled": false
    }
}

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Choix d'un type de réseau

Préparation d'un cluster