Comment configurer l'auto-scaling DynamoDB

L'auto-scaling DynamoDB ajuste la capacité en lecture et en écriture d'une table provisionnée vers une utilisation cible que tu choisis, pour que tu arrêtes de régler les RCU/WCU à la main et de payer une réservation dimensionnée au pire cas 24h/24. Ce guide est la moitié pratique de l'histoire de la capacité : le chemin dans la console, les commandes CLI, comment choisir concrètement les chiffres, et les délais de réaction qui throttlent quand même un pic net. Si tu n'as pas encore choisi de mode de capacité, commence par On-Demand vs Provisionné — l'auto-scaling ne s'applique qu'au mode Provisionné.

Comment activer l'auto-scaling sur une table DynamoDB ?

Dans la console : ouvre ta table, va dans Paramètres supplémentaires → Capacité en lecture/écriture → Modifier, choisis Provisionné, et passe Auto scaling sur Activé pour la capacité en lecture, en écriture, ou les deux, en donnant à chacune un minimum, un maximum et une utilisation cible (réglable entre 20 et 90 pour cent). Depuis la CLI, enregistre une cible évolutive et attache une politique de mise à l'échelle par suivi de cible avec aws application-autoscaling. Les tables créées via la console ont l'auto-scaling activé par défaut.

Ce que fait réellement l'auto-scaling

Une politique de mise à l'échelle demande à Application Auto Scaling de maintenir le rapport consommé/provisionné d'une table près de ton utilisation cible, à l'intérieur des bornes de capacité minimale et maximale que tu fixes. Sous le capot, elle crée une paire d'alarmes CloudWatch pour les limites haute et basse ; quand la consommation en franchit une, Application Auto Scaling émet un appel UpdateTable pour déplacer la capacité provisionnée.

Deux faits structurels comptent avant de configurer quoi que ce soit :

Les politiques sont par table et par GSI. Chaque index secondaire global a son propre débit provisionné, donc chacun a besoin de sa propre politique (ou de la case « mêmes paramètres pour tous les GSI » de la console). Un GSI sous-dimensionné peut throttler les écritures de la table de base — voir pourquoi un GSI throttle les écritures de la table de base.
Les tables créées dans la console adhèrent par défaut ; les GSI ajoutés ensuite ne se mettent pas à l'échelle pendant leur construction. Un nouveau GSI sur une table existante démarre en capacité manuelle pendant son backfill — surveille-le jusqu'à ce que la politique s'y attache.

Les délais que tu acceptes

L'auto-scaling est réactif, et ses temps de réaction sont fixes — AWS documente que les nombres de points de données des alarmes ne sont pas réglables :

La montée en charge se déclenche après que la capacité consommée a dépassé la cible pendant deux minutes consécutives (plus jusqu'à quelques minutes de latence d'alarme CloudWatch).
La descente en charge attend 15 points de données consécutifs d'une minute sous la cible.
Après l'un ou l'autre déclenchement, l'appel UpdateTable met plusieurs minutes à s'appliquer — et les requêtes au-dessus de l'ancien plafond sont throttlées pendant ce temps.

Ce plancher d'environ 5 minutes entre le dépassement et la nouvelle capacité est la limite honnête de la fonctionnalité : l'auto-scaling absorbe un trafic qui croît, pas un trafic qui saute d'un cran. Une vente flash qui triple la charge en une minute throttlera en capacité provisionnée quelle que soit ta politique ; cette forme-là appelle On-Demand, qui absorbe instantanément jusqu'au double de ton précédent pic (et throttle au-delà du double dans les 30 minutes — sa propre version de la même physique).

Configuration dans la console

Pour une table existante (les étapes AWS) :

Console DynamoDB → Tables → choisis la table.
Onglet Paramètres supplémentaires → Capacité en lecture/écriture → Modifier.
Mode de capacité : Provisionné.
Sous Capacité de la table, passe Auto scaling sur Activé pour la lecture, l'écriture, ou les deux, puis définis pour chacune Unités de capacité minimales, Unités de capacité maximales et Utilisation cible.
Applique éventuellement les mêmes paramètres à chaque GSI, puis Enregistrer.

Une limite de la console mérite d'être connue : les temps de récupération (cooldowns) n'y sont pas exposés. La documentation d'AWS elle-même te renvoie vers la CLI « pour des fonctionnalités plus avancées comme le réglage des temps de récupération de scale-in et de scale-out ».

Configuration en CLI

Deux appels par dimension : enregistrer la cible évolutive (les bornes min/max), puis attacher la politique de suivi de cible. Repris tels quels du tutoriel CLI d'AWS, pour la capacité en écriture d'une table :

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 configuration de la politique vit dans un fichier 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

