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 sobre la resolución de problemas y respuestas a preguntas comunes de compatibilidad, visite el Centro de conocimiento de AWS
Temas
Problemas de conectividad
Si no puedes conectarte a la ElastiCache memoria caché, considera una de las siguientes opciones:
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 caché. Obtenga más información sobre cómo conectarte a una caché con TLS habilitado.
VPC: solo se puede acceder a las ElastiCache cachés desde una VPC. Asegúrese de que la EC2 instancia desde la que accede a la caché y a la ElastiCache caché se crean en la misma VPC. Como alternativa, debe habilitar el emparejamiento de VPC entre la VPC en la que EC2 reside la instancia y la VPC en la que va a crear la caché.
Grupos de seguridad: ElastiCache usa grupos de seguridad para controlar el acceso a la memoria caché. Considere lo siguiente:
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. Consulte aquí cómo configurar correctamente las reglas de entrada en su grupo de seguridad.
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 sistemas sin servidor y 6379, de forma predeterminada, para los de diseño propio). ElastiCache utiliza estos puertos para aceptar los comandos OSS de Valkey o Redis. Obtenga más información sobre cómo configurar el acceso a los puertos aquí.
Si la conexión sigue siendo difícil, consulte otros pasos en Problemas de las conexiones persistentes.
Errores del cliente de Valkey o Redis OSS
ElastiCache Solo se puede acceder a Serverless mediante clientes que admitan el protocolo de modo de clúster OSS de Valkey o Redis. Se puede acceder a los clústeres de autodiseño desde los clientes en cualquier modo, según la configuración del clúster.
Si experimenta errores en su cliente, tenga en cuenta lo siguiente:
Modo de clúster: si se producen errores de CROSSLOT o errores con el comando SELECT
, es posible que esté intentando acceder a una caché habilitada en modo de clúster con un cliente OSS de Valkey o Redis que no sea compatible con el protocolo de clúster. ElastiCache Serverless solo admite clientes que admitan el protocolo de clúster OSS de Valkey o Redis. Si desea utilizar Valkey o Redis OSS en el modo de clúster deshabilitado (CMD), debe diseñar su propio clúster. Errores CROSSLOT: si se produce el error
ERR CROSSLOT Keys in request don't hash to the same slot, es posible que esté intentando acceder a claves que no pertenecen a la misma ranura de una caché en modo de clúster. Como recordatorio, ElastiCache Serverless siempre funciona en modo clúster. Las operaciones con varias claves, las transacciones o los scripts de Lua que contengan varias claves solo están permitidas si todas las claves involucradas se encuentran en la misma ranura de hash.
Para conocer más prácticas recomendadas sobre la configuración de los clientes de Valkey o Redis OSS, consulte esta entrada del 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 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 la midan, 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 característica 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 servidor
No hay que preocuparse si hay cierta variabilidad y algunos picos ocasionales. 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 Support.
Tenga en cuenta las siguientes prácticas recomendadas y estrategias para reducir la latencia:
Habilitar Lectura desde réplica: si su aplicación lo permite, le recomendamos que habilite la característica Lectura desde réplica en su cliente de Valkey o Redis OSS para escalar las lecturas y lograr una latencia más baja. Cuando está activado, 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 característica Lectura desde réplica en su cliente implica 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 implementa 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 puntos de enlace de VPC en esas subredes. Asegúrese de que la aplicación esté desplegada en la misma ubicación. AZs De lo contrario, la aplicación podría sufrir un salto entre zonas de disponibilidad al acceder a la caché, lo que provocaría una mayor latencia 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. Iniciar 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 típica. Las solicitudes a través de una conexión ya inicializada ofrecen ElastiCache una baja latencia constante. Por este motivo, debería considerar la posibilidad de utilizar una agrupación de conexiones o reutilizar las conexiones de Valkey o Redis OSS 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 Valkey o Redis OSS, incluidos los scripts de Lua o los comandos de estructuras de datos de gran tamaño, podrían ejecutarse durante mucho tiempo. Para identificar estos comandos, ElastiCache publica las métricas a nivel de comando. Con ElastiCache Serverless puedes usar las
BasedECPUsmé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 Consulte la siguiente sección para solucionar problemas de las solicitudes con limitaciones.
Distribución uniforme de las claves y las solicitudes: en ElastiCache el caso de los OSS de Valkey y Redis, una distribución desigual de las claves o solicitudes por ranura puede dar lugar a un espacio ocupado, lo que puede provocar una latencia elevada. ElastiCache Serverless admite hasta 30 000 ECPUs €/segundo (90 000 ECPUs €/segundo cuando se utiliza Read from Replica) en una sola ranura, en una carga de trabajo que ejecuta comandos SET/GET sencillos. Le recomendamos que evalúe la distribución de las claves y las solicitudes en las ranuras y que garantice una distribución uniforme si la tasa de solicitudes supera este límite.
Solución de ElastiCache problemas de limitación en Serverless
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 OSS de Valkey o Redis 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 con limitación, tenga en cuenta lo siguiente:
Velocidad de escalado: ElastiCache Serverless escala automáticamente a medida que ingieres más datos o aumentas tu tasa de solicitudes. Si su aplicación escala más rápido que la velocidad a la que se escala ElastiCache Serverless, es posible que sus solicitudes se reduzcan mientras ElastiCache Serverless escala para adaptarse a su carga de trabajo. ElastiCache Por lo general, la tecnología 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 el caso de Valkey y Redis OSS, una distribución desigual de las claves o solicitudes por ranura puede provocar una sobrecarga. 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 se ejecuta de forma sencilla. SET/GET commands. Similarly, for ElastiCache for Memcached, a hot key can result in throttling of requests if the request rate exceeds 30,000 ECPUs/second
Lectura desde réplica: si su aplicación lo permite, considere la posibilidad de utilizar la característica Lectura desde réplica. La mayoría de los clientes de Valkey o Redis OSS se pueden configurar para escalar las lecturas con el fin de dirigir las lecturas a los nodos de réplica. Esta característica 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
