Problemas de las conexiones persistentes - Amazon ElastiCache
Grupos de seguridadACL de redTablas de enrutamientoResolución de los DNSIdentificación de los problemas con los diagnósticos del lado del servidorValidación de la conectividad de redLímites relacionados con la redUso de la CPUConexiones que terminan desde el lado del servidorSolución de problemas del lado del cliente para instancias de Amazon EC2Análisis del tiempo que se tarda en completar una sola solicitud

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.

Problemas de las conexiones persistentes

Se deben verificar los siguientes elementos al solucionar problemas de conectividad persistentes con ElastiCache:

Grupos de seguridad

Los grupos de seguridad son firewalls virtuales que protegen su cliente ElastiCache (instancia EC2, función de AWS Lambda, contenedor de Amazon ECS, etc.) y la caché de ElastiCache. Además, son firewalls con estado, lo que significa que, después de permitir el tráfico entrante o saliente, las respuestas para ese tráfico se autorizarán automáticamente en el contexto de ese grupo de seguridad específico.

La característica con estado requiere que el grupo de seguridad realice un seguimiento de todas las conexiones autorizadas. Además, hay un límite para las conexiones monitoreadas. Si se alcanza ese límite, las conexiones nuevas producirán errores. Consulte la sección de solución de problemas para obtener ayuda sobre cómo identificar si se han alcanzado los límites en el lado del cliente o en el de ElastiCache.

Puede tener un único grupo de seguridad asignado tanto para el cliente como para el clúster de ElastiCache a la vez o un grupo de seguridad para cada uno de ellos.

En ambos casos, se debe permitir el tráfico de salida del TCP en el puerto ElastiCache desde la fuente y el tráfico de entrada del mismo puerto a ElastiCache. El puerto predeterminado es 11211 para Memcached y 6379 para Valkey o Redis OSS. De forma predeterminada, los grupos de seguridad permiten el tráfico de salida. En este caso, solo se requiere la regla de entrada en el grupo de seguridad de destino.

A fin de obtener más información, consulte Patrones de acceso para obtener la entrada a un clúster de ElastiCache en una Amazon VPC.

ACL de red

Las listas de control de acceso (ACL) de red son reglas sin estado. El tráfico debe estar permitido en ambas direcciones (tanto de entrada como de salida) para tener éxito. Las ACL de red se asignan a subredes, no a recursos específicos. Se puede tener la misma ACL asignada a ElastiCache y al recurso del cliente, sobre todo si se encuentran en la misma subred.

De forma predeterminada, las ACL de red permiten todo el tráfico. Sin embargo, se pueden modificar para denegar o permitir el tráfico. Además, la evaluación de las reglas de las ACL es secuencial, lo que significa que la regla con el número más bajo que coincida con el tráfico lo permitirá o lo denegará. La configuración mínima para permitir el tráfico de Valkey o Redis OSS es:

ACL de red del lado del cliente:

  • Reglas de entrada:

  • Número de regla: preferiblemente inferior a cualquier regla de denegación

  • Tipo: regla de TCP personalizada

  • Protocol: TCP

  • Intervalo de puertos: 1024-65535

  • Fuente: 0.0.0.0/0 (o establezca reglas individuales para las subredes del clúster de ElastiCache)

  • Permitir/Denegar: Permitir

  • Reglas salientes

  • Número de regla: preferiblemente inferior a cualquier regla de denegación

  • Tipo: regla de TCP personalizada

  • Protocol: TCP

  • Intervalo de puertos: 6379

  • Fuente: 0.0.0.0/0 (o las subredes del clúster de ElastiCache. Tenga en cuenta que el uso de las direcciones IP específicas puede causar problemas en caso de que ocurra una conmutación por error o debido a la escalabilidad del clúster)

  • Permitir/Denegar: Permitir

ACL de red de ElastiCache:

  • Reglas de entrada:

  • Número de regla: preferiblemente inferior a cualquier regla de denegación

  • Tipo: regla de TCP personalizada

  • Protocol: TCP

  • Intervalo de puertos: 6379

  • Fuente: 0.0.0.0/0 (o establezca reglas individuales para las subredes del clúster de ElastiCache)

  • Permitir/Denegar: Permitir

  • Reglas salientes

  • Número de regla: preferiblemente inferior a cualquier regla de denegación

  • Tipo: regla de TCP personalizada

  • Protocol: TCP

  • Intervalo de puertos: 1024-65535

  • Fuente: 0.0.0.0/0 (o las subredes del clúster de ElastiCache. Tenga en cuenta que el uso de las direcciones IP específicas puede causar problemas en caso de que ocurra una conmutación por error o debido a la escalabilidad del clúster)

  • Permitir/Denegar: Permitir

Para obtener más información, consulte las ACL de red.

Tablas de enrutamiento

De manera similar a las ACL de red, cada subred puede tener tablas de enrutamiento diferentes. Si los clientes y el clúster de ElastiCache se encuentran en subredes diferentes, asegúrese de que las tablas de enrutamiento permitan la conexión entre ellos.

Los entornos más complejos, los cuales implican varias VPC, enrutamiento dinámico o firewalls de red, pueden dificultar la resolución de los problemas. Consulte Validación de la conectividad de red para confirmar que la configuración de red es adecuada.

Resolución de los DNS

ElastiCache proporciona los puntos de enlace de servicio basados en nombres de dominio (DNS). Los puntos de enlace disponibles son los puntos Configuration, Primary, Reader y Node. Para obtener más información, consulte Búsqueda de puntos de enlace de conexión.

