Auto scaling de Amazon DynamoDB: Optimización de rendimiento y costos a cualquier escala

Escalar la capacidad de la base de datos puede ser una tarea tediosa y arriesgada. Incluso desarrolladores veteranos y administradores de bases de datos que entienden el comportamiento matizado de su base de datos y aplicaciones, realizan este trabajo con cautela. A pesar de la actual era de los clústers NoSQL con shards, el aumento de la capacidad puede tomar horas, días o semanas. Cualquier persona que haya emprendido una tarea de este tipo sabe que, mientras se escala verticalmente, el impacto en el rendimiento puede ser impredecible o incluir interrupciones en el servicio. Por el contrario, requeriría circunstancias raras para que alguien decidiera que vale la pena el esfuerzo de reducir la capacidad porque eso viene con su propio conjunto de consideraciones complejas. Y bueno, ¿por qué le tememos tanto a las tareas la planificación de la capacidad de las bases de datos? Bueno, sabemos de antemano que si subaprovisionas tu base de datos, puede tener un impacto catastrófico en tus aplicaciones, por el contrario, si sobreaprovisionas, podrías desperdiciar decenas o cientos de miles de dólares. Nadie quiere experimentar eso.

Amazon DynamoDB es una base de datos totalmente administrada en la que los desarrolladores y administradores de bases de datos han confiado desde hace más de 10 años. Ofrece rendimiento de baja latencia a cualquier escala y simplifica en gran medida la administración de la capacidad de la base de datos. Con un esfuerzo mínimo, puede tener una tabla completamente aprovisionada que se integra fácilmente con una variedad de SDKs y servicios de AWS. Después de aprovisionar una tabla, puede cambiar su capacidad sobre la marcha. Si descubres que tu aplicación se ha vuelto tremendamente popular de la noche a la mañana, puedes aumentar fácilmente la capacidad. Por otro lado, si optimizas la lógica de la aplicación y reduces sustancialmente el rendimiento de la base de datos, puedes realizar inmediatamente ahorros de costos al reducir la capacidad aprovisionada. La capacidad adaptativa de DynamoDB maneja sin problemas la capacidad creciente y decreciente tras bambalinas.

En junio de 2017, DynamoDB lanzó el escalamiento automático para facilitarle la administración eficiente de la capacidad, y seguir ayudando a los usuarios de DynamoDB a reducir el costo de las cargas de trabajo que tienen un patrón de tráfico predecible. Antes del escalamiento automático, usted aprovisionaría de forma estática la capacidad con el fin de cumplir con la carga máxima de una tabla más un buffer pequeño. En la mayoría de los casos, sin embargo, no es rentable aprovisionar estáticamente una tabla por encima de la capacidad máxima. En este blog, mostramos cómo el autoescalamiento responde a los cambios en el tráfico, explicamos qué cargas de trabajo son las más adecuadas para el autoescalamiento, demostramos cómo optimizar una carga de trabajo y calcular el costo-beneficio, y mostraremos cómo DynamoDB puede responder a un millón de solicitudes por segundo.

Antecedentes: Cómo funciona el autoescalamiento de DynamoDB

Cuando se crea una tabla en DynamoDB, el autoescalamiento se activa por default, pero también se puede habilitar el escalamiento automático en cualquier tabla que no lo tenga activo. Como se ilustra en el siguiente diagrama, el autoescalamiento de DynamoDB utiliza una política de escalamiento en Aplication Auto Scaling . Para configurar el escalamiento automático en DynamoDB, debes de establecer los niveles mínimo y máximo de capacidad de lectura y escritura, además del porcentaje de utilización objetivo. El escalamiento automático utiliza Amazon CloudWatch para supervisar las métricas de capacidad de lectura y escritura de una tabla. Para ello, el autoescalamiento creará alarmas de CloudWatch, las cuales rastrean la capacidad consumida.

