¿Cómo soluciono los problemas de alta latencia cuando uso ElastiCache para Redis?

Descripción corta

A continuación, se muestran motivos comunes por los que se producen latencias elevadas o problemas de tiempo de espera en ElastiCache para Redis:

• Latencia causada por comandos lentos.
• Un uso elevado de memoria que se traduce en un mayor intercambio.
• Latencia causada por problemas de red.
• Problemas de latencia del lado del cliente.
• Eventos de clúster de ElastiCache.

Resolución

Latencia causada por comandos lentos

Redis tiene un único hilo. Por lo tanto, cuando una solicitud tarda en servirse, todos los demás clientes deben esperar a que se atienda. Esta espera se suma a las latencias de los comandos. Los comandos de Redis también tienen una complejidad temporal definida mediante la notación Big O.

Utilice las métricas de Amazon CloudWatch que proporciona ElastiCache para supervisar la latencia promedio de las diferentes clases de comandos. Es importante tener en cuenta que las operaciones comunes de Redis se calculan en una latencia de microsegundos. Las métricas de CloudWatch se muestrean cada 1 minuto, y las métricas de latencia muestran un conjunto de varios comandos. Por lo tanto, un solo comando puede provocar resultados inesperados, como tiempos de espera, sin mostrar cambios significativos en los gráficos de métricas. En estas situaciones, utilice el comando SLOWLOG para determinar qué comandos tardan más en completarse. Conéctese al clúster y ejecute el comando slowlog get 128 en la redis-cli para recuperar la lista. Para obtener más información, consulte How do I turn on Redis Slow log in an ElastiCache for Redis cache cluster? (¿Cómo se activa el registro lento de Redis en un clúster de caché de ElastiCache para Redis?)

También puede observar un aumento en la métrica EngineCPUUtilization en CloudWatch debido a que la lentitud de los comandos bloquea el motor de Redis. Para obtener más información, consulte Why am I seeing high or increasing CPU usage in my ElastiCache for Redis cluster? (¿Por qué veo un uso elevado o creciente de la CPU en mi clúster de ElastiCache para Redis?)

Algunos ejemplos de comandos complejos son:

• KEYS en entornos de producción para grandes conjuntos de datos, a medida que barre todo el espacio de claves en busca de un patrón específico.
• Scripts LUA de larga duración.

Uso elevado de memoria que se traduce en un mayor intercambio

Redis comienza a intercambiar páginas cuando hay una mayor presión de memoria en el clúster al usar más memoria de la disponible. Los problemas de latencia y tiempo de espera aumentan cuando las páginas de memoria se transfieren hacia y desde el área de intercambio. A continuación, se muestran métricas de CloudWatch que indican un aumento del intercambio:

• Aumento del valor de SwapUsage.
• Valor de FreeableMemory muy bajo.
• Métricas BytesUsedForCache y DatabaseMemoryUsagePercentage con valores elevados.

SwapUsage es una métrica de nivel de host que indica la cantidad de memoria que se intercambia. Es normal que esta métrica muestre valores distintos a cero porque está controlada por el sistema operativo subyacente y puede verse influenciada por muchos factores dinámicos. Estos factores incluyen la versión del sistema operativo, los patrones de actividad, etc. Linux intercambia de forma proactiva las claves inactivas (a las que rara vez acceden los clientes) al disco como una técnica de optimización para liberar espacio de memoria para las claves de uso más frecuente.

El intercambio se convierte en un problema cuando no hay suficiente memoria disponible. Cuando esto sucede, el sistema comienza a mover páginas hacia adelante y hacia atrás entre el disco y la memoria. De manera específica, un valor de SwapUsage inferior a unos pocos cientos de megabytes no afecta negativamente al rendimiento de Redis. El rendimiento se ve afectado si el valor de SwapUsage es alto y se modifica de forma activa y no hay suficiente memoria disponible en el clúster. Para obtener más información, consulte lo siguiente:

• ¿Por qué veo un uso de memoria elevado o creciente en mi clúster de ElastiCache?
• ¿Por qué se produce el intercambio en ElastiCache?

Latencia causada por la red

Latencia de red entre el cliente y el clúster de ElastiCache

Para aislar la latencia de la red entre el cliente y los nodos del clúster, utilice las rutas de seguimiento TCP o las pruebas de MTR del entorno de la aplicación. O bien, utilice una herramienta de depuración como el documento AWSSupport-SetupIPMonitoringFromVPC de AWS Systems Manager (documento SSM) para probar las conexiones desde la subred del cliente.

El clúster está alcanzando los límites de red

Un nodo de ElastiCache comparte los mismos límites de red que los de las instancias de Amazon Elastic Compute Cloud (Amazon EC2) del tipo correspondiente. Por ejemplo, el tipo de nodo cache.m6g.large tiene los mismos límites de red que la instancia de EC2 m6g.large. Para obtener información sobre cómo comprobar los tres componentes clave del rendimiento de la red, como la capacidad de ancho de banda, el rendimiento de paquetes por segundo (packet-per-second, PPS) y las conexiones rastreadas, consulte Supervisar el rendimiento de la red de la instancia de EC2.

Para solucionar problemas de límites de red en el nodo de ElastiCache, consulte Troubleshooting - Network-related limits (Resolución de problemas: límites relacionados con la red).

Latencia de tiempo de espera del protocolo TCP/SSL

