Pasos comunes de solución de problemas y prácticas recomendadas con ElastiCache - Amazon ElastiCache

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Pasos comunes de solución de problemas y prácticas recomendadas con ElastiCache

En los temas siguientes se proporcionan consejos para solucionar los errores y problemas que puedan surgir al utilizarlos. ElastiCache Si se encuentra con un problema que no se muestra aquí, puede utilizar el botón de feedback de esta página para notificarlo.

Para obtener más consejos de solución de problemas y respuestas a las preguntas de soporte más comunes, visite el Centro de AWS conocimiento

Problemas de conectividad

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

  1. UsoTLS: Si la conexión se interrumpe al intentar conectarse a su ElastiCache terminal, es posible que no la esté utilizando TLS en su cliente. Si utiliza ElastiCache Serverless, el cifrado en tránsito siempre está activado. Asegúrese de que su cliente lo esté utilizando TLS para conectarse a la memoria caché. Obtén más información sobre cómo conectarte a una caché TLS habilitada.

  2. VPC: solo se puede acceder a las ElastiCache cachés desde unVPC. Asegúrese de que la EC2 instancia desde la que accede a la memoria caché y a la ElastiCache memoria caché se crean en la misma VPC instancia. Como alternativa, debes habilitar la VPCinterconexión entre el VPC lugar en el que reside la EC2 instancia y el VPC lugar en el que estás creando la caché.

  3. Grupos de seguridad: ElastiCache usa 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 la EC2 instancia. Consulta aquí para obtener información sobre cómo configurar correctamente las reglas de entrada en tu 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 usa estos puertos para aceptar comandos de Valkey o Redis. OSS Obtenga más información sobre cómo configurar el acceso a los puertos aquí.

Si la conexión sigue siendo difícil, Problemas de conexión persistentes consulta otros pasos.

Errores en los clientes de Valkey o Redis OSS

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

Si se producen errores en el cliente, tenga en cuenta lo siguiente:

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

  2. CROSSLOTerrores: 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 OSS clientes de Valkey o 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 observas una latencia elevada en el lado del cliente, pero no un aumento correspondiente en CloudWatch SuccessfulReadRequestLatency la latencia SuccessfulWriteRequestLatency del lado del servidor, ten 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 OSS cliente Valkey o 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 la AZs misma ubicación que la caché: si la aplicación no se despliega en la misma AZs ubicación 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 VPC puntos de conexión en esas subredes. Asegúrese de que la aplicación esté desplegada en la misma ubicación. AZs 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 TCP conexión TLS habilitada 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ías considerar la posibilidad de utilizar la agrupación de conexiones o reutilizar las conexiones Valkey o Redis existentes. OSS

  • 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 Valkey o Redis, incluidos OSS 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 comando. 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 el ElastiCache caso de Valkey y RedisOSS, una distribución desigual de las claves o solicitudes por espacio puede provocar una sobrecarga de datos, lo que puede provocar un aumento de la latencia. ElastiCache La tecnología Serverless admite hasta 30 000 ECPUs €/segundo (90 000 ECPUs €/segundo cuando se utiliza la función de lectura desde réplica) en una sola ranura, lo que supone una carga de trabajo que ejecuta simples comandos/. SET GET Te recomendamos que evalúes la distribución de las claves y las solicitudes entre las ranuras y que te asegures de que la distribución es uniforme en caso de que la tasa de solicitudes supere este límite.

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

En las arquitecturas orientadas a los servicios y los sistemas distribuidos, limitar la velocidad a la que los distintos componentes del servicio procesan las API llamadas se denomina limitación. Esto reduce los picos, controla los desajustes en el rendimiento de los componentes y permite que las recuperaciones sean más predecibles cuando se produce un imprevisto operativo. ElastiCache Serverless está diseñado para este tipo de arquitecturas, y la mayoría de los clientes de Valkey o Redis incorporan OSS 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 se 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 el ElastiCache caso de Valkey o RedisOSS, una distribución desigual de las claves o solicitudes por espacio puede resultar en un espacio ocupado. Si la tasa de solicitudes en una sola ranura es superior a 30 000 ECPUs €/segundo, se pueden limitar las solicitudes, lo que supone una carga de trabajo que ejecuta simples comandos/. SET GET

  • Leer desde réplica: si tu aplicación lo permite, considera la posibilidad de utilizar la función «Leer desde réplica». La mayoría de los OSS clientes de Valkey o 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 ECPUs €/segundo en una sola ranura, para cargas de trabajo con simples comandos/. SET GET

Temas relacionados