La alarma de umbral superior se activa cuando el consumo de lecturas o escrituras sobrepasan el porcentaje de utilización objetivo durante dos minutos consecutivos. La alarma de umbral inferior se activa después de que el tráfico cae por debajo de la utilización objetivo menos 20 por ciento durante 15 minutos consecutivos. Cuando se activa una alarma, CloudWatch inicia la actividad de escalamiento automático, la cual comprueba la capacidad consumida y actualiza la capacidad aprovisionada de la tabla. Por ejemplo, si establece las unidades de capacidad de lectura (RCU) en 100 y la utilización objetivo en 80 por ciento, el escalamiento automático aumenta la capacidad aprovisionada cuando la utilización supera los 80 RCU durante dos minutos consecutivos, o disminuye la capacidad cuando el consumo cae por debajo de 60 RCU (80 por ciento menos 20 por ciento) por quince minutos.

El siguiente gráfico ilustra cómo una tabla sin escalamiento automático se aprovisiona estáticamente. La linea roja es la capacidad aprovisionada y el área azul es la capacidad consumida. El pico consumido es casi el 80 por ciento de la capacidad aprovisionada, lo que representa un buffer de sobrecarga estándar. El área entre la línea roja y la zona azul es la capacidad no utilizada.

El escalamiento automático de DynamoDB reduce la capacidad no utilizada en el área entre la capacidad aprovisionada y consumida. El siguiente gráfico es un ejemplo de una carga de trabajo que utilizamos para esta blog, el cual tiene habilitado el escalamiento automático. Se puede ver la mejor relación de consumo a capacidad aprovisionada, lo que reduce la sobrecarga desperdiciada a la vez que proporciona suficiente capacidad operativa.

A través del resto de este blog, mostramos cómo el escalamiento automático de DynamoDB le permite entregar la mayoría, si no toda, la administración de la capacidad a la automatización y, por ende, obtener menores costos.

Configurando la prueba

Para demostrar el escalamiento automático para esta entrada de blog, generamos una carga de trabajo cíclica de 24 horas. El patrón de la carga de trabajo representa muchas aplicaciones del mundo real cuyo tráfico crece hasta un pico y luego disminuye durante el periodo de un día. Ejemplos de este patrón incluyen métricas para una empresa de Internet de las Cosas (IoT), datos del carrito de compras para un minorista en línea y metadatos utilizados por una aplicación de redes sociales.

Desplegamos un generador de carga personalizado, basado en Java, en AWS Elastic Beanstalk y luego creamos un panel de CloudWatch. El panel que se muestra en la siguiente captura de pantalla monitorea las métricas clave de rendimiento: tasa de solicitud, latencia promedio de solicitudes, capacidad aprovisionada y capacidad consumida para lecturas y escrituras.

Como muestra el panel, el generador creó una carga cíclica que creció constantemente y que alcanzó su máximo nivel al mediodía, y luego disminuyó de nuevo a cero. Esta prueba generó lecturas y escrituras usando ítems creados aleatoriamente con una distribución de claves de alta cardinalidad. Para que la muestra sea heterogénea, hubo 10 tamaños de ítems los cuales tenían un tamaño promedio de 4 KB. Para lograr una carga máxima de 1 millón de solicitudes por segundo, se utilizó el tamaño promedio del artículo, la tasa de solicitud, 20 por ciento de sobreaprovisionamiento y la relación lectura-escritura para estimar que la tabla requeriría 2 millones de unidades de capacidad de escritura (Write Capacity Units, WCU) y 800K unidades de capacidades de lectura (RCU, Read Capacity Units)  (Documentación de Calculo de Capacidad aprovisionada). Siguiendo las mejores prácticas, también nos aseguramos de que el parámetro useTcpKeepAlive este habilitado en la aplicación del generador de carga (ClientConfiguration javadocs). Esta configuración puede ayudar a reducir la sobrecarga y mejorar el rendimiento ya que con esto indicamos que el cliente reutilice las conexiones TCP en lugar de reestablecer una conexión para cada solicitud.

El resultado de la prueba

La prueba alcanzó un pico de 1,100,000 solicitudes por segundo. El escalamiento automático de DynamoDB consiguió que la capacidad aprovisionada coincidiera activamente con el tráfico generado, lo que significó que tuviéramos una carga de trabajo que se aprovisionó de manera eficiente. El promedio de latencia de solicitud del lado de servicio de prueba fue de 2.89 milisegundos para lecturas y 4.33 milisegundos para escrituras. Sorprendentemente, la latencia promedio de solicitudes bajó a medida que la carga sobre la tabla aumentaba.

