Comment résoudre les problèmes de latence élevée lors de l'utilisation d'ElastiCache pour Redis ?

Brève description

Les raisons suivantes expliquent fréquemment les latences élevées ou les problèmes de délai d'expiration dans ElastiCache pour Redis :

• latence causée par des commandes lentes ;
• utilisation élevée de la mémoire entraînant une augmentation des échanges ;
• latence causée par des problèmes de réseau ;
• problèmes de latence côté client ;
• événements de cluster ElastiCache.

Solution

Latence causée par des commandes lentes

Redis est principalement à thread unique. Ainsi, lorsqu'une demande tarde à être traitée, tous les autres clients doivent attendre pour être traités. Cette attente augmente les latences des commandes. Les commandes Redis ont également une complexité temporelle définie à l'aide de la notation Big O.

Utilisez les métriques Amazon CloudWatch fournies par ElastiCache pour surveiller la latence moyenne des différentes classes de commandes. Il est important de noter que la latence des opérations courantes Redis est calculée en microsecondes. Les métriques CloudWatch sont échantillonnées toutes les minutes, les mesures de latence affichant un agrégat de plusieurs commandes. Ainsi, une seule commande peut entraîner des résultats inattendus, tels que des délais d'expiration, sans afficher de modifications significatives dans les graphiques de mesures. Dans ces situations, utilisez la commande SLOWLOG pour déterminer les commandes prenant le plus de temps pour être exécutées. Connectez-vous au cluster et exécutez la commande slowlog get 128 dans la redis-cli pour récupérer la liste. Pour plus d'informations, consultez Comment activer Redis Slow Log dans un cluster de cache ElastiCache pour Redis ?

Vous pouvez également constater une augmentation de la métrique EngineCPUUtilization dans CloudWatch en raison de commandes lentes bloquant le moteur Redis. Pour plus d'informations, consultez Pourquoi est-ce que je constate une utilisation élevée ou croissante du processeur dans mon cluster ElastiCache for Redis ?

Voici quelques exemples de commandes complexes :

• KEYS dans les environnements de production sur de grands jeux de données, car il balaie la totalité de l'espace de clés à la recherche d'un modèle spécifié.
• Scripts LUA de longue durée.

Utilisation élevée de la mémoire entraînant une augmentation des échanges

Redis commence à permuter les pages lorsque la pression de la mémoire sur le cluster augmente en utilisant plus de mémoire que ce qui est disponible. Les problèmes de latence et de délai d'expiration sont plus fréquents lorsque les pages mémoire sont transférées vers et depuis la zone d'échange. Voici des indications d'une augmentation des permutations dans les métriques CloudWatch :

• augmentation de SwapUsage ;
• mémoire libre très faible ;
• métriques BytesUsedForCache et DatabaseMemoryUsagePercentage élevées.

SwapUsage est une métrique au niveau de l'hôte qui indique la quantité de mémoire échangée. Il est normal que cette métrique affiche des valeurs non nulles, car elle est contrôlée par le système d'exploitation sous-jacent et peut être influencée par de nombreux facteurs dynamiques. Ces facteurs incluent la version du système d'exploitation, les modèles d'activité, etc. Linux échange de manière proactive les clés inactives (rarement consultées par les clients) sur le disque. Ceci constitue une technique d'optimisation permettant de libérer de l'espace mémoire pour les clés les plus fréquemment utilisées.

L'échange devient un problème lorsque la mémoire disponible n'est pas suffisante. Lorsque cela se produit, le système commence à déplacer les pages entre le disque et la mémoire. Plus précisément, si SwapUsage est inférieure à quelques centaines de mégaoctets, cela n'a pas d'impact négatif sur les performances de Redis. Il y a un impact sur les performances si la métrique SwapUsage est élevée et s'il n'y a pas assez de mémoire disponible sur le cluster. Pour plus d'informations, consultez :

• Pourquoi est-ce que je constate une utilisation élevée ou croissante de la mémoire dans mon cluster ElastiCache ?
• Pourquoi l'échange se produit-il dans ElastiCache ?

Latence causée par le réseau

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, utilisez lestests TCP traceroute ou mtr de l'environnement applicatif. Vous pouvez également utiliser un outil de débogage tel que le document d'AWS Systems Manager AWSSupport-SetupIPMonitoringFromVPC (document SSM) pour tester les connexions à partir du sous-réseau client.

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 EC2 m6g.large. Pour plus d'informations sur la vérification des trois composants clés de performance réseau que sont la capacité de bande passante, les performances PPS (paquet par seconde) et le suivi des connexions, consultez Contrôlez les performances réseau de votre instance EC2.

