Comment résoudre les problèmes de latence élevée dans ElastiCache pour Valkey ou ElastiCache for Redis OSS ?

Brève description

Les causes courantes des problèmes de latence élevée dans les clusters ElastiCache pour Valkey ou ElastiCache for Redis OSS sont les suivantes :

• Commandes lentes
• Activité d’échange accrue en raison d'une utilisation élevée de la mémoire
• Problèmes liés au réseau
• Problèmes de latence côté client
• Synchronisation de Redis
• Événements de cluster Amazon ElastiCache

Résolution

Commandes lentes

Les clusters Valkey et Redis OSS étant monothread, ElastiCache ne peut pas servir les clients tant que la requête en cours n'est pas terminée. Ce ralentissement entraîne une augmentation du temps total des requêtes et provoque une latence élevée.

Pour surveiller la latence moyenne, vous pouvez utiliser les métriques Amazon CloudWatch pour Valkey et Redis afin de surveiller des commandes spécifiques. Pour plus d'informations, consultez la section Métriques pour Valkey et Redis OSS.

Pour récupérer une liste de commandes dont le traitement prend au moteur plus de 10 ms, utilisez la commande SLOWLOG GET. Vous pouvez vous connecter au nœud concerné pour exécuter la commande slowlog get 128 dans la valkey-cli.

Aussi, ElastiCache calcule également les opérations Redis courantes avec une latence de l’ordre de la microseconde. CloudWatch échantillonne les métriques toutes les minutes et affiche les métriques de latence sous la forme d'un agrégat de plusieurs commandes. Une seule commande peut engendrer des problèmes mineurs, tels que des délais d'attente, sans modification significative des graphiques de métriques.

Les commandes lentes et longues à exécuter peuvent entraîner une utilisation accrue du processeur sur le nœud ElastiCache. En cas d’augmentation de la métrique EngineCPUUtilization, consultez Comment résoudre les problèmes liés à l’utilisation accrue du processeur dans le cluster ElastiCache for Redis que j’ai conçu ?

Des exemples de commandes complexes susceptibles de ralentir les clusters ElastiCache sont présentés ci-dessous :

• L'utilisation de la commande KEYS dans des environnements de production contenant des jeux de données volumineux : La commande KEYS parcourt l’espace clé entier et recherche les modèles spécifiés. Pour plus d’informations, consultez KEYS sur le site Web de Valkey.
• Scripts Lua qui prennent du temps à s’exécuter : Selon la complexité d'un script ou la taille d'un jeu de données, les scripts Lua peuvent être longs à s’exécuter et entraîner des problèmes de latence.

Activité d’échange accrue en raison d'une utilisation élevée de la mémoire

Lorsque la pression de la mémoire sur le cluster augmente, Redis permute les pages de mémoire. Étant donné que les pages de mémoire sont transférées depuis et vers la zone d’échange, l’échange peut augmenter la latence et provoquer des délais d'attente. Les modifications suivantes apportées aux métriques CloudWatch indiquent une augmentation de l'activité d’échange :

• Augmentation de SwapUsage
• FreeableMemory faible
• Métriques BytesUsedForCache et DatabaseMemoryUsagePercentage élevées

Pour résoudre les problèmes liés à l'augmentation de l'activité d’échange, consultez les articles suivants :

• Comment remédier à une augmentation de l’activité d’échange dans mes instances ElastiCache ?
• Comment puis-je vérifier l’utilisation de la mémoire dans un cluster ElastiCache for Redis que j’ai moi-même créé et mettre en œuvre les bonnes pratiques pour contrôler l’utilisation élevée de la mémoire ?

Problèmes liés au réseau

Les problèmes de réseau peuvent entraîner une latence élevée pour vos clusters. En fonction de votre problème réseau, effectuez les tâches suivantes pour résoudre les problèmes de latence élevée.

Latence du réseau entre le client et le cluster ElastiCache

Pour réduire la latence entre le client et votre cluster ElastiCache, vous pouvez isoler la latence réseau entre le client et les nœuds de cluster. Pour en savoir plus, consultez la section Comment résoudre les problèmes de performances réseau entre les instances EC2 Linux ou Windows d'un cloud privé virtuel (VPC) et un hôte sur site via la passerelle Internet ?

Le cluster atteint les limites du réseau

Un nœud ElastiCache partage les mêmes limites réseau que celles des instances Amazon Elastic Compute Cloud (Amazon EC2) de type correspondant. Par exemple, les limites réseau pour le type de nœud cache.m6g.large et l'instance m6g.large Amazon EC2 sont les mêmes. Pour plus d'informations sur les types de nœuds ElastiCache pris en charge et les limites de bande passante réseau, consultez la section Types de nœuds pris en charge.

Pour résoudre les problèmes liés aux limites du réseau des nœuds ElastiCache, consultez la section Limites liées au réseau.