Las siguientes capturas de pantalla provienen de la pestaña de métricas de la consola DynamoDB. Como se puede ver en la captura de pantalla correcta, la latencia de solicitud de lectura bajó a casi 2.5 milisegundos a la carga máxima.

  Izquierda: Capacidad de lectura aprovisionada y consumida.      Derecha: Latencia de lectura correspondiente

De igual manera, la latencia de escritura (que se muestra en la siguiente captura de pantalla de la derecha) fue a un poco más de 4 milisegundos.

Izquierda: Capacidad de escritura aprovisionada y consumida.      Derecha: Latencia de escritura correspondiente

Estos resultados son sorprendentes. Tradicionalmente, una base de datos bajo carga se vuelve cada vez más lenta en relación con el tráfico, por lo que ver mejorar el rendimiento con carga es notable. Algunos trabajos de investigación revelaron que la menor latencia se debe a las optimizaciones internas en DynamoDB, las cuales se mejoraron debido a que todas las solicitudes accedieron a la misma tabla. El ajuste useTcpKeepAlive también resultó en más solicitudes por conexión, lo que ayudó a traducirse en menor latencia.

¿Qué tan bien administró la capacidad el escalamiento automático? El escalamiento automático mantuvo una relación de aprovisionamiento a consumo saludable durante todo el día. Hubo un breve periodo en la primera hora cuando el generador de carga incrementó el tráfico más rápido del 80 por ciento por periodo de dos minutos. No obstante, debido a la capacidad de ráfaga, el impacto fue insignificante. En las métricas se observa que hubo 15 eventos de lectura con limitación controlada por 3.35 millones de solicitudes de lectura, que son cuatro décimas de un por ciento. Después del periodo inicial, no hubo limitación controlada.

Izquierda: Peticiones y eventos limitados por minuto         Derecha: Relación de capacidad aprovisionada y consumida 

Como se describió anteriormente en esta publicación, CloudWatch monitorea la actividad de la tabla y responde cuando se supere un umbral durante un período determinado. En la siguiente imagen de CloudWatch se muestra la actividad para las alarmas de utilización objetivo. Como puede ver, existen umbrales superiores e inferiores que utilizan periodos de dos minutos y quince minutos para realizar un seguimiento de la capacidad consumida y aprovisionada de lecturas y escrituras.

A continuación, las alarmas de utilización activaron eventos de escalamiento, que se pueden ver como actividades de escalamiento automático en la pestaña Capacidad de DynamoDB (que se muestra en la imagen). El escalamiento automático cambió de forma independiente la capacidad de lectura y escritura aprovisionada a medida que la capacidad consumida cruzó los umbrales.

La prueba superó un millón de solicitudes por segundo. El siguiente gráfico muestra ambas lecturas (el área azul) y escrituras (el área naranja): 66.5 millones/60 segundo periodo = 1.11 millones de solicitudes por segundo.

Esta prueba mostró que el escalamiento automático incrementó la capacidad aprovisionada cada dos minutos cuando el tráfico alcanzó la utilización objetivo del 80 por ciento. Es posible que hayas notado en una captura de pantalla anterior de este post que el periodo de reducción fue más lento. Esto se debe a que el escalamiento automático disminuye la capacidad después de que el consumo es 20 por ciento menor que la utilización objetivo durante 15 minutos. Disminuir la capacidad más lentamente es por diseño, y se ajusta al límite de dial-downs por día.

La actualización constante del escalamiento automático de DynamoDB dio como resultado una tabla aprovisionada eficientemente y, como mostramos en la siguiente sección, un 30.8% de ahorro. La prueba demostró claramente el rendimiento consistente y la baja latencia de DynamoDB ante un millón de solicitudes por segundo.

Optimización de costos de escalamiento automático: capacidades aprovisionadas, bajo demanda y reservadas

En esta sección, comparamos los costos de la tabla de las opciones aprovisionadas estáticamente, autoescalamiento y bajo demanda. También calculamos cómo la capacidad reservada puede optimizar el modelo de costos.

