Cómo configurar el escalado automático de DynamoDB

El escalado automático de DynamoDB ajusta la capacidad de lectura y escritura de una tabla aprovisionada hacia una utilización objetivo que tú escoges, para que dejes de afinar a mano las RCU/WCU y dejes de pagar por una reserva del peor caso a todas horas. Esta guía es la mitad práctica de la historia de la capacidad: la ruta en la consola, los comandos de la CLI, cómo escoger de verdad los números y los tiempos de reacción que aún limitan un pico brusco. Si todavía no has escogido un modo de capacidad, empieza por Bajo demanda frente a aprovisionada — el escalado automático solo se aplica a la aprovisionada.

¿Cómo se activa el escalado automático en una tabla de DynamoDB?

En la consola: abre tu tabla, ve a Configuración adicional → Capacidad de lectura/escritura → Editar, escoge Aprovisionada y pon el Escalado automático en Activado para la capacidad de lectura, la de escritura o ambas, dándole a cada una un mínimo, un máximo y una utilización objetivo (configurable entre el 20 y el 90%). Desde la CLI, registra un destino escalable y adjunta una política de escalado de seguimiento de destino con aws application-autoscaling. Las tablas creadas desde la consola traen el escalado automático activado por defecto.

Qué hace realmente el escalado automático

Una política de escalado le dice a Application Auto Scaling que mantenga la proporción entre capacidad consumida y aprovisionada de una tabla cerca de tu utilización objetivo, dentro de los límites de capacidad mínimo y máximo que fijes. Por debajo crea un par de alarmas de CloudWatch para los límites superior e inferior; cuando el consumo cruza uno, Application Auto Scaling emite una llamada UpdateTable para mover la capacidad aprovisionada.

Dos hechos estructurales importan antes de la configuración:

• Las políticas son por tabla y por GSI. Cada índice secundario global tiene su propio rendimiento aprovisionado, así que cada uno necesita su propia política (o la casilla de la consola «los mismos ajustes para todos los GSI»). Un GSI mal escalado puede limitar las escrituras de la tabla base — mira por qué un GSI limita las escrituras de la tabla base.
• Las tablas creadas desde la consola se apuntan por defecto; los GSI añadidos después no escalan mientras se construyen. Un GSI nuevo sobre una tabla existente arranca con capacidad manual durante su backfill — vigílalo hasta que se adjunte la política.

Los tiempos a los que te comprometes

El escalado automático es reactivo, y sus tiempos de reacción son fijos — AWS documenta que los recuentos de puntos de datos de las alarmas no son ajustables:

• El escalado hacia arriba se dispara después de que la capacidad consumida supere el objetivo durante dos minutos consecutivos (más hasta unos pocos minutos de retardo de la alarma de CloudWatch).
• El escalado hacia abajo espera a 15 puntos de datos consecutivos de un minuto por debajo del objetivo.
• Tras cualquiera de los dos disparos, la llamada UpdateTable tarda varios minutos en aplicarse — y las peticiones por encima del techo anterior se limitan mientras tanto.

Ese suelo de ~5 minutos entre la superación y la nueva capacidad es el límite honesto de la función: el escalado automático absorbe tráfico que crece, no tráfico que salta de golpe. Una venta relámpago que triplique la carga en un minuto limitará el tráfico con capacidad aprovisionada por mucha política que tengas; esa forma pide bajo demanda, que acomoda al instante hasta el doble de tu pico anterior (y limita el tráfico más allá del doble dentro de 30 minutos — su propia versión de la misma física).

Configuración en la consola

Para una tabla existente (pasos de AWS):

1. Consola de DynamoDB → Tablas → escoge la tabla.
2. Pestaña Configuración adicional → Capacidad de lectura/escritura → Editar.
3. Modo de capacidad: Aprovisionada.
4. En Capacidad de la tabla, pon el Escalado automático en Activado para lectura, escritura o ambas, y fija luego Unidades de capacidad mínimas, Unidades de capacidad máximas y Utilización objetivo para cada una.
5. Opcionalmente aplica los mismos ajustes a todos los GSI, y Guardar.

Una limitación de la consola que conviene conocer: los períodos de recuperación no se exponen ahí. La propia documentación de AWS te manda a la CLI «para funciones más avanzadas, como configurar los tiempos de recuperación de reducción y de ampliación horizontal».

Configuración con la CLI

Dos llamadas por dimensión: registra el destino escalable (los límites mínimo y máximo) y luego adjunta la política de seguimiento de destino. Textual del tutorial de la CLI de AWS, para la capacidad de escritura de una tabla:

aws application-autoscaling register-scalable-target \
    --service-namespace dynamodb \
    --resource-id "table/TestTable" \
    --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
    --min-capacity 5 \
    --max-capacity 10

La configuración de la política vive en un archivo JSON:

{
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "DynamoDBWriteCapacityUtilization"
  },
  "ScaleOutCooldown": 60,
  "ScaleInCooldown": 60,
  "TargetValue": 50.0
}

