Come configurare l'auto scaling di DynamoDB

L'auto scaling di DynamoDB regola la capacità di lettura e scrittura di una tabella Provisioned verso un utilizzo target che scegli tu, così smetti di tarare a mano le RCU/WCU e smetti di pagare 24 ore su 24 per una prenotazione dimensionata sul caso peggiore. Questa guida è la metà pratica della storia della capacità: il percorso nella console, i comandi CLI, come scegliere davvero i numeri e i limiti di tempistica che fanno comunque andare in throttling un picco netto. Se non hai ancora scelto una modalità di capacità, parti da Capacità On-Demand vs Provisioned — l'auto scaling si applica solo a Provisioned.

Come si abilita l'auto scaling su una tabella DynamoDB?

Nella console: apri la tua tabella, vai su Additional settings → Read/write capacity → Edit, scegli Provisioned e imposta Auto scaling su On per la capacità di lettura, di scrittura o entrambe, dando a ciascuna un minimo, un massimo e un utilizzo target (impostabile tra il 20 e il 90 percento). Da CLI, registra uno scalable target e collega una policy di scaling target-tracking con aws application-autoscaling. Le tabelle create dalla console hanno l'auto scaling abilitato di default.

Cosa fa davvero l'auto scaling

Una policy di scaling dice ad Application Auto Scaling di mantenere il rapporto tra capacità consumata e capacità Provisioned di una tabella vicino al tuo utilizzo target, entro i limiti di capacità minimo e massimo che imposti. Sotto il cofano crea una coppia di allarmi CloudWatch per la soglia superiore e quella inferiore; quando il consumo ne attraversa una, Application Auto Scaling emette una chiamata UpdateTable per spostare la capacità Provisioned.

Due fatti strutturali contano prima di iniziare:

• Le policy sono per tabella e per GSI. Ogni global secondary index ha il proprio throughput provisionato, quindi ognuno ha bisogno della propria policy (o della casella "same settings for all GSIs" della console). Una GSI sotto-dimensionata può causare throttling delle scritture della tabella base — vedi perché una GSI limita le scritture sulla tabella base.
• Le tabelle create dalla console aderiscono di default; le GSI aggiunte dopo non scalano mentre vengono costruite. Una nuova GSI su una tabella esistente parte con capacità manuale durante il backfill — tienila d'occhio finché la policy non si aggancia.

Le tempistiche a cui ti stai impegnando

L'auto scaling è reattivo, e i suoi tempi di reazione sono fissi — AWS documenta che i conteggi dei punti dati degli allarmi non sono modificabili:

