Pasos adicionales de solución de problemas - Amazon ElastiCache (Redis OSS)
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.

Pasos adicionales de solución de problemas

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

Grupos de seguridad

Los grupos de seguridad son firewalls virtuales que protegen su ElastiCache cliente (instancia EC2, AWS Lambda función, contenedor Amazon ECS, etc.) y ElastiCache la memoria caché. 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 el cliente o ElastiCache el bando han alcanzado los límites.

Puede tener un único grupo de seguridad asignado al mismo tiempo al cliente y al ElastiCache clúster, o grupos de seguridad individuales para cada uno.

En ambos casos, debe permitir el tráfico TCP saliente en el ElastiCache puerto de origen y el tráfico entrante en el mismo puerto. ElastiCache El puerto predeterminado es 11211 para Memcached y 6379 para 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.

Para obtener más información, consulte Patrones de acceso para acceder a un ElastiCache clúster 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. Es posible tener la misma ACL asignada ElastiCache y el mismo recurso del cliente, especialmente 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 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

  • Protocolo: TCP

  • Intervalo de puertos: 1024-65535

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

  • Permitir/Denegar: Permitir

  • Reglas salientes

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

  • Tipo: regla de TCP personalizada

  • Protocolo: TCP

  • Intervalo de puertos: 6379

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

  • Permitir/Denegar: Permitir