Los clientes se conectan a los clústeres de Redis mediante una conexión TCP. La creación de una conexión TCP tarda unos milisegundos. Los milisegundos adicionales crean una sobrecarga adicional en las operaciones de Redis ejecutadas por su aplicación y una presión adicional en la CPU de Redis. Es importante controlar el volumen de las nuevas conexiones cuando el clúster utiliza la función de cifrado en tránsito de ElastiCache debido al tiempo adicional y al uso de la CPU necesarios para un protocolo TLS. Un volumen elevado de conexiones que se abren y cierran rápidamente (NewConnections) podría afectar al rendimiento del nodo. Puede usar la agrupación de conexiones para almacenar en caché las conexiones TCP establecidas en una agrupación. Las conexiones se reutilizan cada vez que un nuevo cliente intenta conectarse al clúster. Puede implementar la agrupación de conexiones si utiliza su biblioteca cliente de Redis (si se admite), con un marco disponible para su entorno de aplicaciones, o crearlo desde cero. También puede usar comandos agregados como MSET/MGET como técnica de optimización.

Hay un gran número de conexiones en el nodo de ElastiCache

Es una práctica recomendada realizar un seguimiento de las métricas de CloudWatch CurrConnections y NewConnections. Estas métricas supervisan la cantidad de conexiones TCP aceptadas por Redis. Una gran cantidad de conexiones TCP podría llevar al agotamiento del límite de maxclients, establecido en 65 000 clientes. Este límite es el número máximo de conexiones simultáneas que puede tener por nodo. Si alcanza el límite de 65 000, recibirá el error ERR max number of clients reached (Error: número máximo de clientes alcanzado). Si se agregan más conexiones más allá del límite del servidor Linux o del número máximo de conexiones rastreadas, las conexiones de cliente adicionales producen errores de tiempo de espera de conexión agotado. Para obtener recomendaciones sobre cómo evitar un gran número de conexiones, consulte Best practices: Redis clients and Amazon ElastiCache for Redis (Prácticas recomendadas: clientes de Redis y Amazon ElastiCache para Redis).

Problemas de latencia del lado del cliente

La latencia y los tiempos de espera pueden originarse en el propio cliente. Verifique el uso de la memoria, la CPU y la red en el lado del cliente para determinar si alguno de estos recursos está alcanzando sus límites. Si la aplicación se ejecuta en una instancia de EC2, consulte las mismas métricas de CloudWatch analizadas anteriormente para comprobar si hay cuellos de botella. La latencia puede producirse en un sistema operativo que no puede supervisarse a fondo mediante las métricas predeterminadas de CloudWatch. Considere la posibilidad de instalar una herramienta de supervisión dentro de la instancia de EC2, como atop o el agente de CloudWatch.

Si los valores de configuración de tiempo de espera configurados en el lado de la aplicación son demasiado pequeños, es posible que reciba errores de tiempo de espera excedido innecesarios. Configure el tiempo de espera del lado del cliente de forma adecuada para que el servidor disponga de tiempo suficiente para procesar la solicitud y generar la respuesta. Para obtener más información, consulte Best practices: Redis clients and Amazon ElastiCache for Redis (Prácticas recomendadas: clientes de Redis y Amazon ElastiCache para Redis).

El error de tiempo de espera que recibe de su aplicación revela detalles adicionales. Estos detalles incluyen si un nodo específico está implicado, el nombre del tipo de datos de Redis que provoca los tiempos de espera, la marca de tiempo exacta en la que se agotó el tiempo de espera, etc. Esta información le ayuda a encontrar el patrón del problema. Utilice dicha información para responder a preguntas como las siguientes:

• ¿Los tiempos de espera se producen con frecuencia durante un momento específico del día?
• ¿Se agotó el tiempo de espera en uno o más clientes?
• ¿Se agotó el tiempo de espera en un nodo de Redis o en más nodos?
• ¿Se agotó el tiempo de espera en uno o más clústeres?

Utilice estos patrones para investigar al cliente o al nodo de ElastiCache con más posibilidades de ser el causante del problema. También puede usar el registro de la aplicación y los registros de flujo de la VPC para determinar si la latencia se produjo en el lado del cliente, el nodo de ElastiCache o la red.

Sincronización de Redis

La sincronización de Redis se inicia durante los eventos de copia de seguridad, reemplazo y escalado. Se trata de una carga de trabajo de procesamiento intensivo que puede provocar latencias. Utilice la métrica de CloudWatch SaveInProgress para determinar si la sincronización está en curso. Para obtener más información, consulte How synchronization and backup are implemented (Cómo se implementan la sincronización y la copia de seguridad).

Eventos de clúster de ElastiCache

Consulte la sección Events (Eventos) de la consola de ElastiCache para comprobar el período de tiempo en el que se observó la latencia. Verifique si hay actividades en segundo plano, como el reemplazo de nodos o los eventos de conmutación por error que podrían ser causados por el mantenimiento administrado de ElastiCache y las actualizaciones de servicio, o si hay errores inesperados de hardware. Recibirá notificaciones de eventos programados a través del panel de PHD y el correo electrónico.

A continuación, se muestra un ejemplo de registro de eventos:

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

---

Información relacionada

Monitoring best practices with Amazon ElastiCache for Redis using Amazon CloudWatch (Prácticas recomendadas de supervisión con Amazon ElastiCache para Redis utilizando Amazon CloudWatch)

Diagnosing latency issues - Redis (Diagnóstico de errores de latencia: Redis)

Solucionar problemas de Amazon ElastiCache para Redis