Pasos comunes para la solución de problemas y prácticas recomendadas

Problemas de conectividad

Si no puedes conectarte a la ElastiCache memoria caché, considera una de las siguientes opciones:

1. Uso de TLS: si se produce un bloqueo de la conexión al dispositivo de ElastiCache punto final, es posible que no esté utilizando TLS en su cliente. Si utiliza ElastiCache Serverless, el cifrado en tránsito siempre está activado. Asegúrese de que su cliente utilice TLS para conectarse a la memoria caché. Obtén más información sobre cómo conectarte a una caché con TLS habilitada aquí.

2. VPC: solo se puede acceder a las ElastiCache cachés desde una VPC. Asegúrese de que la instancia EC2 desde la que accede a la memoria caché y a la ElastiCache memoria caché estén creadas en la misma VPC. Como alternativa, debe habilitar el emparejamiento de VPC entre la VPC en la que reside la instancia de EC2 y la VPC en la que va a crear la memoria caché.

3. Grupos de seguridad: ElastiCache utiliza grupos de seguridad para controlar el acceso a la memoria caché. Considere lo siguiente:

   1. Asegúrese de que el grupo de seguridad utilizado por la ElastiCache memoria caché permita el acceso entrante a la misma desde su instancia EC2. Consulte aquí para obtener información sobre cómo configurar correctamente las reglas de entrada en su grupo de seguridad.

   2. Asegúrese de que el grupo de seguridad utilizado por la ElastiCache memoria caché permita el acceso a los puertos de la memoria caché (6379 y 6380 para los sistemas sin servidor y 6379 de forma predeterminada para los de diseño propio). ElastiCache utiliza estos puertos para aceptar los comandos de Redis OSS. Obtenga más información sobre cómo configurar el acceso a los puertos aquí.

Errores del cliente OSS de Redis

ElastiCache Solo se puede acceder a Serverless mediante los clientes OSS de Redis que admiten el protocolo de modo de clúster de Redis OSS. Se puede acceder a los clústeres de diseño propio desde los clientes OSS de Redis en cualquier modo, según la configuración del clúster.

Si se producen errores de Redis OSS en su cliente, tenga en cuenta lo siguiente:

1. Modo de clúster: si se producen errores de CROSSLOT o errores con el comando SELECT Redis OSS, es posible que esté intentando acceder a una caché habilitada en modo de clúster con un cliente de Redis OSS que no sea compatible con el protocolo de clúster OSS de Redis. ElastiCache Serverless solo es compatible con los clientes OSS de Redis que admiten el protocolo de clúster OSS de Redis. Si desea utilizar Redis OSS en un modo de clúster desactivado (CMD), debe diseñar su propio clúster.

2. Errores de CROSSLOT: si se produce el ERR CROSSLOT Keys in request don't hash to the same slot error, es posible que esté intentando acceder a claves que no pertenecen a la misma ranura en una memoria caché en modo clúster. Como recordatorio, ElastiCache Serverless siempre funciona en modo clúster. Las operaciones con varias claves, las transacciones o los scripts de Lua con varias claves solo están permitidas si todas las claves involucradas están en la misma ranura de hash.

Para obtener más información sobre las mejores prácticas sobre la configuración de los clientes OSS de Redis, consulte esta entrada de blog.

Solución de problemas de alta latencia en Serverless ElastiCache

Si tu carga de trabajo parece experimentar una latencia alta, puedes analizar las SuccessfulWriteRequestLatency métricas CloudWatch SuccessfulReadRequestLatency y comprobar si la latencia está relacionada con ElastiCache Serverless. Estas métricas miden la latencia, que es interna de ElastiCache Serverless; no se incluyen la latencia del lado del cliente ni los tiempos de recorrido de la red entre el cliente y el terminal ElastiCache Serverless.

Solución de problemas de latencia del lado del cliente

