Solución de problemas de latencia en Amazon DynamoDB - Amazon DynamoDB

Solución de problemas de latencia en Amazon DynamoDB

Si la carga de trabajo parece experimentar una alta latencia, puede analizar la métrica SuccessfulRequestLatency de CloudWatch y comprobar la latencia media y la latencia mediana a través de métricas de percentil (p50) para ver si está relacionada con DynamoDB. Es normal que haya cierta variabilidad en SuccessfulRequestLatency notificado y los picos ocasionales (en concreto en la estadística de Maximum y los percentiles) no deben ser motivo de preocupación. No obstante, si la estadística de Average o p50 (mediana) muestra un fuerte aumento y persiste, debe consultar el panel de estado del servicio de AWS y el panel de estado personal para obtener más información. Algunas causas posibles son el tamaño del elemento de la tabla (un elemento de 1 KB y otro de 400 KB variarán en latencia) o el tamaño de la consulta (10 elementos frente a 100 elementos).

Las métricas de percentil (p99, p90, etc.) pueden ayudarlo a comprender mejor la distribución de latencia. Por ejemplo:

  • p50 (mediana) muestra la latencia típica de la carga de trabajo.

  • p90 muestra que el 90 % de las solicitudes son más rápidas que este valor.

  • p99 ayuda a identificar la latencia en el peor de los casos, que afecta al 1 % de las solicitudes.

Los valores altos de p99 con valores normales de p50 podrían indicar problemas esporádicos que afectan una pequeña parte de las solicitudes, mientras que los valores elevados de p50 de forma coherente podrían sugerir cierto deterioro del rendimiento.

nota

Para analizar valores de percentiles personalizados (como p99,9), puede introducir manualmente el percentil deseado (por ejemplo, p99,9) en el campo de estadísticas de métricas de CloudWatch. Esto le permite evaluar las distribuciones de latencia más allá de los percentiles predeterminados que aparecen en la lista desplegable.

Se espera cierta variación en las métricas de latencia, en concreto en los percentiles más altos, y puede verse como resultado de las operaciones en segundo plano impulsadas por DynamoDB que ayudan a mantener una alta disponibilidad y durabilidad de los datos almacenados en tablas de DynamoDB o problemas transitorios de infraestructura.

Si es necesario, considere la posibilidad de abrir un caso de soporte con AWS Support y siga evaluando las opciones de emergencia disponibles para su aplicación (como la evacuación de una región si tiene una arquitectura multirregión) de acuerdo con sus manuales de procedimientos. Debes registrar los ID de solicitud de las solicitudes lentas para proporcionarlos a AWS Support cuando cree un caso de asistencia.

La métrica SuccessfulRequestLatency solo mide la latencia interna del servicio DynamoDB; no se incluyen la actividad del cliente ni los tiempos de ida y vuelta de la red. Para obtener más información sobre la latencia global de las llamadas de su cliente al servicio DynamoDB, puede activar el registro de métricas de latencia en su SDK de AWS.

nota

Para la mayoría de las operaciones singleton (operaciones que se aplican a un único elemento mediante la especificación completa del valor de la clave principal), DynamoDB proporciona Average SuccessfulRequestLatency milisegundos de un solo dígito. Este valor no incluye la sobrecarga de transporte para el código de llamada que accede al punto de conexión de DynamoDB. En el caso de las operaciones con datos de varios elementos, la latencia variará en función de factores como el tamaño del conjunto de resultados, la complejidad de las estructuras de datos devueltas y las expresiones de condición y de filtro aplicadas. Para operaciones repetidas de varios elementos al mismo conjunto de datos con los mismos parámetros, DynamoDB proporcionará Average SuccessfulRequestLatency de alta coherencia.