• Lo scale-up scatta dopo che la capacità consumata supera il target per due minuti consecutivi (più fino a qualche minuto di ritardo dell'allarme CloudWatch).
• Lo scale-down attende 15 punti dati consecutivi da un minuto sotto il target.
• Dopo entrambi gli inneschi, la chiamata UpdateTable richiede diversi minuti per essere applicata — e nel frattempo le richieste oltre il vecchio tetto vengono sottoposte a throttling.

Quel pavimento di ~5 minuti dal superamento alla nuova capacità è il limite onesto della funzionalità: l'auto scaling assorbe il traffico che cresce, non il traffico che fa un gradino. Un flash sale che triplica il carico in un minuto andrà in throttling su capacità Provisioned a prescindere dalla tua policy; quella forma vuole On-Demand, che accoglie all'istante fino al doppio del tuo picco precedente (e va in throttling oltre il doppio entro 30 minuti — la sua versione della stessa fisica).

Configurazione dalla console

Per una tabella esistente (i passaggi AWS):

1. Console DynamoDB → Tables → scegli la tabella.
2. Tab Additional settings → Read/write capacity → Edit.
3. Capacity mode: Provisioned.
4. Sotto Table capacity, porta Auto scaling su On per lettura, scrittura o entrambe, poi imposta Minimum capacity units, Maximum capacity units e Target utilization per ciascuna.
5. Facoltativamente applica le stesse impostazioni a ogni GSI, e Save.

Un limite della console che vale la pena conoscere: i cooldown non sono esposti lì. La documentazione AWS stessa ti indirizza alla CLI "for more advanced features like setting scale-in and scale-out cooldown times".

Configurazione da CLI

Due chiamate per dimensione: registra lo scalable target (i limiti min/max), poi collega la policy target-tracking. Verbatim dalla guida CLI di AWS, per la capacità di scrittura su una tabella:

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 configurazione della policy vive in un file 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

Per le letture, sostituisci la dimensione con dynamodb:table:ReadCapacityUnits e la metrica con DynamoDBReadCapacityUtilization. Per una GSI, il resource id diventa table/TestTable/index/test-index con le dimensioni dynamodb:index:*. Una tabella con tre GSI che scalano entrambe le dimensioni ha quindi bisogno di otto coppie target/policy — scriptalo.

I due cooldown hanno default 0 per DynamoDB e sono le uniche manopole disponibili da CLI: ScaleOutCooldown è il minimo di secondi tra due aumenti di capacità (uno scale-out più grande passa comunque all'istante), e ScaleInCooldown blocca la diminuzione successiva — anche se uno scale-out interrompe un cooldown di scale-in invece di aspettarlo.

Scegliere i numeri

L'utilizzo target è una manopola tra margine e costo. A un target di T percento, paghi circa 100/T volte la capacità che consumi: un target del 70% compra ~1,4× di margine sopra il traffico stabile, un target del 50% ne compra 2×. Target più bassi assorbono crescite più nette senza throttling; target più alti sprecano meno prenotazione. L'intervallo è 20–90%.

La manopola si collega direttamente alla bolletta. Dalle tariffe us-east-1 attuali (stessa derivazione di DynamoDB può fare auto scaling?): la capacità Provisioned al 100% di utilizzo è ~3,46× più economica per richiesta dell'on-demand, e il punto di pareggio sta al ~29% di utilizzo. Il compito dell'auto scaling è tenere l'utilizzo reale vicino al tuo target, quindi il target sceglie di fatto il tuo sconto: tenuto al 70%, Provisioned costa ~2,4× meno dell'on-demand; al 50%, ~1,7×; sotto il ~29%, dovresti invece stare su on-demand. Controlla i numeri del tuo workload nel calcolatore dei prezzi.

La capacità minima è il tuo pavimento per i picchi: è la capacità che è già lì durante i ~5 minuti che l'auto scaling impiega a reagire. Impostala partendo dalla raffica più netta che devi assorbire senza throttling, non dal traffico medio.

La capacità massima è la protezione contro le fughe in avanti — il tetto a quanto un bug, un loop Lambda impazzito o un test di carico possono fatturarti. Impostala sopra il tuo picco realistico e tratta il fatto di raggiungerla come un allarme, non come normale funzionamento.

Lo scale-down è limitato da quota. Le diminuzioni di capacità Provisioned escono da un token bucket: inizi ogni giorno UTC con 4 disponibili, ne matura una in più all'ora (massimo 4 in mano), per al massimo 27 diminuzioni per tabella al giorno — i limiti delle GSI sono separati, ma una singola richiesta che diminuisce sia la tabella sia l'indice viene rifiutata per intero se a uno dei due lati manca la quota. Lo scale-down conservativo da 15 minuti dell'auto scaling in pratica rispetta già questo vincolo, ma è il motivo per cui la capacità scende a scatti lenti dopo un picco — e per cui un traffico oscillante finisce la giornata inchiodato più in alto della sua media.

Fallo in DynoTable

Dimensionare il minimo e validare il target partono entrambi da numeri reali, non da supposizioni: quanto sono grandi gli item, quanti sono e quanto consuma davvero una lettura o una scrittura rappresentativa. La vista tabella di DynoTable mostra il numero di item e la dimensione della tabella in tempo reale, e la sua anteprima del costo di una query mostra la stima in RCU di uno statement prima che venga eseguito — gli stessi numeri di cui è fatto un piano di capacità. Per dimensionare un singolo item, il gratuito calcolatore della dimensione degli item calcola la sua impronta in RCU/WCU.

Trappole e passi successivi

• L'auto scaling non batte la fisica per partizione. Una chiave calda va in throttling anche con capacità da vendere — vedi partizioni calde e capacità adattiva.
• Non dimenticare le GSI. Ogni indice scala (o va in throttling) per conto suo.
• La capacità riservata si somma solo a Provisioned. Se un workload è abbastanza stabile da far muovere appena l'auto scaling, la capacità riservata (classe di tabella Standard, solo modalità Provisioned) è lo sconto successivo — le tabelle on-demand non possono usarla.
• Guarda il primo giorno. ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits confrontate con la linea della capacità Provisioned in CloudWatch ti dicono in fretta se il target sta tenendo o sta oscillando.

La capacità è un asse del modello di costo; ciò che le tue query consumano è l'altro — Query vs Scan e il modello di costo degli Scan da SQL coprono quella metà.

Scarica DynoTable per leggere la dimensione reale della tua tabella, il numero di item e il costo per query prima di impegnarti su dei numeri di capacità.