Como configurar o auto-scaling do DynamoDB

O auto-scaling do DynamoDB ajusta a capacidade de leitura e escrita de uma tabela provisionada em direção a uma utilização alvo que você escolhe, para que você pare de ajustar RCU/WCU na mão e pare de pagar por uma reserva de pior caso o dia inteiro. Este guia é a metade prática da história de capacidade: o caminho no console, os comandos da CLI, como de fato escolher os números, e os limites de tempo que ainda deixam um pico abrupto sofrer throttling. Se você ainda não escolheu um modo de capacidade, comece por On-Demand vs Provisionado — o auto-scaling só se aplica ao Provisionado.

Como habilitar o auto-scaling em uma tabela DynamoDB?

No console: abra sua tabela, vá em Configurações adicionais → Capacidade de leitura/escrita → Editar, escolha Provisionado e defina o Auto scaling como Ativado para a capacidade de leitura, de escrita ou ambas, dando a cada uma um mínimo, um máximo e uma utilização alvo (configurável entre 20 e 90 por cento). Pela CLI, registre um destino escalável e anexe uma política de escalabilidade de rastreamento de destino com aws application-autoscaling. Tabelas criadas pelo console já vêm com auto-scaling habilitado por padrão.

O que o auto-scaling faz de fato

Uma política de escalabilidade diz ao Application Auto Scaling para manter a razão entre capacidade consumida e provisionada de uma tabela perto da sua utilização alvo, dentro dos limites de capacidade mínimo e máximo que você define. Por baixo dos panos ele cria um par de alarmes do CloudWatch para as fronteiras superior e inferior; quando o consumo cruza uma delas, o Application Auto Scaling emite uma chamada UpdateTable para mover a capacidade provisionada.

Dois fatos estruturais importam antes da configuração:

• As políticas são por tabela e por GSI. Cada índice secundário global tem seu próprio throughput provisionado, então cada um precisa da sua própria política (ou da caixa de seleção "mesmas configurações para todos os GSIs" do console). Um GSI sub-escalado pode aplicar throttling nas escritas da tabela base — veja por que um GSI aplica throttling na tabela base.
• Tabelas criadas pelo console entram por padrão; GSIs adicionados depois não escalam enquanto são construídos. Um GSI novo em uma tabela existente começa com capacidade manual durante o backfill — fique de olho nele até a política ser anexada.

O tempo de reação com que você está se comprometendo

O auto-scaling é reativo, e seus tempos de reação são fixos — a AWS documenta que as contagens de pontos de dados dos alarmes não são ajustáveis:

• O scale-up dispara depois que a capacidade consumida ultrapassa o alvo por dois minutos consecutivos (mais até alguns minutos de atraso do alarme do CloudWatch).
• O scale-down espera por 15 pontos de dados consecutivos de um minuto abaixo do alvo.
• Depois de qualquer um dos gatilhos, a chamada UpdateTable leva vários minutos para ser aplicada — e requisições acima do teto antigo sofrem throttling enquanto isso.

Esse piso de ~5 minutos entre a violação e a nova capacidade é o limite honesto do recurso: o auto-scaling absorve tráfego que cresce, não tráfego que salta em degrau. Uma promoção-relâmpago que triplica a carga em um minuto vai sofrer throttling na capacidade provisionada independentemente da sua política; esse formato pede On-Demand, que acomoda instantaneamente até o dobro do seu pico anterior (e aplica throttling além do dobro dentro de 30 minutos — sua própria versão da mesma física).

Configuração pelo console

Para uma tabela existente (passos da AWS):

1. Console do DynamoDB → Tabelas → escolha a tabela.
2. Aba Configurações adicionais → Capacidade de leitura/escrita → Editar.
3. Modo de capacidade: Provisionado.
4. Em Capacidade da tabela, mude o Auto scaling para Ativado para leitura, escrita ou ambas, e então defina Unidades mínimas de capacidade, Unidades máximas de capacidade e Utilização alvo para cada uma.
5. Opcionalmente aplique as mesmas configurações a todos os GSIs e clique em Salvar.

Uma limitação do console que vale conhecer: os cooldowns não são expostos lá. A própria documentação da AWS te aponta para a CLI "para recursos mais avançados, como definir os tempos de cooldown de scale-in e scale-out".

Configuração pela CLI

Duas chamadas por dimensão: registre o destino escalável (os limites mínimo/máximo) e então anexe a política de rastreamento de destino. Literalmente como no passo a passo da CLI da AWS, para a capacidade de escrita em uma tabela:

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