Como recordarán, una tabla tradicional aprovisionada estáticamente establece la capacidad 20 por ciento por encima de la carga máxima esperada; para nuestra prueba que serían 2 millones de WCU y 800K RCU. Las unidades de capacidad de escritura y lectura tienen un precio por hora por lo que el costo mensual se calcula multiplicando las WCU y RCU aprovisionadas por el costo por unidad-hora, que es de $.00013/RCU y $.00065/WCU, y luego por el número de horas en un mes promedio (730). Todos los costos unitarios se pueden encontrar en la página de Precios de DynamoDB . Como tal, una tabla aprovisionada estáticamente para nuestra prueba costaría $1,024,920 mensuales:

$1,024.920 mensuales = 730 horas × ((2,000,000 × $.00065) + (800,000 × $.00013))

Para encontrar el costo real de la prueba de autoescalamiento que ejecutamos, utilizamos el Informe de uso de AWS, que es un componente de facturación que ayuda a identificar el costo por servicio y fecha. Dentro del informe de uso, hay tres unidades de costo primario para DynamoDB, que son: WriteCapacityUnit-Hrs, ReadCapacityUnit-Hrs, y Timestorage-ByteHrs. Nos centraremos en los dos primeros, y podemos ignorar el costo de almacenamiento, porque es mínimo y es el mismo independientemente de otras configuraciones. En la siguiente imagen, se pueden ver los costos de lectura y escritura de la prueba, que dieron en total $23,318.06 diarios.

A 30.4 días al mes (365 días/12 meses), el escalamiento automático daría un promedio de $708,867 mensuales, que es de $316,053 (o 30.8 por ciento) menos que la tabla aprovisionada estáticamente que calculamos arriba ($1,024,920):

Ahorro mensual de $316,053 = $1,024,920 aprovisionados estáticamente — $708,867 auto scaling

Esto muestra cómo el autoescalamiento bajó el costo de la tabla. En un entorno de producción, el escalamiento automático podría reducir el tiempo de operaciones asociado a la planificación y administración de una tabla aprovisionada. Puede incluir esos ahorros operativos en las estimaciones de costos de cualquiera de sus cargas de trabajo en DynamoDB.

¿Cómo se compara el ahorro de escalamiento automático con lo que veríamos con el modo de capacidad bajo demanda? Con bajo demanda, DynamoDB asigna instantáneamente la capacidad según sea necesaria. No hay concepto de capacidad aprovisionada, y no hay retraso en la espera de los umbrales de CloudWatch o las actualizaciones posteriores de la tabla. Bajo demanda es ideal para cargas de trabajo explotadas, nuevas o impredecibles cuyo tráfico puede aumentar en segundos o minutos, y cuando la capacidad sub aprovisionada repercutiría en la experiencia del usuario. Bajo demanda es una solución perfecta si su equipo se está trasladando a un entorno NoOps o sin servidor. Dado que el costo beneficio de un flujo de trabajo sin servidor está fuera del alcance de esta entrada de blog, y nuestra prueba representa el tráfico cambiante gradualmente, a petición no es muy adecuado para esta comparación. No obstante, veamos los costos de todos modos para entender cómo calcularlos.

El modo de capacidad bajo demanda tiene un precio de $1.25 y $.25 por cada millón de unidades de escritura o lectura respectivas. Para identificar el total de WCU y RCU que utiliza nuestra prueba en un solo día, regresamos a nuestro panel de control de CloudWatch. Si recuerdas, rastreamos solicitudes por minuto. Esto se hizo mediante el uso de la métrica SampleCount de SuccessfulRequestLatency , como se describe en la documentación de métricas y dimensiones . Al cambiar el periodo de esta métrica a un día completo, podemos ver el número total de solicitudes de lectura y escritura, como se muestra en la siguiente captura de pantalla. Con los recuentos de solicitudes, podemos usar el tamaño promedio de objeto de la prueba (4 KB) para aproximar cuantos WCU y RCU se utilizarían en modo bajo demanda. Las ecuaciones para calcular la capacidad consumida se describen largamente en la documentación.

   Izquierda: Peticiones por día(en billones)        Derecha: Cálculo de capacidad consumida y costo bajo demanda por día