ElastiCache ACL de red:

  • Reglas de entrada:

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

  • Tipo: regla de TCP personalizada

  • Protocolo: TCP

  • Intervalo de puertos: 6379

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

  • Permitir/Denegar: Permitir

  • Reglas salientes

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

  • Tipo: regla de TCP personalizada

  • Protocolo: TCP

  • Intervalo de puertos: 1024-65535

  • Fuente: 0.0.0.0/0 (o las subredes del clúster). ElastiCache Tenga en cuenta que el uso de direcciones IP específicas puede crear problemas (en caso de conmutación por error o de escalado 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 ElastiCache clúster se encuentran en subredes diferentes, asegúrese de que sus tablas de enrutamiento les permitan comunicarse entre sí.

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 finales del servicio en función de los nombres de 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, que no utilice el servicio DNS de la VPC) no reconozca los nombres de DNS ElastiCache proporcionados. Asegúrese de que el sistema pueda resolver correctamente los ElastiCache puntos finales mediante herramientas del 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

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

  • Uso de la CPU: Redis OSS es una aplicación de subprocesos múltiples. Sin embargo, la ejecución de cada comando ocurre en un solo subproceso (principal). Por este motivo, ElastiCache proporciona las métricas y. CPUUtilization EngineCPUUtilization EngineCPUUtilizationproporciona el uso de la CPU dedicado al proceso OSS de Redis y 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 los clústeres con el modo de clúster desactivado, el uso de réplicas de lectura se puede realizar creando una configuración de conexión adicional en la aplicación mediante el punto final del lector. 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á descubrir automáticamente la topología del clúster y los nodos de la réplica, habilitar las operaciones de lectura mediante el comando READONLY Redis OSS 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 ElastiCache nodo con miles de puntos NewConnections por minuto indica que la conexión se crea y se utiliza con solo unos pocos comandos, lo que 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. El OSS de Redis proporciona un rendimiento óptimo con un número reducido 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 el ancho de banda: ElastiCache los nodos tienen un ancho de banda 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 mejor práctica para las cargas de trabajo con un uso intensivo de la escritura es utilizar ElastiCache (Redis OSS) con el modo de clúster habilitado para que las escrituras se puedan equilibrar entre varios fragmentos, o ampliarlas a un tipo de nodo con más capacidades de red.

      • Los valores CloudWatchmetrics NetworkBytesIn y NetworkBytesOut proporcionan la cantidad de datos que entran o salen del nodo, respectivamente. ReplicationByteses el tráfico dedicado a la replicación de datos.

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

    • Comandos complejos: los comandos OSS de Redis se envían en un único subproceso, lo que significa que las solicitudes se atienden 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 utiliza la notación «O grande» 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, acceda a https://redis.io/commands.

      Ejemplos de problemas posibles:

      • Secuencias de comandos de Lua: Redis OSS proporciona un intérprete de Lua integrado, que permite la ejecución de scripts en el servidor. Los scripts de Lua en Redis OSS se ejecutan a nivel de motor y son atómicos por definición, lo que significa que no se permitirá ejecutar ningún otro comando o script mientras un script esté en ejecución. Los scripts de Lua ofrecen la posibilidad de ejecutar varios comandos, algoritmos de toma de decisiones, análisis de datos y otros directamente en el motor OSS de Redis. 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. Sí ElastiCache, el tiempo de ejecución de los scripts de Lua está 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 las múltiples modificaciones clave relacionadas 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 DEL es UNLINK un comando asíncrono disponible desde Redis OSS 4. UNLINKdebe preferirse a él siempre que sea posible. DEL A partir de la ElastiCache versión 6x (Redis OSS), el lazyfree-lazy-user-del parámetro hace que el DEL comando se comporte igual que UNLINK cuando está activado. Para obtener más información, consulte Cambios de parámetros de Redis OSS 6.0.

      • 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 forma 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 teclas, independientemente del tipo de datos. ElastiCache (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 los comandos, consulte https://redis.io/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 ENI ID (identificación de interfaz de red elástica) de uno de los ElastiCache nodos disponibles en su 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 ElastiCache clúster o la dirección IP obtenida de las validaciones de DNS anteriores.

  3. Anote o guarde el ID de ENI. Si se muestran varias interfaces, revise la descripción para confirmar que pertenecen al ElastiCache clúster 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 instancia si su ElastiCache cliente se ejecuta en una instancia de Amazon EC2 o en una interfaz de red (si utiliza otro servicio, como AWS Fargate Amazon ECS con red awsvpc AWS Lambda, etc.) y el ID de recurso respectivo (instancia EC2 o ID 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 (Redis OSS) o 11211 para (Memcached). ElastiCache 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.

Para validar la conectividad TCP en el puerto de ElastiCache servicio: en Amazon Linux, Nping está disponible en el paquete nmap y puede probar la conectividad TCP en el ElastiCache puerto, además de proporcionar a la red el tiempo de ida y vuelta para establecer la conexión. Úselo para validar la conectividad de la red y la latencia actual con el ElastiCache clúster, 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 ElastiCache consola, compruebe si el cifrado en tránsito está activado en los detalles ElastiCache del clúster. 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 sistema operativo, pero la aplicación sigue sin poder conectarse a ellos ElastiCache, compruebe si las configuraciones de la aplicación cumplen con los ElastiCache parámetros. Los errores frecuentes son:

  • Su aplicación no admite el modo de ElastiCache clúster y ElastiCache tiene el modo de clúster activado;

  • Su aplicación no es compatible con TLS/SSL y ElastiCache tiene activado el cifrado en tránsito;

  • 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 ElastiCache nodo permite hasta 65 000 conexiones simultáneas en todos los clientes. Este límite se puede monitorizar a través de las CurrConnections métricas CloudWatch activadas. 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 el mismo origen, a la misma IP (ElastiCache nodo) y puerto de destino. El siguiente comando muestra cuántas conexiones existen para un ElastiCache nodo específico (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: compruebe las siguientes CloudWatch métricas de Redis OSS para identificar los posibles límites de red que se estén alcanzando en el nodo: 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 reducir los posibles problemas ElastiCache secundarios:

  • Redis OSS SlowLogs: la configuración ElastiCache predeterminada conserva 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 (Redis OSS) proporciona CloudWatch métricas para monitorear la latencia promedio 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: relacionado con los comandos de Lua Script,,; eval evalsha

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

    • GetTypeCmdsLatency: Lee los comandos, 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, len, lrange, blop, broplpush, linsert, pop, push, pushx, lrem, let, ltrim, rpop, proplpush, rpushx;

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

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

    • SetTypeCmdsLatency: Escribe comandos, 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 los comandos ejecutados desde que se inició el motor OSS de Redis, su número acumulado de ejecuciones, el tiempo total de ejecución y el tiempo medio 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.

  • Backup y replicación: las versiones ElastiCache (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 la versión 2.8.22 de ElastiCache Redis OSS, se introdujo un método de copia de seguridad y replicación sin bifurcación. AWS 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 ElastiCache (Redis OSS) mantiene las conexiones de los clientes establecidas indefinidamente. 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 provocar una saturación en el cliente o ElastiCache en el lado. Cuando no es posible realizar una solución inmediata desde el lado del cliente, algunos administradores establecen un valor de «tiempo de espera» en su grupo de ElastiCache parámetros. El tiempo de espera es el tiempo permitido (medido en segundos) para que las conexiones inactivas persistan. Si el cliente no envía ninguna solicitud durante el período, el motor OSS de Redis finalizará la conexión en cuanto la conexión 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. La configuración predeterminada ElastiCache (Redis OSS) no restringe el tamaño de los búferes de salida normales de los clientes. Si se alcanza el límite de maxmemory, el motor intentará expulsar elementos para cumplir con el uso del búfer. En condiciones de muy poca memoria, ElastiCache (Redis OSS) puede optar por desconectar los clientes que consumen grandes búferes de salida para liberar memoria y conservar 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 flexible para las conexiones de los clientes. La conexión finalizará si se mantiene por encima del límite flexible durante más tiempo del tiempo en segundos definido normal-soft-seconds o si sobrepasa el límite estricto; client-output-buffer-limit

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

    • client-output-buffer-limit-normal-hard-limit: Una conexión que alcance este límite finalizará inmediatamente.

    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 por parte del cliente también pueden afectar a las solicitudes. 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 mediante CloudWatch, sin embargo, tenga en cuenta que la granularidad de los puntos de datos es de 1 minuto (con la monitorización detallada habilitada) o 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 está disponible en la CPUCreditBalance CloudWatch métrica.

    • Los períodos cortos de uso intensivo de la CPU pueden provocar tiempos de espera sin que se refleje en el 100 por ciento de uso. 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. ElastiCache el tráfico se puede optimizar para aprovechar mejor los paquetes de red mediante canalizaciones o comandos que realizan varias operaciones a la vez, por ejemplo, en MGET lugar de hacerlo. 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 saber cuánto tiempo tardó la solicitud en recorrer la red, activarse ElastiCache y recibir respuesta. 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. Usando el mismo PING comando OSS de Redis obtenemosstrace:

    $ 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.