A configuração da política vive em um arquivo 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 leituras, troque a dimensão para dynamodb:table:ReadCapacityUnits e a métrica para DynamoDBReadCapacityUtilization. Para um GSI, o resource id vira table/TestTable/index/test-index com as dimensões dynamodb:index:*. Uma tabela com três GSIs escalando as duas dimensões precisa, portanto, de oito pares destino/política — automatize com um script.

Os dois cooldowns têm valor padrão 0 no DynamoDB e são os botões exclusivos da CLI: ScaleOutCooldown é o mínimo de segundos entre aumentos de capacidade (um scale-out maior ainda passa imediatamente), e ScaleInCooldown bloqueia a próxima redução — embora um scale-out interrompa um cooldown de scale-in em vez de esperar por ele.

Escolhendo os números

A utilização alvo é um botão de folga versus custo. Com um alvo de T por cento, você paga por aproximadamente 100/T vezes a sua capacidade consumida: um alvo de 70% compra ~1.4× de folga acima do tráfego estável, um alvo de 50% compra 2×. Alvos mais baixos aguentam crescimentos mais abruptos sem throttling; alvos mais altos desperdiçam menos reserva. A faixa é de 20 a 90%.

O botão se conecta direto à conta. Com as tarifas atuais de us-east-1 (mesma derivação de O DynamoDB faz auto scaling?): a capacidade provisionada a 100% de utilização é ~3.46× mais barata por requisição que o on-demand, e o ponto de equilíbrio fica em ~29% de utilização. O trabalho do auto-scaling é manter a utilização real perto do seu alvo, então o alvo está efetivamente escolhendo o seu desconto: mantido em 70%, o provisionado sai ~2.4× mais barato que o on-demand; em 50%, ~1.7×; abaixo de ~29%, você deveria estar no on-demand. Confira os números da sua própria carga de trabalho na calculadora de preços.

A capacidade mínima é o seu piso para picos: é a capacidade que já está lá durante os ~5 minutos de que o auto-scaling precisa para reagir. Defina-a a partir da rajada mais abrupta que você precisa absorver sem throttling, não a partir do tráfego médio.

A capacidade máxima é a proteção contra descontrole — o teto do que um bug, um loop quente de Lambda ou um teste de carga pode te cobrar. Defina-a acima do seu pico realista e trate atingi-la como um alerta, não como operação normal.

O scale-down é limitado por cota. As reduções de capacidade provisionada vêm de um balde de tokens: você começa cada dia UTC com 4 disponíveis, ganha mais uma a cada hora (máximo de 4 em mãos), até no máximo 27 reduções por tabela por dia — os limites de GSI são separados, mas uma única requisição que reduz tanto a tabela quanto o índice é rejeitada inteira se qualquer um dos lados não tiver cota. O scale-down conservador de 15 minutos do auto-scaling já respeita isso na prática, mas é por isso que a capacidade desce lentamente depois de um pico — e por que um tráfego oscilante termina o dia fixado acima da sua média.

Faça isso no DynoTable

Dimensionar o mínimo e validar o alvo partem os dois de números reais, não de chutes: quão grandes são os itens, quantos existem e quanto uma leitura ou escrita representativa de fato consome. A visualização de tabela do DynoTable expõe a contagem e o tamanho dos itens ao vivo, e a prévia de custo de consulta mostra a estimativa de RCU de uma instrução antes de ela rodar — os mesmos números de que um plano de capacidade é feito. Para dimensionar um único item, a calculadora de tamanho de item gratuita calcula sua pegada de RCU/WCU.

Armadilhas e próximos passos

• O auto-scaling não vence a física por partição. Uma chave quente sofre throttling mesmo com capacidade de sobra — veja partições quentes e capacidade adaptativa.
• Não esqueça os GSIs. Cada índice escala (ou sofre throttling) por conta própria.
• A capacidade reservada só empilha sobre o provisionado. Se uma carga de trabalho é estável a ponto de o auto-scaling quase não se mexer, a capacidade reservada (classe de tabela Standard, apenas no modo provisionado) é o próximo desconto — tabelas on-demand não podem usá-la.
• Observe o primeiro dia. ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits contra a linha do provisionado no CloudWatch te diz rápido se o alvo está se sustentando ou oscilando.

A capacidade é um eixo do modelo de custo; o que suas consultas consomem é o outro — Scan vs Query e o modelo de custo de scans SQL cobrem essa metade.

Baixe o DynoTable para ler o tamanho real, a contagem de itens e o custo por consulta da sua tabela antes de comprometer números de capacidade com ela.