Al combinar los costos de RCU y WCU, podemos aproximar un costo mensual bajo demanda de $2,471,520:

$2,471,520/mes = 30.4 días × ($5,800 + $75,500)

En comparación con 708,867 dólares mensuales en auto scaling, el mayor costo del modo bajo demanda no es sorprendente porque nuestra prueba representa una carga de trabajo predecible y no da cuenta del beneficio de costo real de NoOps. El mensaje aqui es que esta carga de trabajo es un candidato perfecto para el autoescalamiento y la optimización de costos.

El escalamiento automático representa un ahorro significativo de costos, pero ¿podemos hacer más? ¿Cómo influye la capacidad reservada en la optimización de costos? La capacidad reservada para DynamoDB es consistente con el modelo de instancias reservadas de Amazon EC2 . Usted adquiere capacidad reservada por un plazo de un año o tres años y recibe un descuento significativo. Usted adquiere capacidad reservada en sets 100-WCU o 100-RCU. Por el bien de la comparación, usemos el modelo de reservas de un año. Una capacidad reservada de 1 WCU funciona a $.000299 por hora.

$.000299 por hora = (($150 reserva ÷ 8,760 horas/año) + $.0128 reservados WCu/hora) ÷ 100 unidades

Eso es 46 por ciento del precio estándar, que es .00065, y un ahorro significativo. El mismo ahorro de costos también es consistente para las RCU reservadas, que es de $.000059 por RCU reservada o $.00013 por RCU estándar.

$.000059 por hora = (($30 reserva ÷ 8,760 horas/año) + $.0025 reservada RCU/hora) ÷ 100 unidades

¿Pueden trabajar juntos el escalamiento automático y la capacidad reservada? ¡Sí! Puede aproximar una mezcla de capacidad reservada y escalamiento automático mediante el uso de la relación entre costo reservado y aprovisionado. Por ejemplo, sabemos que la capacidad reservada cuesta 46 por ciento del precio estándar, por lo que cualquier porción de una capacidad que esté activa más del 46 por ciento de un día debería ahorrar dinero como capacidad reservada. Podemos calcular el punto de transición de la relación utilizando el mediodía como nuestro ancla. Como tal, 46 por ciento de 12 horas funciona a 5.5 horas antes del mediodía, o 6:30 AM.

331 minutos antes del mediodía = 46% × (12 horas × 60 minutos)

DynamoDB se factura por hora, y las métricas de uso por hora se pueden descargar desde los informes de facturación. Nos redondeamos de 6:30 AM a 7:00 AM para la transición entre la capacidad reservada y el autoescalamiento. El tablero de CloudWatch muestra que a las 7:00 AM había 1.74 millones de WCU y 692,000 RCU. Para estimar el costo mezclado, utilizamos las tarifas reservadas RCU y WCU y agregamos el uso de autoescala por hora de 7:00 AM a 7:00 PM (que es cuando la carga cae por debajo del monto de la reserva). En las siguientes imagenes se muestra la relación mezclada entre WCU reservadas y autoescaladas.

Izquierda: Relación mezclada de WCU reservadas y autoescaladas        Derecha: 1.74 millones de WCU aprovisionadas a las 7:00 a.m

El uso por hora fue descargado desde la consola de facturación. En la siguiente tabla se muestra el costo por hora para la porción de escalamiento automático de la relación mezclada. Se resta la capacidad reservada de las RCU y WCU porque eso se agrega por separado.

Para entonces encontrar el costo mensual reservado, multiplicamos las unidades totales por el costo unitario reservado ($.000299 por WCU-hora y $.000059 por RCU-hora) y multiplicamos por las horas en un mes (730).

$379,789 al mes = 1.74 millones de WCs × $.000299 × 730 horas

$29,804 al mes = 692,000 RCU × $.000059 × 730 horas

Combinada, la capacidad reservada asciende a $409,593 mensuales. Al sumar esto a la porción de autoescalamiento, que es de $50,734 ($1,668.88 x 30.4 días), llegamos a una tasa mensual mixta de 460.327 dólares. Eso es 248,540 dólares menos que la estimación auto escalamiento, que fue de 708,867 dólares