Considere una o más de las siguientes estrategias para reducir la latencia:

  • Reutilizar conexiones: las solicitudes de DynamoDB se realizan a través de una sesión autenticada que es HTTPS de forma predeterminada. Iniciar la conexión requiere varios procesos de ida y vuelta y lleva tiempo, por lo que la latencia de la primera solicitud es superior a la de las siguientes solicitudes que reutilizan la conexión. Las solicitudes a través de una conexión ya inicializada ofrecen la baja latencia coherente de DynamoDB. Para evitar la latencia que supone establecer nuevas conexiones, es posible que desee implementar un mecanismo de “mantenimiento de conexión” mediante el envío de una solicitud GetItem cada 30 segundos si no se realizan otras solicitudes.

  • Usar lecturas coherentes posteriores: si su aplicación no requiere lecturas altamente coherentes, considere la posibilidad de utilizar las lecturas coherentes posteriores predeterminadas. Las lecturas coherentes posteriores tienen un costo menor y pueden provenir de varias zonas de disponibilidad, lo que permite seleccionar una zona de disponibilidad ubicada cerca del solicitante y reducir la latencia. Para obtener más información, consulte Coherencia de lectura de DynamoDB.

  • Implementar cobertura de solicitudes: para requisitos de latencia p99 muy bajos, considere implementar cobertura de solicitudes. Con la cobertura de solicitudes, si la solicitud inicial no recibe una respuesta lo suficientemente rápido, envíe una segunda solicitud equivalente y deje que compitan. La primera respuesta gana. Esto mejora la latencia de cola a costa de algunas solicitudes adicionales. Puede decidir cuánto tiempo esperar antes de enviar la segunda solicitud. La cobertura es más fácil para las lecturas. Para las escrituras, utilice el orden basado en marcas temporales para garantizar que las solicitudes cubiertas se traten como si ocurrieran en el momento del primer intento, evitando actualizaciones desordenadas. Este enfoque se ha analizado en Escrituras con marca temporal para cobertura de escritura en Amazon DynamoDB.

  • Ajustar el tiempo de espera de la solicitud y el comportamiento de reintentos: la ruta desde el cliente a DynamoDB atraviesa muchos componentes, cada uno diseñado teniendo en cuenta la redundancia. Tenga en cuenta los siguientes aspectos:

    • Resiliencia de la red

    • Tiempos de espera de los paquetes TCP

    • Arquitectura distribuida de DynamoDB

    Los comportamientos del SDK predeterminados están optimizados para la mayoría de las aplicaciones. No obstante, puede implementar una estrategia de respuesta rápida a los errores y ajustar la configuración del tiempo de espera. Las solicitudes que tardan mucho más de lo normal tienen menos probabilidades de realizarse correctamente. Al responder rápido a los errores y reintentarlo, es posible que lo consiga rápidamente a través de una ruta diferente. Esto es similar a la cobertura de solicitudes, pero finaliza la primera solicitud en lugar de permitir que continúe.

    Evite establecer valores de tiempo de espera demasiado bajos. Los tiempos de espera demasiado bajos pueden provocar problemas de disponibilidad inducidos por el cliente. Por ejemplo, un tiempo de espera de socket de 50 milisegundos podría provocar errores de conexión durante picos de latencia de la red, por ejemplo, cuando se acercan los límites de ancho de banda de la instancia de Amazon EC2 para el tráfico de flujo único. Valore detenidamente las ventajas de los tiempos de espera más bajos frente a los riesgos potenciales para la disponibilidad de la aplicación y priorice la cobertura a los tiempos de espera cortos.

    Para obtener un análisis útil de este tema, consulte Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications.

  • Reducir la distancia entre el cliente y el punto de conexión de DynamoDB: si tiene usuarios dispersos por todo el mundo, considere la posibilidad de utilizar Tablas globales: replicación en varias regiones para DynamoDB. Con las tablas globales, puede replicar la tabla en las regiones de AWS especificadas donde desee que esté disponible. Puede colocar una copia de los datos más cerca del usuario final para reducir la latencia de red durante las operaciones de lectura y escritura. Para obtener más información sobre cómo utilizar las tablas globales de DynamoDB de forma efectiva, consulte Uso de tablas globales de Amazon DynamoDB en Recomendaciones de AWS.

  • Utilizar el almacenamiento en caché: si tiene mucho tráfico de lectura, considere la posibilidad de utilizar uno de estos servicios de almacenamiento en caché:

    • Acelerador de DynamoDB (DAX) es una caché en memoria altamente disponible y completamente administrada para DynamoDB que multiplica el rendimiento hasta por diez (de milisegundos a microsegundos) incluso con millones de solicitudes por segundo. Para obtener más información sobre DAX, consulte Aceleración en memoria con DynamoDB Accelerator (DAX):

    • Amazon ElastiCache: un servicio de almacenamiento en caché en memoria totalmente administrado que se puede integrar con DynamoDB para mejorar el rendimiento de lectura mediante el patrón de reserva de caché. Para obtener más información, consulte Integrating Amazon DynamoDB and Amazon ElastiCache by using read-through caching en Recomendaciones de AWS.