En caso de conmutación por error o de modificación del clúster, la dirección asociada al nombre del punto de conexión puede cambiar y se actualizará de forma automática.

Es posible que la configuración de DNS personalizada (es decir, cuando no se emplea el servicio de DNS de la VPC) no conozca los nombres de dominios que proporciona ElastiCache. Asegúrese de que el sistema pueda resolver los puntos de enlace de ElastiCache con éxito mediante herramientas de sistema como dig (como se muestra a continuación) o nslookup.

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4

Además, la resolución de nombres se puede forzar a través del servicio de DNS de la VPC:

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253
example-001.tihewd.0001.use1.cache.amazonaws.com.
1.2.3.4

Identificación de los problemas con los diagnósticos del lado del servidor

Las métricas de CloudWatch y la información de tiempo de ejecución del motor de ElastiCache son recursos o datos frecuentes para identificar las posibles causas de los problemas de conexión. En general, un buen análisis comienza con los siguientes elementos:

  • Uso de la CPU: Valkey o Redis OSS son aplicaciones de múltiples subprocesos. Sin embargo, la ejecución de cada comando ocurre en un solo subproceso (principal). Por este motivo, ElastiCache proporciona las métricas CPUUtilization y EngineCPUUtilization. La métrica EngineCPUUtilization proporciona el uso de la CPU dedicado al proceso de Valkey o Redis OSS y la CPUUtilization el uso en todas las vCPU. Los nodos con más de una vCPU suelen tener valores diferentes para CPUUtilization y EngineCPUUtilization, el segundo suele ser más alto. Una EngineCPUUtilization alta puede producirse por un número elevado de solicitudes u operaciones complejas que toman demasiado tiempo de CPU en completarse. Ambos se pueden identificar por:

    • Un número elevado de solicitudes: verifique si hay aumentos en otras métricas que coincidan con el patrón de EngineCPUUtilization. Las métricas útiles son:

      • CacheHits y CacheMisses: el número de solicitudes correctas o solicitudes que no han encontrado un elemento válido en la caché Si la proporción de los errores en comparación con los aciertos es alta, la aplicación está perdiendo tiempo y consta de recursos con solicitudes poco útiles.

      • SetTypeCmds y GetTypeCmds: estas métricas, las cuales se encuentran correlacionadas con EngineCPUUtilization, pueden ayudar a entender si la carga es mucho más elevada para las solicitudes de escritura (medida por SetTypeCmds) o lecturas (medida por GetTypeCmds). Si la carga son lecturas en su gran mayoría, el uso de varias réplicas de lectura puede equilibrar las solicitudes en varios nodos y ahorrar las principales para las escrituras. En clústeres con el modo de clúster deshabilitado, el uso de réplicas de lectura se puede realizar mediante la creación de una configuración de conexión adicional en la aplicación mediante el punto de conexión del lector de ElastiCache. Para obtener más información, consulte Búsqueda de puntos de enlace de conexión. Las operaciones de lectura deben enviarse a esta conexión adicional. Las operaciones de escritura se realizarán a través del punto de conexión principal habitual. En el modo de clúster habilitado, se aconseja utilizar una biblioteca que admita réplicas de lectura por defecto. Con los indicadores correctos, la biblioteca podrá identificar automáticamente la topología del clúster y los nodos de la réplica, así como también habilitar las operaciones de lectura mediante el comando de Valkey o Redis OSS READONLY y enviar las solicitudes de lectura a las réplicas.

    • Número elevado de conexiones:

      • CurrConnections y NewConnections: CurrConnection muestra el número de conexiones establecidas en el momento de la recopilación de puntos de datos, mientras que NewConnections muestra cuántas conexiones se crearon en el periodo.

        La creación y la gestión de las conexiones implica una sobrecarga significativa de la CPU. Además, el protocolo de establecimiento de comunicación de tres canales del TCP que se necesita para crear conexiones nuevas afectará negativamente a los tiempos de respuesta generales.

        Un nodo de ElastiCache con miles de NewConnections por minuto indica que una conexión es creada y utilizada por unos pocos comandos, lo cual no es óptimo. Una práctica recomendada es mantener las conexiones establecidas y reutilizarlas para operaciones nuevas. Esto es posible cuando la aplicación de cliente admite e implementa correctamente la agrupación de conexiones o conexiones persistentes. Con la agrupación de conexiones, el número de currConnections no tiene grandes variaciones y NewConnections debe ser lo más bajo posible. Valkey y Redis OSS proporcionan un rendimiento óptimo con un pequeño número de currConnections. Mantener la métrica currConnections en el orden de decenas o centenas minimiza el uso de recursos para admitir conexiones individuales tales como los búferes del lado del cliente y los ciclos de la CPU a fin de servir la conexión.

    • Rendimiento de la red:

      • Determine la banda ancha: los nodos de ElastiCache tienen una banda ancha de red proporcional al tamaño del nodo. Dado que las aplicaciones tienen características diferentes, los resultados pueden variar según la carga de trabajo. Como, por ejemplo, las aplicaciones que tengan una alta tasa de solicitudes pequeñas tienden a afectar más al uso de la CPU que al rendimiento de la red, mientras que las claves más grandes generarán un mayor uso de la red. Por esta razón, se aconseja probar los nodos con la carga de trabajo real para una mejor comprensión de los límites.

        Simular la carga desde la aplicación proporcionaría resultados más precisos. Sin embargo, las herramientas de punto de referencia pueden transmitir una buena noción de los límites.

      • Para los casos en los que las solicitudes son principalmente lecturas, el uso de réplicas para operaciones de lectura aliviará la carga en el nodo primario. Si el caso de uso es predominantemente de escrituras, el uso de muchas réplicas amplificará el uso de la red. Por cada byte escrito en el nodo primario, se enviarán N bytes a las réplicas, siendo N el número de réplicas. La práctica recomendada para las cargas de trabajo intensivas de escritura es usar ElastiCache para Redis con el modo de clúster habilitado a fin de que las escrituras se puedan equilibrar en varias particiones o escalar verticalmente hasta un tipo de nodo con más capacidades de red.

      • Las métricas de CloudWatch NetworkBytesIn y NetworkBytesOut proporcionan la cantidad de datos que entran o salen del nodo, respectivamente. ReplicationBytes es el tráfico dedicado a la reproducción de datos.

      Para obtener más información, consulte Límites relacionados con la red.

    • Comandos complejos: los comandos de Redis OSS se ofrecen en un solo subproceso, lo que significa que las solicitudes se ofrecen de forma secuencial. Un solo comando lento puede afectar a otras solicitudes y conexiones, lo que genera tiempos de espera. El uso de comandos que actúan sobre varios valores, claves o tipos de datos debe efectuarse con cuidado. Las conexiones pueden bloquearse o interrumpirse en función del número de parámetros o del tamaño de sus valores de entrada o de salida.

      Un ejemplo notorio es el comando KEYS. Analiza todo el espacio de claves en la búsqueda de un patrón dado y bloquea la puesta en marcha de otros comandos durante su ejecución. Redis OSS emplea la notación Big O para describir la complejidad de sus comandos.

      El comando de claves tiene una complejidad de tiempo O(N), siendo N el número de claves en la base de datos. Por lo tanto, cuanto mayor sea el número de claves, más lento será el comando. Sin embargo, el comando KEYS puede causar problemas de diferentes maneras. Si no se utiliza un patrón de búsqueda, el comando devolverá todos los nombres de clave disponibles. En las bases de datos con miles o millones de elementos, se creará una enorme salida que saturará a los búferes de red.

      Si se utiliza un patrón de búsqueda, solo las claves que coincidan con el patrón volverán al cliente. No obstante, el motor todavía barrerá todo el espacio de claves en búsqueda de dicho patrón y el tiempo para completar el comando será el mismo.

      Una alternativa para KEYS es el comando SCAN. Vuelve a repetir el proceso sobre el espacio de claves y limita las iteraciones en un número específico de elementos, al evitar bloqueos prolongados en el motor.

      El escaneo tiene el parámetro COUNT, el cual se utiliza para establecer el tamaño de los bloques de iteración. El valor predeterminado es 10 (10 elementos por iteración).

      En función del número de elementos en la base de datos, los bloques de valores COUNT pequeños requerirán más iteraciones para completar un análisis completo, mientras que los valores más grandes mantendrán al motor ocupado durante más tiempo en cada iteración. Mientras que los valores de conteo pequeños harán SCAN más lento en las bases de datos de gran tamaño, los valores más elevados pueden causar los mismos problemas presentados para KEYS.

      Por ejemplo, ejecutar el comando SCAN con un valor de conteo en 10 requerirá 100 000 repeticiones en una base de datos con 1 millón de claves. Si el tiempo promedio de ida y vuelta de la red es de 0,5 milisegundos, cerca de 50 000 milisegundos (50 segundos) se utilizarán para transferir solicitudes.

      Por otro lado, si el valor de conteo fuera 100 000, se requerirá una sola iteración y solo se gastarían 0,5 ms para transferirla. Sin embargo, el motor se encontraría completamente bloqueado para otras operaciones hasta que el comando termine de analizar todo el espacio de claves.

      Además de KEYS, existen otros comandos que son potencialmente dañinos si no se utilizan correctamente. Para ver una lista de todos los comandos, junto con su complejidad de tiempo correspondiente, vaya a Valkey and Redis OSS commands.

      Ejemplos de problemas posibles:

      • Scripts de Lua: Redis proporciona un intérprete de Lua incrustado, lo que permite la ejecución de scripts en el servidor. Los scripts de Lua en Valkey y Redis OSS se ejecutan en el motor y son atómicos por definición, lo que significa que, mientras se está ejecutando un script, no se permitirá la ejecución de otro comando o script. Los scripts de Lua ofrecen la posibilidad de ejecutar diferentes comandos, algoritmos de toma de decisiones, análisis de datos, entre otros, directamente en el motor. Mientras que la atomicidad de los scripts y la posibilidad de descargar la aplicación son tentadoras, los scripts deben emplearse con cuidado y para pequeñas operaciones. En ElastiCache, el tiempo de ejecución de los scripts de Lua se encuentra limitado a 5 segundos. Los scripts que no se hayan escrito en el espacio de claves se interrumpirán de manera automática después del periodo de 5 segundos. Para evitar la corrupción de datos y las inconsistencias, el nodo realizará una conmutación por error si la ejecución del script no se ha completado en 5 segundos y ha tenido alguna escritura durante su ejecución. Las transacciones son la alternativa para garantizar la coherencia de varias modificaciones de claves del mismo grupo en Redis OSS. Una transacción permite la ejecución de un bloque de comandos al observar las claves existentes en busca de modificaciones. Si alguna de las claves observadas cambia antes de la finalización de la transacción, se descartan todas las modificaciones.

      • Eliminación masiva de elementos: el comando DEL acepta varios parámetros, los cuales son los nombres clave que se eliminarán. Las operaciones de eliminación son síncronas y llevarán mucho tiempo de CPU si la lista de parámetros es grande, o si contiene una lista, un conjunto, un conjunto ordenado o un hash grandes (estructuras de datos que contienen varios subelementos). En otras palabras, incluso la eliminación de una sola clave puede tomar un tiempo considerable si tiene muchos elementos. La alternativa a DEL es UNLINK, que es un comando asíncrono disponible desde Redis OSS 4. Se debe preferir UNLINK a DEL siempre que sea posible. A partir de ElastiCache para Redis OSS 6x, el parámetro lazyfree-lazy-user-del hace que el comando DEL se comporte como UNLINK cuando se habilita. Para obtener más información, consulte Redis OSS 6.0 Parameter Changes.

      • Comandos que actúan sobre varias claves: se mencionó el comando DEL como un comando que acepta varios argumentos y su tiempo de ejecución será directamente proporcional a eso. Sin embargo, Redis OSS proporciona muchos más comandos que funcionan de manera similar. Por ejemplo, los comandos MSET y MGET permiten la inserción o recuperación de varias claves de cadena a la vez. Su uso puede resultar beneficioso para reducir la latencia de la red inherente a varios comandos SET o GET individuales. Sin embargo, una lista de parámetros extensa afectará al uso de la CPU.

        Aunque el uso de la CPU por sí sola no es la causa de los problemas de conectividad, dedicar demasiado tiempo a procesar uno o varios comandos a través de varias claves puede causar interrupciones en otras solicitudes y aumentar el uso general de la CPU.

        El número y el tamaño de las claves afectarán a la complejidad del comando y, en consecuencia, al tiempo de finalización.

        Otros ejemplos de comandos que pueden actuar sobre varias claves son HMGET, HMSET, MSETNX, PFCOUNT, PFMERGE, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SUNION, SUNIONSTORE, TOUCH, ZDIFF, ZDIFFSTORE, ZINTER y ZINTERSTORE.

      • Comandos que actúan sobre varios tipos de datos: Redis OSS también proporciona comandos que actúan sobre una o varias claves, independientemente de su tipo de datos. ElastiCache para Redis OSS proporciona la métrica KeyBasedCmds para supervisar dichos comandos. Esta métrica suma la ejecución de los siguientes comandos en el periodo seleccionado:

        • Complejidad O(N):

          • KEYS

        • O(1)

          • EXISTS

          • OBJECT

          • PTTL

          • RANDOMKEY

          • TTL

          • TYPE

          • EXPIRE

          • EXPIREAT

          • MOVE

          • PERSIST

          • PEXPIRE

          • PEXPIREAT

          • UNLINK (O(N) para recuperar la memoria. No obstante, la tarea de recuperación de memoria ocurre en un subproceso aparte y no bloquea el motor.

        • Tiempos de complejidad diferentes según el tipo de datos:

          • DEL

          • DUMP

          • Se estima que el comando RENAME tiene una complejidad O(1), pero ejecuta DEL internamente. El tiempo de ejecución variará en función del tamaño de la clave que ha sido renombrada.

          • RENAMENX

          • RESTORE

          • SORT

        • Hash de gran tamaño: un hash es un tipo de datos que permite una sola clave con varios subelementos de valor de clave. Cada hash puede almacenar 4 294 967 295 elementos y las operaciones en hash grandes pueden volverse costosas. Del mismo modo que KEYS, los hashes tienen el comando HKEYS con una complejidad de tiempo O(N), siendo N el número de elementos en el hash. Se recomienda emplear HSCAN antes que HKEYS para evitar comandos de larga ejecución. Los comandos HDEL, HGETALL, HMGET, HMSET y HVALS se deben utilizar con precaución en hashes grandes.

      • Otras estructuras de big data: además de los hashes, existen otras estructuras de datos que pueden ser pesadas para la CPU. Los conjuntos, las listas, los conjuntos ordenados y los Hyperloglogs también pueden demorar en gestionarse en función del tamaño y de los comandos utilizados. Para obtener más información sobre esos comandos, consulte Valkey and Redis OSS commands.

Validación de la conectividad de red

Luego de revisar las configuraciones de red relacionadas con la resolución de DNS, los grupos de seguridad, las ACL de red y las tablas de enrutamiento, la conectividad se puede validar con el VPC Reachability Analyzer y las herramientas del sistema.

Reachability Analyzer probará la conectividad de red y confirmará si se cumplen todos los requisitos y permisos. Para las siguientes pruebas necesitará el ID de ENI (Identificación de interfaz de red elástica) de uno de los nodos de ElastiCache disponibles en la VPC. Para ello, puede realizar lo siguiente:

  1. Diríjase a https://console.aws.amazon.com/ec2/v2/home?#NIC:

  2. Filtre la lista de interfaces por el nombre del clúster de ElastiCache o por la dirección IP obtenida de las validaciones de DNS.

  3. Anote o guarde el ID de ENI. Si se muestran varias interfaces, revise la descripción para confirmar que pertenecen al clúster de ElastiCache correcto y elija una de ellas.

  4. Continúe con el siguiente paso.

  5. Cree una ruta de análisis en https://console.aws.amazon.com/vpc/home?#ReachabilityAnalyzer y elija las siguientes opciones:

    • Tipo de fuente: elija instance (instancia) si su cliente de ElastiCache se ejecuta en una instancia de Amazon EC2 o Network Interface (Interfaz de red) si utiliza otro servicio, tal como AWS Fargate Amazon ECS con la red awsvpc, AWS Lambda, etc. y el ID de recurso correspondiente (instancia EC2 o ID de ENI);

    • Tipo de destino: elija Network Interface (Interfaz de red) y seleccione la ElastiCache ENI (ENI de ElastiCache) de la lista.

    • Puerto de destino: especifique 6379 para ElastiCache para Redis o 11211 para ElastiCache para Memcached. Estos son los puertos definidos con la configuración predeterminada y en este ejemplo se supone que no se modifican.

    • Protocolo: TCP

Cree la ruta de análisis y espere unos momentos para obtener el resultado. Si no se puede acceder al estado, abra los detalles del análisis y revise el Explorador de análisis para conocer los detalles en los que se bloquearon las solicitudes.

Si se han superado las pruebas de accesibilidad, proceda a la verificación a nivel del sistema operativo.

Validación de la conectividad de TCP en el puerto de servicios de ElastiCache: en Amazon Linux, Nping se encuentra disponible en el paquete nmap y puede probar la conectividad de TCP en el puerto de ElastiCache, así como proporcionar el tiempo de ida y vuelta de la red para establecer la conexión. Utilice esta opción para validar la conectividad de red y la latencia actual al clúster de ElastiCache, como se muestra a continuación: 

$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC
SENT (0.0495s) TCP ...
(Output suppressed )

Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.08 seconds

De forma predeterminada, nping envía 5 sondas con un retraso de 1 segundo entre ellas. Puede utilizar la opción “-c” para aumentar el número de sondas y “-delay” a fin de cambiar el tiempo en que se envía una prueba nueva.

Si las pruebas con el VPC Reachability Analyzer funcionan, pero fracasan con nping, pida al administrador del sistema que revise las reglas de firewall basadas en host, las reglas de enrutamiento asimétrico o cualquier otra restricción posible a nivel de sistema operativo.

En la consola de ElastiCache, verifique si el Cifrado en tránsito se encuentra habilitado en los detalles del clúster de ElastiCache. Si el cifrado en tránsito se encuentra habilitado, confirme si la sesión de TLS se puede establecer con el siguiente comando:

openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379

Se espera un gran resultado si la conexión y la negociación de TLS son exitosas. Verifique el código de retorno que se encuentra disponible en la última línea, el valor debe ser 0 (ok). Si OpenSSL devuelve algo diferente, verifique el motivo del error en https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS.

Si se han superado todas las pruebas de infraestructura y de sistema operativo pero la aplicación sigue sin poder conectarse a ElastiCache, verifique si las configuraciones de la aplicación cumplen con la configuración de ElastiCache. Los errores frecuentes son:

  • La aplicación no admite el modo clúster de ElastiCache y ElastiCache tiene el modo de clúster habilitado.

  • La aplicación no es compatible con TLS/SSL y ElastiCache tiene el cifrado en tránsito habilitado.

  • La aplicación es compatible con TLS/SSL, pero no tiene los indicadores de configuración correctos ni las entidades de certificación de confianza.

Límites relacionados con la red

  • Número máximo de conexiones: hay límites estrictos para conexiones simultáneas. Cada nodo de ElastiCache permite hasta 65 000 conexiones simultáneas en todos los clientes. Este límite se puede monitorear a través de las métricas CurrConnections en CloudWatch. Sin embargo, los clientes también tienen sus límites para las conexiones de salida. En Linux, verifique el rango de puertos efímeros permitido con el comando:

    # sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999

    En el ejemplo anterior, se permitirán 28231 conexiones desde la misma fuente a la misma dirección IP de destino (nodo de ElastiCache) y puerto. El siguiente comando muestra cuántas conexiones existen para un nodo de ElastiCache concreto (IP 1.2.3.4):

    ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l

    Si el número es demasiado alto, es posible que el sistema se sobrecargue al intentar procesar las solicitudes de conexión. Se recomienda considerar la implementación de técnicas tales como la agrupación de conexiones o conexiones persistentes para controlar las conexiones con mayor facilidad. Siempre que sea posible, configure el grupo de conexiones para limitar el número máximo de conexiones a unos pocos cientos. Además, se recomienda seguir la lógica del retardo para controlar los tiempos de espera u otras excepciones de conexión a fin de evitar la pérdida de conexión en caso de problemas.

  • Límites de tráfico de red: verifique las siguientes métricas de CloudWatch para Redis OSS con el objetivo de identificar los posibles límites de la red que ha alcanzado el nodo de ElastiCache:

    • NetworkBandwidthInAllowanceExceeded/NetworkBandwidthOutAllowanceExceeded: paquetes de red configurados porque el rendimiento superó el límite de banda ancha agregado.

      Es importante tener en cuenta que cada byte escrito en el nodo primario se replicará en N réplicas, siendo N el número de réplicas. Es posible que los clústeres con tipos de nodos pequeños, varias réplicas y solicitudes de escritura intensivas no puedan afrontar al retraso de la reproducción. En estos casos, es una práctica recomendada escalar verticalmente (cambiar el tipo de nodo), escalar horizontalmente (agregar particiones en clústeres en modo de clúster habilitado) y disminuir el número de réplicas o el de escrituras.

    • NetworkConntrackAllowanceExceeded: paquetes configurados porque se ha superado el número máximo de conexiones rastreadas en todos los grupos de seguridad asignados al nodo. Es probable que las conexiones nuevas fallen durante este periodo.

    • NetworkPackets PerSecondAllowanceExceeded: se ha superado el número máximo de paquetes por segundo. Las cargas de trabajo basadas en una alta tasa de solicitudes muy pequeñas pueden alcanzar este límite antes de la banda ancha máxima.

    Las métricas mencionadas son una manera ideal de confirmar que los nodos alcanzan sus límites de red. No obstante, los límites también son identificables por periodos de estancamiento en las métricas de la red.

    Si dichos periodos se observan durante largos plazos de tiempo, es probable que se produzca un retraso en la reproducción, un aumento de los bytes utilizados para caché y un deterioro en la memoria que se puede liberar, en el intercambio alto y en el uso de la CPU. Las instancias de Amazon EC2 también tienen límites de red a los que se puede realizar un seguimiento mediante las Métricas de los controladores de ENA. Las instancias de Linux con compatibilidad de red mejorada y los controladores de ENA 2.2.10, o más recientes, pueden controlar los contadores de límites con el comando:

    # ethtool -S eth0 | grep "allowance_exceeded"

Uso de la CPU

La métrica de uso de la CPU es el punto de partida de la investigación y los siguientes elementos pueden ayudar a mermar los posibles problemas en el lado de ElastiCache:

  • Registros lentos de Redis OSS: la configuración predeterminada de ElastiCache retiene los últimos 128 comandos que tardaron más de 10 milisegundos en completarse. El historial de comandos lentos se mantiene durante el tiempo de ejecución del motor y se perderá en caso de interrupción o de reinicio. Si la lista alcanza 128 entradas, los eventos antiguos se eliminarán para crear espacio para otros nuevos. El tamaño de la lista de eventos lentos y el tiempo de ejecución que se considera lento puede modificarse a través de los parámetros slowlog-max-len y slowlog-log-slower-than en un grupo de parámetros personalizados. La lista de registros lentos se puede recuperar al ejecutar SLOWLOG GET 128 en el motor, siendo 128 los últimos 128 comandos lentos informados. Cada entrada cuenta con los siguientes campos:

    1) 1) (integer) 1 -----------> Sequential ID
   2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
   3) (integer) 4823378 -----> Time in microseconds to complete the command.
   4) 1) "keys" -------------> Command
      2) "*" ----------------> Arguments 
   5) "1.2.3.4:57004"-> Source

    El evento anterior ocurrió el 26 de diciembre, a las 19:26:07 UTC, tardó 4,8 segundos (4823 ms) en completarse y fue causado por el comando KEYS solicitado desde el cliente 1.2.3.4.

    En Linux, la marca de tiempo puede convertirse con la fecha del comando:

    $ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020

    Con Python:

    >>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)

    O en Windows con PowerShell:

    PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime      : 12/26/2020 7:26:07 PM
