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

Brève description

Les causes suivantes sont souvent à l’origine de problèmes de latence élevée dans ElastiCache for Redis :

• Commandes lentes
• Augmentation de l’activité d’échange causée par 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 ElastiCache

Résolution

Résolvez vos problèmes de latences élevées causés par :

Commandes lentes

Redis est principalement à thread unique. Ainsi, lorsqu’une demande tarde à être traitée, les autres clients doivent attendre d’être servis. Cette attente se traduit par une augmentation de la durée totale de traitement des demandes. Utilisez les métriques Amazon CloudWatch pour Redis afin de surveiller la latence moyenne des différentes classes de commandes. De plus, la latence des opérations courantes Redis est calculée en microsecondes. Les métriques CloudWatch sont échantillonnées toutes les minutes et les métriques de latence sont affichées comme agrégat de plusieurs commandes. Une seule commande peut provoquer des résultats inattendus, comme des dépassements de délai, sans que des changements significatifs n’apparaissent dans les graphiques de métriques. Pour récupérer la liste des commandes dont l’exécution est longue, utilisez SLOWLOG GET. Exécutez également la commande slowlog get 128 dans le redis-cli. Pour plus d’informations, consultez SLOWLOG GET sur le site Web de Redis. Consultez également Comment activer Redis Slow Log dans un cluster de cache ElastiCache for Redis ?

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 ?

Voici quelques exemples de commandes complexes :

• KEYS dans les environnements de production sur de grands jeux de données. KEYS balaie la totalité de l’espace de clés à la recherche d’un modèle spécifié. Pour plus d’informations, consultez KEYS sur le site Web de Redis.
• Scripts Lua de longue durée. Pour plus d’informations, consultez Création de scripts via Lua sur le site web de Redis.

Augmentation de l’activité d’échange causée par une utilisation élevée de la mémoire

Redis permute les pages lorsque la pression de la mémoire sur le cluster augmente. Par conséquent, les problèmes de latence et de délai d’expiration sont plus fréquents lorsque les pages de mémoire sont transférées vers et depuis la zone d’échange. Les indicateurs suivants indiquent une augmentation de l’activité d’échange dans les métriques CloudWatch :

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

Pour résoudre les problèmes liés à une augmentation de l’activité d’échange, consultez les ressources suivantes :

• Comment puis-je résoudre les problèmes d’utilisation élevée du processeur dans le cluster ElastiCache for Redis que j’ai conçu ?
• Comment remédier à une augmentation de l’activité d’échange dans mes instances ElastiCache ?

Problèmes liés au réseau

Pour résoudre les problèmes de latences élevées causés par des problèmes liés au réseau, consultez les scénarios suivants :

Latence du réseau entre le client et le cluster ElastiCache
Pour isoler la latence du réseau entre le client et les nœuds du cluster, consultez Comment résoudre les problèmes de performance du réseau entre les instances EC2 Linux ou Windows dans un 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, le type de nœud cache.m6g.large a les mêmes limites réseau que l’instance Amazon EC2 m6g.large. Pour plus d’informations sur la résolution des problèmes de limites du réseau de votre nœud ElastiCache, consultez Limites de réseau. Il est également recommandé de surveiller les performances réseau de votre instance Amazon EC2 et de vérifier votre capacité de bande passante, les performances du paquet par seconde (PPS) et les connexions suivies.

Latence de connexion TCP/SSL

Les clients se connectent aux clusters Redis à l’aide d’une connexion TCP. La création de connexions TCP peut prendre quelques millisecondes. Ce retard peut entraîner des frais généraux supplémentaires pour les opérations Redis de votre application. De plus, le nœud ElastiCache subit davantage de pression sur le processeur. Il est important de contrôler le volume des nouvelles connexions, en particulier lorsque votre cluster utilise la fonctionnalité de chiffrement en transit ElastiCache (TLS). Un volume élevé de connexions ouvertes (NewConnections) et fermées peut affecter les performances du nœud. Pour un grand nombre de connexion, utilisez le regroupement de connexions afin de mettre en cache les connexions TCP établies au sein d’un groupe. Pour implémenter le regroupement de connexions, utilisez votre bibliothèque cliente Redis (si elle est prise en charge) ou créez manuellement votre groupe de connexions. Vous pouvez également utiliser des commandes agrégées comme MSET/MGET ou des pipelines Redis comme technique d’optimisation. Pour plus d’informations, consultez Pipelining Redis sur le site Web de Redis.

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

Il est recommandé de suivre les métriques CloudWatch CurrConnections et NewConnections. Ces métriques surveillent le nombre de connexions TCP acceptées par Redis. Un grand nombre de connexions TCP peut entraîner l’épuisement de la limite de 65 000 clients maximum. Cette limite correspond au nombre maximum de connexions simultanées que vous pouvez avoir par nœud. Pour plus d’informations, consultez Nombre maximum de clients connectés simultanément sur le site Web de Redis. Si vous atteignez la limite de 65 000, vous recevrez l’erreur ERR max number of clients reached. Si des connexions sont ajoutées au-delà de la limite du serveur Linux ou du nombre maximum de connexions suivies, des dépassements de délai de connexion se produisent. Pour plus d’informations sur la manière d’éviter un grand nombre de connexions, consultez Meilleures pratiques pour clients Redis.

Problèmes de latence côté client

Pour déterminer si les ressources côté 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. Assurez-vous que ces ressources n’atteignent pas leurs limites. Si votre application s’exécute sur une instance Amazon EC2, utilisez les métriques CloudWatch pour identifier les problèmes. Utilisez également un outil de surveillance intégré à l’instance Amazon EC2, comme un agent atop ou CloudWatch.

Si les valeurs de configuration du délai d’expiration définies sur l’application sont trop faibles, vous risquez de recevoir des erreurs de délai d’expiration inutiles. Pour corriger ces erreurs, configurez le délai d’expiration côté client afin de laisser suffisamment de temps au serveur pour traiter les demandes et générer des réponses. Pour plus d’informations, consultez Meilleures pratiques pour clients Redis. De plus, les erreurs de délai d’expiration révèlent des informations supplémentaires. Assurez-vous de vérifier les détails de l’erreur de délai d’expiration pour isoler la cause de votre latence. Vérifiez les modèles suivants pour déterminer si la latence est causée par le côté client, le nœud ElastiCache ou le réseau :

• Vérifiez si les temps morts 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’expiration s’appliquent à un nœud Redis spécifique ou à plusieurs nœuds.
• Vérifiez si les délais d’expiration 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. Il s’agit d’une charge de travail intensive en calcul qui peut entraîner des latences. Utilisez la métrique CloudWatch SaveInProgress pour déterminer si la synchronisation est en cours. Pour plus d’informations, consultez Implémentation de la sauvegarde et de la synchronisation.

Événements de cluster ElastiCache

Consultez la section Événements de la console ElastiCache pour connaître la période pendant laquelle la latence a été observée. Vérifiez les activités en arrière-plan comme le remplacement de nœud ou les événements de basculement qui pourraient être provoqués par la maintenance ElastiCache gérée et les mises à jour de service. Vérifiez également les défaillances matérielles inattendues. Vous recevez une notification des événements planifiés via le tableau de bord AWS Health et par e-mail.

Voici un exemple de journal d’événements :

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

Informations connexes

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

Autres mesures de résolution des problèmes stepshttps://kcs.support.aws.dev/article/elasticache-redis-correct-high-latency/2