También puedes usar la opción de capacidad reservada de tres años, con el cual obtienes un descuento de más del 75 por ciento. En ese nivel de descuento, es rentable aprovisionar estáticamente toda la capacidad reservada.

En el siguiente cuadro se resumen nuestros hallazgos de optimización. Se compara cada escenario y destaca el ahorro asociado en relación a una tabla aprovisionada estáticamente. Tus patrones de carga de trabajo serán diferentes, y tendrás que calcular la cantidad de ahorro en función de tus propios patrones. Al usar las optimizaciones que hemos discutido, puede reducir significativamente sus costos.

Resumen: Auto escalamiento y optimización de costos para llevar

Repasemos los resultados de la prueba de autoescalamiento de DynamoDB en este post y las lecciones que aprendimos:

• ¿ Cómo funciona el autoescalamiento? En esta prueba, el escalamiento automático utilizó alarmas de CloudWatch para adaptarse rápidamente al tráfico. En cuestión de minutos, el escalamiento automático actualizó la capacidad aprovisionada de la tabla para que coincidiera con la carga. El escalamiento automático se escala hacia arriba más rápido que hacia abajo, y puedes afinarlo estableciendo la utilización target. En nuestra prueba, el escalamiento automático proporcionaba capacidad suficiente mientras reducía los gastos generales.
• ¿ Cómo manejó el escalamiento automático una carga de trabajo no trivial? Extremadamente bien. Ejecutamos una prueba de carga que creció de cero a 1.1 millones de solicitudes por segundo en 12 horas y el escalamiento automático actualizó la tabla cada vez que se incumplió el umbral de utilización objetivo. Se comprobó la actividad de autoescalamiento, lo que confirmó que se actualizó con precisión y rapidez. El escalamiento automático no degradó el rendimiento. De hecho, a medida que el tráfico creció a 1,.1 millones de solicitudes por segundo, se disminuyó la latencia promedio de cada solicitud.
• ¿ El escalamiento automático puede ayudar a reducir costos? En esta prueba, el escalamiento automático redujo los costos en 30.8 por ciento. Para la prueba, utilizamos un 80 por ciento de utilización objetivo, pero debes ajustar la utilización objetivo para cada carga de trabajo para aumentar el ahorro y garantizar que la capacidad se asigne adecuadamente. También mostramos en este post cómo optimizar aún más los costos mediante el uso de una mezcla de capacidad reservada a un año y autoescalamiento, lo que en esta prueba redujo los costos en un 55.1 por ciento.

Como puede ver, hay razones convincentes para usar el escalamiento automático de DynamoDB con tráfico que cambia constantemente. El escalamiento automático responde rápidamente y simplifica la administración de la capacidad, lo que reduce los costos al escalar la capacidad aprovisionada de su tabla y reducir la sobrecarga operativa.

Los montos mencionados en el blog están precios en dólares estadounidenses.

Sobre el autor

Sean Shriver es un arquitecto senior de soluciones especialista en NoSQL con sede en Dallas enfocado en DynamoDB.

Sobre los traductores

José Lorenzo Cuéncar Garza es Arquitecto de Soluciones Sr. para Amazon Web Services en Sector Público. José colabora con Dependencias de Gobierno, Instituciones Educativas y Organizaciones sin fines de lucro en México, apoyándolos en su camino a la innovación y adopción tecnológica, además forma parte de la comunidad técnica de educación y cómputo (TFC) dentro de AWS.

Alex Luna es Arquitecto de Soluciones en AWS México para el Sector Público. Apoya a Instituciones sin Fines de Lucro e Instituciones Educativas a adoptar las mejores prácticas y soluciones en la nube de AWS.

Christian Castro es Arquitecto de Soluciones Senior para Gobierno Federal de México en Sector Público. Christian es responsable de establecer y mantener arquitecturas de soluciones en AWS para clientes del Gobierno Federal Mexicano, además forma parte de la comunidad técnica de contenedores (TFC) dentro de AWS.

Blog Post original: https://aws.amazon.com/blogs/database/amazon-dynamodb-auto-scaling-performance-and-cost-optimization-at-any-scale/