UtcDateTime  
                : 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date          : 12/26/2020 12:00:00 AM
Day           : 26
DayOfWeek    
                : Saturday
DayOfYear     : 361
Hour          : 19
Millisecond   : 0
Minute        : 26
Month        
                : 12
Offset        : 00:00:00Ticks         : 637446075670000000
UtcTicks     
                : 637446075670000000
TimeOfDay     : 19:26:07
Year          : 2020

    Muchos comandos lentos en un corto periodo de tiempo (el mismo minuto o menos) son motivo de preocupación. Revise la naturaleza de los comandos y cómo se pueden optimizar (consulte los ejemplos anteriores). Si los comandos con complejidad de tiempo O(1) son frecuentes, verifique los demás factores para el elevado uso de la CPU mencionado anteriormente.

  • Métricas de latencia: ElastiCache para Redis OSS proporciona métricas de CloudWatch para supervisar la latencia media de diferentes clases de comandos. El punto de datos se calcula al dividir el número total de ejecuciones de comandos en la categoría por el tiempo total de ejecución en el periodo. Es importante entender que los resultados de la métrica de latencia son un agregado de varios comandos. Un solo comando puede provocar resultados inesperados, como tiempos de espera, sin un impacto significativo en las métricas. En tales casos, los eventos de registro lento serían una fuente de información más precisa. La siguiente lista contiene las métricas de latencia disponibles y los comandos respectivos que les afectan.

    • EvalBasedCmdsLatency: relacionada con los comandos de lenguaje de scripting Lua, eval, evalsha;

    • GeoSpatialBasedCmdsLatency: geodist, geohash, geopos, georadius, georadiusbymember, geoadd;

    • GetTypeCmdsLatency: comandos de lectura, independientemente del tipo de datos;

    • HashBasedCmdsLatency: hexists, hget, hgetall, hkeys, hlen, hmget, hvals, hstrlen, hdel, hincrby, hincrbyfloat, hmset, hset, hsetnx;

    • HyperLogLogBasedCmdsLatency: pfselftest, pfcount, pfdebug, pfadd, pfmerge;

    • KeyBasedCmdsLatency: comandos que pueden actuar sobre diferentes tipos de datos: dump, exists, keys, object, pttl, randomkey, ttl, type, del, expire, expireat, move, persist, pexpire, pexpireat, rename, renamenx, restoreK, sort, unlink;

    • ListBasedCmdsLatency: lindex, llen, lrange, blpop, brpop, brpoplpush, linsert, lpop, lpush, lpushx, lrem, lset, ltrim, rpop, rpoplpush, rpush, rpushx;

    • PubSubBasedCmdsLatency: psubscribe, publish, pubsub, punsubscribe, subscribe, unsubscribe;

    • SetBasedCmdsLatency: scard, sdiff, sinter, sismember, smembers, srandmember, sunion, sadd, sdiffstore, sinterstore, smove, spop, srem, sunionstore;

    • SetTypeCmdsLatency: comandos de escritura, independientemente del tipo de datos;

    • SortedSetBasedCmdsLatency: zcard, zcount, zrange, zrangebyscore, zrank, zrevrange, zrevrangebyscore, zrevrank, zscore, zrangebylex, zrevrangebylex, zlexcount, zadd. zincrby, zinterstore, zrem, zremrangebyrank, zremrangebyscore, zunionstore, zremrangebylex, zpopmax, zpopmin, bzpopmin, bzpopmax;

    • StringBasedCmdsLatency: bitcount, get, getbit, getrange, mget, strlen, substr, bitpos, append, bitop, bitfield, decr, decrby, getset, incr, incrby, incrbyfloat, mset, msetnx, psetex, set, setbit, setex, setnx, setrange;

    • StreamBasedCmdsLatency: xrange, xrevrange, xlen, xread, xpending, xinfo, xadd, xgroup, readgroup, xack, xclaim, xdel, xtrim, xsetid;

  • Comandos de tiempo de ejecución de Redis OSS:

    • info commandstats: proporciona una lista de comandos ejecutados desde que se inició el motor, el número de ejecuciones acumuladas, el tiempo total de ejecución y el tiempo promedio de ejecución por comando.

    • client list: proporciona una lista de clientes conectados actualmente e información relevante como el uso de los búferes, el último comando ejecutado, entre otros.

  • Copia de seguridad y replicación: las versiones de ElastiCache para Redis OSS anteriores a la 2.8.22 utilizan un proceso bifurcado para crear copias de seguridad y procesar sincronizaciones completas con las réplicas. Este método puede incurrir en una sobrecarga significativa de la memoria para casos de uso intensivos de escritura.

    A partir de ElastiCache Redis OSS 2.8.22, AWS introdujo un método de copia de seguridad y de replicación sin ramificaciones. El método nuevo puede retrasar las escrituras a fin de evitar errores. Ambos métodos pueden causar periodos de mayor uso de la CPU y dar lugar a tiempos de respuesta más altos, lo que, en consecuencia, conlleva a tiempos de espera del cliente durante su ejecución. Siempre verifique si los errores del cliente se producen durante el periodo de copia de seguridad o si la métrica SaveInProgress fue 1 en el periodo. Se aconseja programar el periodo de copia de seguridad para periodos de baja utilización con el objetivo de minimizar los posibles problemas con los clientes o los errores de la copia de seguridad.