Pour résoudre les problèmes de limites réseau sur votre nœud ElastiCache, consultez Dépannage - Limites liées au réseau.

Latence de connexion TCP/SSL

Les clients se connectent aux clusters Redis à l'aide d'une connexion TCP. La création d'une connexion TCP prend quelques millisecondes. Les millisecondes supplémentaires créent une surcharge additionnelle sur les opérations Redis exécutées par votre application et une pression supplémentaire sur le processeur Redis. Il est important de contrôler le volume des nouvelles connexions lorsque votre cluster utilise la fonctionnalité de chiffrement en transit ElastiCache en raison du temps supplémentaire et de l'utilisation du processeur nécessaires pour une négociation TLS. Un volume élevé de connexions rapidement ouvertes (NewConnections) et fermées peut avoir un impact sur les performances du nœud. Vous pouvez utiliser le pool de connexions pour mettre en cache les connexions TCP établies dans un pool. Les connexions sont ensuite réutilisées chaque fois qu'un nouveau client essaie de se connecter au cluster. Vous pouvez implémenter la mise en pool de connexions à l'aide de votre bibliothèque cliente Redis (si elle est prise en charge), avec une infrastructure disponible pour votre environnement applicatif, ou la créer à partir de zéro. Vous pouvez également utiliser des commandes agrégées telles que MSET/MGET comme technique d'optimisation.

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 mesures 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 est le nombre maximal de connexions simultanées que vous pouvez avoir par nœud. Si vous atteignez la limite de 65 000, vous recevez l'erreur ERR max number of clients reached (ERR nombre maximal de clients atteint). Si d'autres connexions sont ajoutées au-delà de la limite du serveur Linux ou du nombre maximal de connexions suivies alors, les connexions client supplémentaires entraînent des erreurs de délai de connexion. Pour obtenir des information sur la manière d'éviter un grand nombre de connexions, consultez Meilleures pratiques : clients Redis et Amazon ElastiCache for Redis.

Problèmes de latence côté client

La latence et les délais d'expiration peuvent provenir du client lui-même. Vérifiez l'utilisation de la mémoire, du processeur et du réseau côté client pour déterminer si l'une de ces ressources atteint ses limites. Si l'application s'exécute sur une instance EC2, utilisez les mêmes métriques CloudWatch décrites précédemment pour vérifier les goulots d'étranglement. La latence peut se produire dans un système d'exploitation qui ne peut pas être surveillé de manière approfondie par les métriques CloudWatch par défaut. Envisagez d'installer un outil de surveillance dans l'instance EC2, tel qu'un agent atop ou CloudWatch.

Si les valeurs de configuration du délai d'expiration définies côté application sont trop petites, vous risquez de recevoir des erreurs d'expiration de délai inutiles. Configurez le délai d'expiration côté client de manière appropriée pour laisser au serveur suffisamment de temps pour traiter la demande et générer la réponse. Pour plus d'informations, consultez Meilleures pratiques : clients Redis et Amazon ElastiCache for Redis.

L'erreur de délai d'expiration reçue de votre application révèle des informations supplémentaires. Celles-ci incluent notamment : si un nœud spécifique est impliqué, le nom du type de données Redis à l'origine des délais d'expiration, l'horodatage exact du délai d'expiration, etc. Ces informations vous aident à trouver la structure du problème. Utilisez ces informations pour répondre à des questions telles que :

• Les délais d'expiration sont-ils fréquents à un moment précis de la journée ?
• Le délai d'expiration s'est-il produit chez un ou plusieurs clients ?
• Le délai d'expiration s'est-il produit sur un nœud Redis ou sur plusieurs nœuds ?
• Le délai d'expiration s'est-il produit sur un ou plusieurs clusters ?

Utilisez ces réponses pour enquêter sur le client ou sur le nœud ElastiCache le plus probable. Vous pouvez également utiliser le journal de votre application et les journaux de flux VPC pour déterminer si la latence s'est produite côté client, sur le nœud ElastiCache ou sur le réseau.

Synchronisation de Redis

La synchronisation de Redis est lancée lors des événements de sauvegarde, de remplacement 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 telles que 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, ou les défaillances matérielles inattendues. Vous recevez une notification des événements planifiés via le tableau de bord PHD et par e-mail.

Voici un 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 meilleures pratiques avec Amazon ElastiCache for Redis à l'aide d'Amazon CloudWatch

Diagnostiquer les problèmes de latence – Redis

Dépanner ElastiCache pour Redis