¿Cómo puedo solucionar problemas de alta latencia en los clústeres del Acelerador de Amazon DynamoDB (DAX)?

6 minutos de lectura
0

Mis solicitudes de lectura o escritura en el Acelerador de Amazon DynamoDB (DAX) tienen una latencia alta. ¿Cómo se soluciona este problema?

Resolución

Hay varios motivos por los que puede recibir latencia en sus solicitudes. Consulte cada uno de los posibles problemas que aparecen a continuación para solucionar su latencia.

El clúster o el nodo están experimentando una carga elevada

La latencia suele deberse a un clúster o nodo que experimenta una carga elevada en el clúster DAX. Esta latencia puede verse afectada aún más si configura el cliente con una URL de nodo único en lugar de la URL del clúster. En este caso, si el nodo sufre algún problema durante una carga alta, las solicitudes del cliente sufren latencia o limitaciones.

Para resolver la latencia y la limitación causadas por una carga elevada en clústeres o nodos individuales, utilice el escalado horizontal o el escalado vertical.

Configuración incorrecta en el cliente DAX

Si reduce el parámetro withMinIdleConnectionSize, es probable que aumente la latencia en todo el clúster de DAX. Este parámetro establece el número mínimo de conexiones inactivas con el clúster de DAX. Para cada solicitud, el cliente utilizará una conexión inactiva disponible. Si no hay ninguna conexión disponible, el cliente establecerá una nueva. Por ejemplo, si el parámetro se establece en 20, hay un mínimo de 20 conexiones inactivas con el clúster de DAX.

El cliente mantiene un grupo de conexiones. Cuando una aplicación realiza una llamada a la API para DynamoDB o DAX, el cliente concede una conexión del grupo de conexiones. A continuación, el cliente realiza la llamada a la API y devuelve la conexión al grupo. Sin embargo, el grupo de conexiones tiene un límite superior. Si realiza una gran cantidad de llamadas de API al DAX a la vez, es posible que superen el límite del grupo de conexiones. En este caso, algunas solicitudes deben esperar a que se completen otras antes de obtener las concesiones del grupo de conexiones. Esto hace que las solicitudes formen una cola en el nivel del grupo de conexiones. Como resultado, la aplicación experimenta un aumento en la latencia de ida y vuelta.

Por lo tanto, para reducir los picos de tráfico periódicos en su aplicación, ajuste los parámetros setMinIdleConnectionSize, getMinIdleConnectionSize y withMinIdleConnectionSize. Estos parámetros desempeñan un papel clave en la latencia de un clúster de DAX. Configúrelos para sus llamadas a la API, de modo que DAX utilice un número adecuado de conexiones inactivas sin necesidad de restablecer nuevas conexiones.

Faltan elementos en la caché

Si una solicitud de lectura omite un elemento, DAX envía la solicitud a DynamoDB. DynamoDB procesa las solicitudes mediante lecturas coherentes posteriores y, a continuación, devuelve los elementos al DAX. El DAX los almacena en la memoria caché de elementos y luego los devuelve a la aplicación. La latencia en la tabla de DynamoDB subyacente puede provocar latencia en la solicitud.

Los errores de caché suelen ocurrir por dos motivos:

1.    Lecturas con coherencia fuerte: DAX no almacena en caché las lecturas con coherencia fuerte para el mismo elemento. Esto provoca una pérdida de memoria caché porque las entradas omiten el DAX y se recuperan desde la propia tabla de DynamoDB. Puede utilizar lecturas coherentes posteriores para resolver este problema, pero tenga en cuenta que DynamoDB primero debe leer los datos para que se almacenen en caché.

2.    Política de expulsión en el DAX: los datos consultados que ya están expulsados de la memoria caché se pierden. El DAX usa tres valores diferentes para determinar las expulsiones de la memoria caché:

  • Los clústeres de DAX utilizan un algoritmo de usado menos recientemente (Least Recently Used, LRU) para priorizar los elementos. Los elementos con la prioridad más baja se expulsan cuando la memoria caché está llena.
  • El DAX usa un valor de tiempo de vida (TTL) para el período de tiempo en que los elementos están disponibles en la memoria caché. Cuando se supera el valor TTL de un artículo, se desaloja el artículo.
    Nota: Si utiliza el valor TTL predeterminado de cinco minutos, compruebe si está consultando los datos después del tiempo de TTL.
  • El DAX utiliza la funcionalidad de escritura directa para eliminar los valores más antiguos a medida que se escriben valores nuevos. Esto ayuda a mantener la caché de elementos de DAX coherente con el almacenamiento de datos subyacente con una sola llamada a la API.

Para ampliar el valor de TTL de sus elementos, consulte Configuring TTL settings (Configuración de los ajustes de TTL).
Nota: No puede modificar un grupo de parámetros mientras esté en uso en una instancia de DAX en ejecución.

También pueden producirse errores de caché cuando se aplican parches de mantenimiento a un clúster de DAX. Utilice varios clústeres de nodos para reducir este tiempo de inactividad.

Períodos de mantenimiento

La latencia puede producirse durante el período de mantenimiento semanal, especialmente si hay actualizaciones de software, parches o cambios en el sistema en los nodos del clúster. En la mayoría de los casos, otros nodos disponibles que no están en mantenimiento gestionan correctamente las solicitudes. Un clúster con un gran número de solicitudes durante un mantenimiento intenso puede sufrir errores.

Para reducir las posibilidades de latencia o error, configure el período de mantenimiento para que coincida con la hora de menor actividad. Hacerlo permite que el clúster se actualice durante un período de menor carga de solicitudes.

Latencia en la tabla de DynamoDB

Con las operaciones de escritura, los datos se escriben primero en la tabla de DynamoDB y, a continuación, en el clúster de DAX. La operación solo se realiza de manera correcta si los datos se escriben correctamente tanto en la tabla como en DAX. La latencia en la tabla de DynamoDB subyacente puede provocar latencia en la solicitud. Para reducir dicha latencia, consulte How can I troubleshoot high latency on an Amazon DynamoDB table? (¿Cómo puedo solucionar problemas de latencia alta en una tabla de Amazon DynamoDB?)

Para seguir configurando DynamoDB según los requisitos de latencia de su aplicación, consulte Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications (Ajustar la configuración de las solicitudes HTTP del AWS Java SDK para las aplicaciones de Amazon DynamoDB con reconocimiento de latencia).

Tiempo de espera de solicitud

El parámetro setIdleConnectionTimeout determina el tiempo de espera para las conexiones inactivas y setConnectTimeout determina el tiempo espera para las conexiones con el clúster de DAX. Estos dos parámetros se refieren a los tiempos de espera de los grupos de conexiones, lo que puede afectar a la latencia del clúster.

Configure el tiempo de espera de la solicitud para las conexiones con el clúster DAX mediante el ajuste del parámetro setRequestTimeout. Para obtener más información, consulte setRequestTimeout en la documentación de DAX.

También se recomienda utilizar reintentos con retroceso exponencial, lo que reduce los errores de solicitud y también los costos operativos.

Nota: DAX no admite la latencia del clúster en métricas de CloudWatch.


OFICIAL DE AWS
OFICIAL DE AWSActualizada hace un año