Conexiones que terminan desde el lado del servidor

La configuración predeterminada de ElastiCache para Redis OSS mantiene las conexiones de cliente establecidas por tiempo indefinido. Sin embargo, en algunos casos, la interrupción de la conexión puede ser deseable. Por ejemplo:

  • Los errores en la aplicación cliente pueden hacer que se olviden las conexiones y que se mantengan establecidas con un estado inactivo. Esto se denomina “fuga de conexión”. Su consecuencia es un aumento constante en el número de conexiones establecidas que se observaron en la métrica CurrConnections. Este comportamiento puede generar una saturación en el lado cliente o en el de ElastiCache. Cuando no se puede encontrar una solución inmediata desde el lado del cliente, algunos administradores establecen un valor de “tiempo de espera” en su grupo de parámetros de ElastiCache. El tiempo de espera es el tiempo permitido (medido en segundos) para que las conexiones inactivas persistan. Si el cliente no envía una solicitud durante el periodo, el motor terminará la conexión tan pronto como alcance el valor de tiempo de espera. Los valores de tiempo de espera pequeños pueden dar lugar a desconexiones innecesarias de manera que los clientes necesitarán ocuparse correctamente de ellas y volver a conectarse, lo que genera retrasos.

  • La memoria empleada para almacenar claves se comparte con los búferes del cliente. Los clientes lentos con grandes solicitudes o respuestas pueden exigir una cantidad significativa de memoria para operar sus búferes. Las configuraciones predeterminadas de ElastiCache para Redis OSS no restringen el tamaño de los búferes de salida frecuentes del cliente. Si se alcanza el límite de maxmemory, el motor intentará expulsar elementos para cumplir con el uso del búfer. En condiciones de memoria extremadamente baja, ElastiCache para Redis OSS puede optar por desconectar clientes que consumen búferes de salida de clientes grandes a fin de liberar memoria y retener el estado del clúster.

    Se puede limitar el tamaño de los búferes de cliente mediante configuraciones personalizadas por lo que cuando un cliente alcance ese límite se desconectará. No obstante, los clientes deben ser capaces de resolver desconexiones inesperadas. Los parámetros para manejar el tamaño de los búferes para los clientes regulares son los siguientes:

    • client-query-buffer-limit: tamaño máximo de una sola solicitud de entrada;

    • client-output-buffer-limit-normal-soft-limit: límite bajo para las conexiones de cliente. La conexión se interrumpirá si permanece por encima del límite bajo durante más tiempo que el tiempo en segundos definido en client-output-buffer-limit-normal-soft-seconds o si alcanza el límite alto;

    • client-output-buffer-limit-normal-soft-seconds: tiempo permitido para las conexiones que superan el client-output-buffer-limit-normal-soft-limit;

    • client-output-buffer-limit-normal-hard-limit: una conexión que alcance este límite se interrumpirá de inmediato.

    Además de los búferes de los clientes frecuentes, las siguientes opciones controlan el búfer para los nodos de réplica y los clientes de publicación/suscripción:

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-replica-soft-seconds;

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-pubsub-soft-limit;

    • client-output-buffer-limit-pubsub-soft-seconds;

    • client-output-buffer-limit-pubsub-hard-limit;

