Hiérarchisation des données ElastiCache

ElastiCache pour les clusters Valkey ou Redis OSS qui comprennent un groupe de réplication et utilisent un type de nœud de la famille r6gd, leurs données sont hiérarchisées entre la mémoire et le stockage SSD (Solid State Drive) local. La hiérarchisation des données offre une nouvelle option de rapport prix/performances pour les charges de travail Valkey ou Redis OSS en utilisant des disques SSD (SSD) à moindre coût dans chaque nœud du cluster en plus de stocker les 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 ElastiCache clusters avec hiérarchisation des données, ElastiCache surveille l'heure du dernier accès à chaque élément qu'il stocke. Lorsque la mémoire disponible (DRAM) est entièrement consommée, ElastiCache utilise un algorithme de dernière utilisation (LRU) pour déplacer automatiquement les éléments rarement utilisés de la mémoire vers le SSD. Lorsque les données du SSD sont ultérieurement consultées, elles sont ElastiCache automatiquement et de manière asynchrone remises 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 OSS Valkey ou Redis prises en charge dans. ElastiCache Vous n’avez besoin d’aucune modification côté client pour utiliser cette fonction.

Bonnes pratiques

Nous recommandons les bonnes pratiques suivantes :

Limitations

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

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 en savoir plus, consultez PricingElastiCache (Tarification).

Contrôle

ElastiCache propose des mesures conçues spécifiquement pour surveiller les clusters de performance qui utilisent la hiérarchisation des données. Pour contrôler le ratio d'éléments dans la DRAM par rapport au SSD, vous pouvez utiliser la CurrItems métrique de Metrics for Valkey et Redis OSS. Vous pouvez calculer le pourcentage comme suit : (CurrItems avec Dimension : Tier = Memory * 100)/(CurrItems sans filtre dimensionnel).

Si la politique d'expulsion configurée le permet, l'expulsion des éléments ElastiCache commencera lorsqu'il reste moins de 5 % de la mémoire disponible (DRAM). Sur les nœuds configurés avec une politique de non-éviction, les opérations d'écriture recevront une erreur de manque de mémoire.

Il est toujours recommandé d'envisager une mise à l'échelle pour les clusters activés en mode cluster ou une mise à l'échelle pour les clusters désactivés lorsqu'il reste moins de 5 % de mémoire disponible (DRAM). Pour plus d'informations sur la mise à l'échelle, voirDimensionnement des clusters Valkey ou Redis OSS (mode cluster activé). Pour plus d'informations sur les métriques des clusters Valkey ou Redis OSS qui utilisent la hiérarchisation des données, consultez. Métriques pour Valkey et Redis OSS

Utilisation de la hiérarchisation des données

aws elasticache create-replication-group \
   --replication-group-id redis-dt-cluster \
   --replication-group-description "Redis OSS 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

aws elasticache create-replication-group ^
   --replication-group-id redis-dt-cluster ^
   --replication-group-description "Redis OSS 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

{
    "ReplicationGroup": {
        "ReplicationGroupId": "redis-dt-cluster",
        "Description": "Redis OSS 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 en activant la hiérarchisation des données à l'aide de (Console), (AWS CLI) ou (ElastiCache API). 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.

aws elasticache create-replication-group \
   --replication-group-id redis-dt-cluster \
   --replication-group-description "Redis OSS 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

aws elasticache create-replication-group ^
   --replication-group-id redis-dt-cluster ^
   --replication-group-description "Redis OSS 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

{
    "ReplicationGroup": {
        "ReplicationGroupId": "redis-dt-cluster",
        "Description": "Redis OSS 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
    }
}