Pour les lectures, remplace la dimension par dynamodb:table:ReadCapacityUnits et la métrique par DynamoDBReadCapacityUtilization. Pour un GSI, l'identifiant de ressource devient table/TestTable/index/test-index avec les dimensions dynamodb:index:*. Une table avec trois GSI qui met à l'échelle les deux dimensions a donc besoin de huit paires cible/politique — scripte-le.

Les deux temps de récupération valent 0 par défaut pour DynamoDB et sont les seuls réglages réservés à la CLI : ScaleOutCooldown est le nombre minimal de secondes entre deux augmentations de capacité (une montée plus grande passe quand même immédiatement), et ScaleInCooldown bloque la diminution suivante — mais une montée en charge interrompt un cooldown de descente au lieu de l'attendre.

Choisir les chiffres

L'utilisation cible est un curseur marge-contre-coût. À une cible de T pour cent, tu paies environ 100/T fois ta capacité consommée : une cible de 70 % achète ~1,4× de marge au-dessus du trafic régulier, une cible de 50 % en achète 2×. Des cibles plus basses encaissent une croissance plus brutale sans throttling ; des cibles plus hautes gaspillent moins de réservation. La plage va de 20 à 90 %.

Ce curseur est branché directement sur la facture. D'après les tarifs us-east-1 actuels (même dérivation que DynamoDB peut-il monter en charge automatiquement ?) : la capacité provisionnée à 100 % d'utilisation revient ~3,46× moins cher par requête que l'on-demand, et le point d'équilibre se situe à ~29 % d'utilisation. Le travail de l'auto-scaling est de maintenir l'utilisation réelle près de ta cible, donc la cible choisit en pratique ta remise : tenue à 70 %, la capacité provisionnée revient ~2,4× moins cher que l'on-demand ; à 50 %, ~1,7× ; en dessous de ~29 %, tu devrais plutôt être en on-demand. Vérifie les chiffres de ta propre charge de travail dans le calculateur de tarifs.

La capacité minimale est ton plancher face aux pics : c'est la capacité qui est déjà là pendant les ~5 minutes dont l'auto-scaling a besoin pour réagir. Fixe-la d'après la rafale la plus brutale que tu dois absorber sans throttling, pas d'après le trafic moyen.

La capacité maximale est une protection contre l'emballement — le plafond de ce qu'un bug, une boucle Lambda emballée ou un test de charge peut te facturer. Fixe-la au-dessus de ton pic réaliste et traite le fait de l'atteindre comme une alerte, pas comme un fonctionnement normal.

La descente en charge est limitée par un quota. Les diminutions de capacité provisionnée viennent d'un seau à jetons : tu commences chaque journée UTC avec 4 diminutions disponibles, une de plus s'accumule par heure (4 détenues au maximum), pour au plus 27 diminutions par table et par jour — les limites des GSI sont séparées, mais une seule requête qui diminue à la fois la table et l'index est rejetée en entier si l'un des deux côtés manque de quota. La descente conservatrice à 15 minutes de l'auto-scaling respecte déjà ça en pratique, mais c'est pourquoi la capacité redescend lentement, par crans, après un pic — et pourquoi un trafic oscillant termine la journée épinglé plus haut que sa moyenne.

Fais-le dans DynoTable

Dimensionner le minimum et valider la cible partent tous deux de chiffres réels, pas de suppositions : quelle est la taille des items, combien il y en a, et ce qu'une lecture ou une écriture représentative consomme vraiment. La vue table de DynoTable fait remonter le nombre et la taille d'items en direct, et son aperçu du coût d'une requête affiche l'estimation en RCU d'une instruction avant son exécution — exactement les chiffres dont un plan de capacité est fait. Pour dimensionner un seul item, le calculateur de taille d'item gratuit calcule son empreinte en RCU/WCU.

Pièges et prochaines étapes

L'auto-scaling ne bat pas la physique par partition. Une clé surchargée throttle même avec de la capacité en réserve — voir les partitions surchargées et la capacité adaptative.
N'oublie pas les GSI. Chaque index se met à l'échelle (ou throttle) de son côté.
La capacité réservée ne se cumule qu'avec le provisionné. Si une charge de travail est assez régulière pour que l'auto-scaling ne bouge presque pas, la capacité réservée (classe de table Standard, mode provisionné uniquement) est la remise suivante — les tables on-demand ne peuvent pas en profiter.
Surveille le premier jour. ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits face à la ligne du provisionné dans CloudWatch te dit vite si la cible tient ou si elle oscille.

La capacité est un axe du modèle de coût ; ce que tes requêtes consomment est l'autre — Scan vs Query et le modèle de coût des scans SQL couvrent cette moitié.

Télécharge DynoTable pour lire la taille réelle, le nombre d'items et le coût par requête de ta table avant de lui fixer des chiffres de capacité.