Solución de problemas del lado del cliente para instancias de Amazon EC2

La carga y la capacidad de respuesta en el lado del cliente también pueden afectar a las solicitudes a ElastiCache. Los límites de la instancia EC2 y del sistema operativo deben revisarse con cuidado mientras se solucionan problemas de conectividad intermitente o de tiempo de espera. Algunos puntos clave a observar:

  • CPU:

    • El uso de la CPU de la instancia EC2: asegúrese de que la CPU no se encuentre saturada o cerca del 100 %. El análisis histórico se puede realizar a través de CloudWatch, sin embargo, tenga en cuenta que la granularidad de los puntos de datos es de 1 minuto (con el monitoreo detallado habilitado) o de 5 minutos.

    • Si utiliza instancias EC2 ampliables, asegúrese de que no se haya agotado el saldo de crédito de la CPU. Esta información se encuentra disponible en la métrica de CloudWatch CPUCreditBalance.

    • Los periodos cortos de uso elevado de la CPU pueden generar tiempos de espera que no repercuten en su uso total en CloudWatch. Estos casos requieren un monitoreo en tiempo real con herramientas de sistema operativo como top, ps y mpstat.

  • Network

    • Verifique si el rendimiento de la red se encuentra por debajo de los valores aceptables de acuerdo con las capacidades de la instancia. Para obtener más información, consulte Tipos de instancia de Amazon EC2

    • En instancias que dispongan de un controlador de red mejorado ena, verifique las estadísticas de ENA para los tiempos de espera o los límites excedidos. Las siguientes estadísticas son útiles para confirmar la saturación de los límites de red:

      • bw_in_allowance_exceeded/bw_out_allowance_exceeded: número de paquetes moldeados debido a un rendimiento excesivo de entrada o de salida;

      • conntrack_allowance_exceeded: número de paquetes descartados debido a los límites de seguimiento de conexiones de los grupos de seguridad. Las conexiones nuevas fallarán cuando este límite se encuentre saturado.

      • linklocal_allowance_exceeded: número de paquetes descartados debido a solicitudes excesivas de metadatos de instancia, NTP a través de DNS de la VPC El límite es de 1024 paquetes por segundo para todos los servicios.

      • pps_allowance_exceeded: número de paquetes descartados debido a una proporción excesiva de paquetes por segundo. Se puede alcanzar el límite de PPS cuando el tráfico de red consiste en miles o millones de solicitudes muy pequeñas por segundo. El tráfico de ElastiCache se puede optimizar para aprovechar los paquetes de red a través de canalizaciones o comandos que realizan varias operaciones a la vez tal como MGET en lugar de GET.