Si observa una latencia elevada en el lado del cliente, pero no un aumento correspondiente en CloudWatch SuccessfulReadRequestLatency la latencia del lado del servidor, ni SuccessfulWriteRequestLatency métricas que midan la latencia del lado del servidor, tenga en cuenta lo siguiente:

• Asegúrese de que el grupo de seguridad permita el acceso a los puertos 6379 y 6380: ElastiCache Serverless utiliza el puerto 6379 para el punto final principal y el puerto 6380 para el punto final del lector. Algunos clientes establecen la conectividad con ambos puertos para cada nueva conexión, incluso si la aplicación no utiliza la función de lectura desde réplica. Si su grupo de seguridad no permite el acceso entrante a ambos puertos, el establecimiento de la conexión puede tardar más. Obtenga más información sobre cómo configurar el acceso a los puertos aquí.

Solución de problemas de latencia del lado del servidor

Cierta variabilidad y picos ocasionales no deberían ser motivo de preocupación. Sin embargo, si la Average estadística muestra un aumento brusco y persiste, consulte el Personal Health Dashboard AWS Health Dashboard y su Personal Health Dashboard para obtener más información. Si es necesario, considere la posibilidad de abrir un caso de soporte con AWS Support.

Tenga en cuenta las siguientes mejores prácticas y estrategias para reducir la latencia:

• Habilitar la lectura desde réplica: si su aplicación lo permite, le recomendamos que habilite la función de «lectura desde réplica» en su cliente OSS de Redis para escalar las lecturas y lograr una latencia más baja. Cuando está habilitada, ElastiCache Serverless intenta enrutar las solicitudes de lectura a los nodos de caché de réplica que se encuentran en la misma zona de disponibilidad (AZ) que el cliente, lo que evita la latencia de la red entre zonas de disponibilidad. Tenga en cuenta que habilitar la función de lectura desde réplica en su cliente significa que su aplicación acepta, en última instancia, la coherencia de los datos. Es posible que su aplicación reciba datos antiguos durante algún tiempo si intenta leerlos después de escribirlos en una clave.

• Asegúrese de que la aplicación esté desplegada en las mismas zonas de disponibilidad que la memoria caché: si la aplicación no se despliega en las mismas zonas de disponibilidad que la caché, es posible que observe una mayor latencia en el lado del cliente. Al crear una caché sin servidor, puede proporcionar las subredes desde las que la aplicación accederá a la caché, y ElastiCache Serverless crea puntos de enlace de VPC en esas subredes. Asegúrese de que la aplicación esté implementada en las mismas zonas de disponibilidad. De lo contrario, es posible que la aplicación sufra un salto entre zonas de disponibilidad al acceder a la caché, lo que provocará una mayor latencia del lado del cliente.

• Conexiones de reutilización: las solicitudes ElastiCache sin servidor se realizan a través de una conexión TCP habilitada para TLS mediante el protocolo RESP. El inicio de la conexión (incluida la autenticación de la conexión, si está configurada) lleva tiempo, por lo que la latencia de la primera solicitud es superior a la habitual. Las solicitudes a través de una conexión ya inicializada ofrecen una baja ElastiCache latencia constante. Por este motivo, debería considerar la posibilidad de utilizar la agrupación de conexiones o reutilizar las conexiones OSS de Redis existentes.

• Velocidad de escalado: ElastiCache Serverless escala automáticamente a medida que aumenta la tasa de solicitudes. Un aumento importante y repentino de la tasa de solicitudes, más rápido que la velocidad a la que se escala ElastiCache Serverless, puede provocar un aumento de la latencia durante algún tiempo. ElastiCache Por lo general, la tecnología Serverless puede aumentar rápidamente su tasa de solicitudes admitidas, lo que tarda entre 10 y 12 minutos en duplicar la tasa de solicitudes.

• Inspeccione los comandos de ejecución prolongada: algunos comandos de Redis OSS, incluidos los scripts de Lua o los comandos de estructuras de datos de gran tamaño, pueden ejecutarse durante mucho tiempo. Para identificar estos comandos, ElastiCache publica métricas a nivel de comandos. Con ElastiCache Serverless puedes usar las BasedECPUs métricas.