aws application-autoscaling put-scaling-policy \
    --service-namespace dynamodb \
    --resource-id "table/TestTable" \
    --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
    --policy-name "MyScalingPolicy" \
    --policy-type "TargetTrackingScaling" \
    --target-tracking-scaling-policy-configuration file://scaling-policy.json

Para lecturas, cambia la dimensión a dynamodb:table:ReadCapacityUnits y la métrica a DynamoDBReadCapacityUtilization. Para un GSI, el id del recurso pasa a ser table/TestTable/index/test-index con las dimensiones dynamodb:index:*. Una tabla con tres GSI escalando ambas dimensiones necesita por tanto ocho pares destino/política — hazlo con un script.

Los dos períodos de recuperación son 0 por defecto en DynamoDB y son los mandos exclusivos de la CLI: ScaleOutCooldown es el mínimo de segundos entre aumentos de capacidad (un escalado hacia arriba mayor pasa igualmente de inmediato), y ScaleInCooldown bloquea la siguiente bajada — aunque un escalado hacia arriba interrumpe el período de recuperación de una bajada en lugar de esperarlo.

Escoger los números

La utilización objetivo es un dial entre margen y coste. Con un objetivo del T por ciento, pagas aproximadamente 100/T veces tu capacidad consumida: un objetivo del 70% compra ~1,4× de margen por encima del tráfico estable, uno del 50% compra 2×. Los objetivos más bajos aguantan un crecimiento más brusco sin limitar el tráfico; los más altos desperdician menos reserva. El rango va del 20 al 90%.

El dial conecta directamente con la factura. Con las tarifas actuales de us-east-1 (la misma derivación que ¿DynamoDB puede escalar automáticamente?): la capacidad aprovisionada al 100% de utilización es ~3,46× más barata por petición que bajo demanda, y el punto de equilibrio está en el ~29% de utilización. El trabajo del escalado automático es mantener la utilización real cerca de tu objetivo, así que el objetivo escoge de hecho tu descuento: mantenido al 70%, la aprovisionada sale ~2,4× más barata que bajo demanda; al 50%, ~1,7×; por debajo del ~29%, deberías estar en bajo demanda. Comprueba los números de tu propia carga de trabajo en la calculadora de precios.

La capacidad mínima es tu suelo ante los picos: es la capacidad que ya está ahí durante los ~5 minutos que el escalado automático necesita para reaccionar. Fíjala a partir de la ráfaga más brusca que debas absorber sin limitar el tráfico, no a partir del tráfico medio.

La capacidad máxima es la protección contra desbocamientos — el tope de lo que un fallo, un bucle caliente de Lambda o una prueba de carga pueden facturarte. Ponla por encima de tu pico realista y trata alcanzarla como una alerta, no como funcionamiento normal.

El escalado hacia abajo está limitado por cuota. Las bajadas de capacidad aprovisionada salen de un cubo de tokens: empiezas cada día UTC con 4 disponibles, ganas una más por hora (con 4 en mano como máximo), hasta un máximo de 27 bajadas por tabla y día — los límites de los GSI van aparte, pero una única petición que baje a la vez la tabla y el índice se rechaza entera si a cualquiera de los dos lados le falta cuota. El conservador escalado hacia abajo a los 15 minutos del escalado automático ya respeta esto en la práctica, pero es la razón de que la capacidad baje despacio y a trompicones tras un pico — y de que el tráfico oscilante acabe el día fijado más alto que su media.

Hazlo en DynoTable

Dimensionar el mínimo y validar el objetivo parten los dos de números reales, no de conjeturas: cómo de grandes son los elementos, cuántos hay y qué consume realmente una lectura o escritura representativa. La vista de tabla de DynoTable muestra el recuento y el tamaño de elementos en vivo, y su vista previa del coste de consulta enseña la estimación de RCU de una sentencia antes de que se ejecute — los mismos números con los que se hace un plan de capacidad. Para dimensionar un único elemento, la calculadora de tamaño de elemento gratuita calcula su huella en RCU/WCU.

Trampas y próximos pasos

• El escalado automático no vence a la física por partición. Una clave caliente se limita aunque sobre capacidad — mira particiones calientes y capacidad adaptativa.
• No te olvides de los GSI. Cada índice escala (o se limita) por su cuenta.
• La capacidad reservada solo se suma a la aprovisionada. Si una carga de trabajo es lo bastante estable como para que el escalado automático apenas se mueva, la capacidad reservada (clase de tabla Standard, solo en modo aprovisionado) es el siguiente descuento — las tablas bajo demanda no pueden usarla.
• Vigila el primer día. ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits frente a la línea de capacidad aprovisionada en CloudWatch te dice enseguida si el objetivo se mantiene o si oscila.

La capacidad es un eje del modelo de costes; lo que tus consultas consumen es el otro — Query frente a Scan y el modelo de costes de los Scan de SQL cubren esa mitad.

Descarga DynoTable para leer el tamaño real, el recuento de elementos y el coste por consulta de tu tabla antes de comprometerte con unos números de capacidad.