Análisis del tiempo que se tarda en completar una sola solicitud

  • En la red: Tcpdump y Wireshark (tshark en la línea de comandos) son herramientas útiles para comprender cuánto tiempo se tomó la solicitud en viajar por la red, en alcanzar al motor de ElastiCache y en regresar. En el próximo ejemplo se resalta una sola solicitud que se creó con el siguiente comando: 

    $ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG

    Del mismo modo que el comando anterior, tcpdump se encontraba en ejecución y volvió:

    $ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
    > 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
    28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
    1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
    IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
    211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

    De la salida anterior podemos confirmar que el protocolo de establecimiento de comunicación de tres canales de TCP se completó en 222 microsegundos (918091 - 917869) y el comando ping se envió y devolvió en 173 microsegundos (918295 - 918122).

    Desde la solicitud hasta la interrupción de la conexión pasaron 438 microsegundos (918307 - 917869). Esos resultados confirmarían que los tiempos de respuesta de la red y del motor son buenos por lo que la investigación puede centrarse en otros componentes.

  • En el sistema operativo: Strace puede ayudar a identificar brechas de tiempo a nivel de sistema operativo. El análisis de las aplicaciones reales sería mucho más extenso y se aconseja utilizar depuradores o perfiles de aplicaciones especializados. El siguiente ejemplo solo muestra si los componentes del sistema operativo base funcionan como se esperaba, de lo contrario, podría requerirse una investigación adicional. Con el mismo comando PING de Redis OSS con strace obtenemos:

    $ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
    6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
    (+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
    (+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
    (+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
    65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
    0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
    (Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
    (+ 0.003569) +++ exited with 0 +++

    En el ejemplo anterior, el comando tardó un poco más de 54 milisegundos en completarse (752110 - 697712 = 54398 microsegundos).

    Se necesitó una cantidad significativa de tiempo, cerca de 20 ms, para representar a nc y realizar la resolución de nombres (de 697712 a 717890). Luego, se necesitaron 2 ms para crear el socket de TCP (745659 a 747858) y 0,4 ms (747858 a 748330) a fin de enviar y recibir la respuesta para la solicitud.