• Solicitudes limitadas: cuando las solicitudes se limitan en ElastiCache Serverless, es posible que experimente un aumento en la latencia del lado del cliente en su aplicación. Cuando las solicitudes se limitan en ElastiCache Serverless, deberías ver un aumento en la métrica Serverless. ThrottledRequests ElastiCache Consulta la siguiente sección para solucionar problemas con las solicitudes restringidas.

• Distribución uniforme de las claves y las solicitudes: en ElastiCache Redis OSS, una distribución desigual de las claves o solicitudes por ranura puede provocar una sobrecarga de datos, lo que puede provocar una latencia elevada. ElastiCache La tecnología Serverless admite hasta 30 000 ECPU/segundo (90 000 ECPU/segundo cuando se utiliza Read from Replica) en una sola ranura, lo que supone una carga de trabajo que ejecuta comandos SET/GET sencillos. Le recomendamos que evalúe la distribución de las claves y las solicitudes entre las ranuras y garantice una distribución uniforme si la tasa de solicitudes supera este límite.

Solución de problemas de limitación en Serverless ElastiCache

En las arquitecturas orientadas a servicios y en los sistemas distribuidos, la limitación de la velocidad a la que los distintos componentes del servicio procesan las llamadas a la API se denomina limitación. Esto suaviza los picos, controla los desajustes en el rendimiento de los componentes y permite realizar recuperaciones más predecibles cuando se produce un evento operativo inesperado. ElastiCache Serverless está diseñado para este tipo de arquitecturas, y la mayoría de los clientes de Redis OSS incorporan reintentos para las solicitudes limitadas. Cierto grado de limitación no es necesariamente un problema para su aplicación, pero la limitación persistente de una parte sensible a la latencia de su flujo de trabajo de datos puede afectar negativamente a la experiencia del usuario y reducir la eficacia general del sistema.

Cuando las solicitudes se limitan en Serverless, deberías ver un aumento en la ElastiCache métrica Serverless. ThrottledRequests ElastiCache Si observa un número elevado de solicitudes limitadas, tenga en cuenta lo siguiente:

• Velocidad de escalado: ElastiCache Serverless escala automáticamente a medida que se ingieren más datos o aumenta la tasa de solicitudes. Si la aplicación escala más rápido que la velocidad a la que se escala sin servidor, es posible que sus solicitudes se reduzcan mientras que ElastiCache Serverless escala para adaptarse a su carga de trabajo. ElastiCache ElastiCache Por lo general, Serverless puede aumentar el tamaño de almacenamiento rápidamente, y tarda entre 10 y 12 minutos en duplicar el tamaño de almacenamiento de la memoria caché.

• Distribución uniforme de las claves y las solicitudes: en ElastiCache Redis OSS, una distribución desigual de las claves o solicitudes por ranura puede dar lugar a una gran demanda. Una ranura activa puede limitar las solicitudes si la tasa de solicitudes en una sola ranura supera las 30 000 ECPU/segundo, lo que supone una carga de trabajo que ejecuta comandos SET/GET sencillos.

• Leer desde réplica: si tu aplicación lo permite, considera utilizar la función «Leer desde réplica». La mayoría de los clientes OSS de Redis se pueden configurar para «escalar las lecturas» y dirigir las lecturas a los nodos de réplica. Esta función le permite escalar el tráfico de lectura. Además, ElastiCache Serverless enruta automáticamente la lectura de las solicitudes de réplica a los nodos de la misma zona de disponibilidad que la aplicación, lo que reduce la latencia. Cuando la función Read from Replica está habilitada, puede alcanzar hasta 90 000 ECPU/segundo en una sola ranura, para cargas de trabajo con simples comandos SET/GET.

Temas relacionados

• Pasos adicionales de solución de problemas

• ElastiCache mejores prácticas y estrategias de almacenamiento en caché