Remarque : Il est recommandé de surveiller les performances réseau de votre instance Amazon EC2, la capacité de bande passante, les performances du paquet par seconde (PPS) et les connexions suivies.

Latence de connexion TCP/SSL

Lorsque les clients se connectent à des clusters Redis, la création de la connexion TCP peut prendre quelques millisecondes. Pendant cette période, le retard peut entraîner une charge supplémentaire pour vos opérations Redis et le processeur de votre nœud ElastiCache. Lorsque vous disposez de nombreuses connexions nouvelles, la contrainte peut entraîner une latence élevée pour votre réseau.

Pour contrôler le volume de vos connexions et réduire la latence, vous pouvez utiliser un groupe de connexions pour mettre en cache les connexions TCP établies dans un groupe. Pour configurer un groupe de connexions, utilisez votre bibliothèque client Redis. Vous pouvez également créer manuellement votre groupe de connexions.

Pour optimiser votre groupe de connexions, vous pouvez également utiliser des commandes agrégées, telles que MSET ou MGET, ou des pipelines Redis. Pour plus d’informations, consultez la page Pipelining Redis sur le site Web de Redis.

Il existe un grand nombre de connexions sur le nœud ElastiCache

S'il existe un grand nombre de connexions TCP sur un nœud ElastiCache, vous risquez d'épuiser la limite maxclients. Lorsque vous atteignez cette limite, vous obtenez une erreur « ERR nombre maximal de clients atteint » et vous pouvez rencontrer des délais d’expiration de connexion.

Pour réduire la latence élevée, il est recommandé de suivre les métriques CloudWatch CurrConnections et NewConnections. Vous pouvez surveiller ces métriques pour connaître le nombre de connexions TCP de votre nœud ElastiCache. Pour résoudre les problèmes liés à l'épuisement de votre limite maxclients, consultez la section Grand nombre de connexions dans Bonnes pratiques : Clients Redis et Amazon ElastiCache for Redis.

Problèmes de latence côté client

Si vous configurez les ressources client avec des valeurs de délai d’attente trop faibles, vous risquez de recevoir des erreurs de délai d’attente. Pour déterminer si les ressources client entraînent des problèmes de latence, vérifiez l’utilisation de la mémoire, du processeur et du réseau côté client. Si ces ressources sont proches de leurs limites, configurez les valeurs de délai d'attente côté client sur une valeur plus élevée afin que la ressource puisse répondre.

Si votre application s’exécute sur une instance Amazon EC2, utilisez les métriques CloudWatch pour identifier en détail les problèmes. Vous pouvez également utiliser un outil de surveillance intégré à l’instance Amazon EC2, comme atop ou l’agent CloudWatch.

Pour déterminer si le client est à l'origine d'une latence élevée, recherchez les problèmes suivants :

• Vérifiez si les délais d’expiration se produisent fréquemment ou à un moment précis de la journée.
• Vérifiez si les délais d’expiration s’appliquent à un client spécifique ou à plusieurs clients.
• Vérifiez si les délais d’attente s’appliquent à un nœud Valkey ou Redis spécifique ou à plusieurs nœuds.
• Vérifiez si les délais d’attente s’appliquent à un cluster spécifique ou à plusieurs clusters.

Synchronisation de Redis

La synchronisation de Redis est initiée lors d’événements de sauvegarde, de remplacement de nœuds et de mise à l’échelle. Ce processus est une charge de travail intensive en calcul qui peut entraîner des latences.

Pour vérifier si une synchronisation a affecté les performances de votre nœud, vous pouvez consulter la métrique SaveInProgress dans CloudWatch.

Remarque : Pour minimiser les effets sur le trafic utilisateur, il est recommandé de planifier les événements de synchronisation pendant les heures creuses.

Événements de cluster ElastiCache

Si votre cluster ElastiCache comporte un événement de cluster, vous pouvez subir une latence élevée pendant cet événement. Vous pouvez utiliser la console ElastiCache pour vérifier les événements survenus pendant la période de latence. Vérifiez les activités en arrière-plan comme les événements de remplacement de nœud ou de basculement à partir de la maintenance gérée par ElastiCache et les mises à jour de service.

Si vous pensez que des pannes matérielles inattendues ont provoqué une latence élevée, contactez AWS Support.

Remarque : Vous pouvez consulter les notifications d'événements planifiés dans le tableau de bord AWS Health.

Exemple de journal d’événements :

Finished recovery for cache nodes 0001
Recovering cache nodes 0001
Failover from master node cluster_node to replica node cluster_node completed

Informations connexes

Surveillance des bonnes pratiques avec Amazon ElastiCache for Redis à l’aide d’Amazon CloudWatch

Problèmes de connexion persistants

Comment activer la livraison des journaux dans un cluster ElastiCache pour Redis OSS ou ElastiCache pour Valkey ?