Capacité provisionnée ou à la demande

DynamoDB mesure le débit en unités de capacité de lecture (RCU) et en unités de capacité d’écriture (WCU). Une RCU permet une lecture à cohérence forte par seconde (ou deux lectures à cohérence éventuelle) pour des éléments allant jusqu’à 4 Ko. Une WCU permet une écriture par seconde pour des éléments allant jusqu’à 1 Ko.

Pour les éléments plus volumineux, le coût augmente proportionnellement : une écriture de 10 Ko coûte 10 WCU ; une lecture à cohérence forte de 10 Ko coûte 3 RCU (ceil(10/4) = 3). Comprendre les unités de capacité est essentiel pour estimer les coûts et diagnostiquer les erreurs de limitation ProvisionedThroughputExceededException.

En mode Provisioned Capacity, vous spécifiez le nombre exact de RCU et de WCU que votre table doit prendre en charge. DynamoDB réserve ce débit et vous le facture, que vous l’utilisiez ou non. Si votre application dépasse la capacité provisionnée, les requêtes sont limitées et renvoient une ProvisionedThroughputExceededException.

Le mode provisionné convient parfaitement aux charges de travail caractérisées par un trafic prévisible et stable. Le coût par unité est inférieur à celui du mode à la demande, et vous pouvez le réduire davantage en achetant une capacité réservée DynamoDB (engagements d’un ou de trois ans avec jusqu’à 76 % de réduction).

En mode On-Demand, DynamoDB s’adapte automatiquement pour prendre en charge tout niveau de trafic, sans planification de capacité. Vous payez par requête : pour chaque RRU (unité de requête de lecture) et chaque WRU (unité de requête d’écriture) réellement consommées. Il n’y a aucune capacité provisionnée à gérer ni limitation due à des limites provisionnées.

Le mode à la demande convient parfaitement aux situations suivantes : charges de travail imprévisibles ou caractérisées par des pics, nouvelles tables dont le trafic est inconnu, et environnements de développement et de test peu fréquemment utilisés. Le coût par requête est supérieur à celui du mode provisionné ; pour les charges de travail stables à haut débit, le mode provisionné est donc plus économique.

Vous pouvez basculer une table entre les modes provisionné et à la demande à tout moment à l’aide de la console ou de la CLI. Toutefois, vous ne pouvez changer de mode qu’une fois toutes les 24 heures. Après le passage au mode à la demande, la table conserve l’ancienne capacité provisionnée maximale comme niveau de débit initial, ce qui la protège contre une limitation immédiate si le trafic est déjà élevé.

Une stratégie courante consiste à utiliser le mode à la demande lors du lancement initial, lorsque les profils de trafic sont inconnus, puis à passer au mode provisionné avec mise à l’échelle automatique une fois que le trafic devient prévisible, afin de réduire les coûts.

La mise à l’échelle automatique de DynamoDB ajuste automatiquement vos RCU et WCU provisionnées en fonction du trafic réel. Vous définissez un pourcentage d’utilisation cible (par exemple, 70 %) ainsi qu’une plage de capacité minimale et maximale. Une stratégie Application Auto Scaling surveille la capacité consommée par la table et ajuste la capacité provisionnée pour maintenir l’utilisation cible.

La mise à l’échelle automatique réagit aux changements durables du trafic et peut prendre quelques minutes pour augmenter la capacité. Elle ne gère pas bien les pics soudains de trafic : dans ce cas, préchauffez manuellement la capacité ou utilisez plutôt le mode à la demande.

DynamoDB conserve jusqu’à 5 minutes de capacité provisionnée inutilisée sous forme de capacité en rafale. Lorsque le trafic de votre table dépasse brièvement le niveau provisionné, DynamoDB puise dans ce pool de réserve pour traiter les requêtes supplémentaires sans limitation. Une fois le pool épuisé, les requêtes excédentaires suivantes sont limitées.

La capacité en rafale est un tampon à court terme et ne remplace pas une planification correcte de la capacité. Surveillez les métriques CloudWatch ConsumedReadCapacityUnits et ConsumedWriteCapacityUnits pour détecter les situations où votre charge de travail consomme constamment la capacité en rafale et ajuster le débit provisionné en conséquence.

Lorsque la capacité provisionnée est dépassée et que la capacité en rafale est épuisée, DynamoDB renvoie ProvisionedThroughputExceededException. Les SDK AWS incluent une logique de nouvelle tentative intégrée, avec temporisation exponentielle et variation aléatoire, qui relance automatiquement les requêtes limitées.

Pour diagnostiquer les limitations, consultez les métriques CloudWatch SystemErrors et ThrottledRequests. Si certaines clés de partition sont limitées alors que l’utilisation globale de la table est faible, vous êtes confronté à un problème de partition surchargée : repensez la clé de partition, ajoutez une clé de tri ou utilisez le partitionnement des écritures.

Pour estimer la capacité en mode provisionné :

• Calculez le nombre maximal d’écritures par seconde × la taille moyenne d’un élément / 1 Ko (arrondi à l’entier supérieur) = nombre de WCU nécessaires
• Calculez le nombre maximal de lectures par seconde × la taille moyenne d’un élément / 4 Ko (arrondi à l’entier supérieur) = nombre de RCU nécessaires (à cohérence forte) ; divisez par deux pour une cohérence éventuelle
• Ajoutez une marge de 20 à 30 % au-dessus du pic afin d’absorber les pointes avant l’épuisement de la capacité en rafale

Exemple : 1 000 écritures/s d’éléments de 2 Ko = 2 000 WCU. 5 000 lectures/s d’éléments de 8 Ko (à cohérence éventuelle) = ceil(8/4) × 5 000 / 2 = 5 000 RCU.

La capacité réservée DynamoDB vous permet d’acheter un nombre fixe de RCU et de WCU pour une durée d’un ou de trois ans, avec un paiement initial donnant droit à une réduction importante (jusqu’à 76 %) par rapport à la tarification à la demande. La capacité réservée s’applique à toutes les tables provisionnées d’une Région et est automatiquement déduite de vos frais horaires.

La capacité réservée s’applique uniquement au mode provisionné : vous ne pouvez pas l’utiliser avec le mode à la demande. Il s’agit de la meilleure option pour réduire les coûts des charges de travail stables et prévisibles que vous pouvez prévoir avec certitude sur une période de 1 à 3 ans.

Utilisez ce guide de décision pour les questions de l’examen SAA-C03 sur les modes de capacité :

• On-Demand : trafic imprévisible, nouvelle application, accès peu fréquent, charge de travail avec des pics, ou absence totale de gestion de la capacité souhaitée
• Provisioned : trafic régulier et prévisible, sensibilité aux coûts, volonté de gérer la capacité et possibilité de bénéficier des réductions liées à la capacité réservée
• Provisioned + Auto Scaling : niveau de base prévisible avec une certaine variabilité, et souhait d’un ajustement automatique sans modifications manuelles

À l’examen, des mots-clés comme « en dents de scie », « imprévisible » ou « charge opérationnelle minimale » indiquent le mode à la demande ; « trafic régulier » ou « optimisation des coûts » indiquent le mode provisionné.

La capacité adaptative de DynamoDB redistribue automatiquement le débit des partitions peu sollicitées vers les partitions très sollicitées, en temps réel. Si une clé de partition reçoit davantage de trafic que la part qui lui est allouée, la capacité adaptative emprunte du débit aux partitions sous-utilisées pour prendre en charge la partition surchargée, tant que la capacité totale de la table n’est pas dépassée.

La capacité adaptative est toujours activée et ne nécessite aucune configuration. Elle réduit les limitations des partitions surchargées pour les profils d’accès modérément déséquilibrés. Pour les charges de travail fortement asymétriques (par exemple, lorsqu’une clé de partition reçoit 90 % du trafic), la capacité adaptative ne suffit pas : vous devez repenser la clé de partition ou utiliser le partitionnement des écritures.

Vérifiez votre compréhension des concepts d’architecte de solutions AWS (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que le mode provisionné définit des RCU/WCU fixes pour les charges de travail prévisibles à moindre coût, que le mode à la demande s’adapte automatiquement au trafic imprévisible avec un prix par requête plus élevé, et que la mise à l’échelle automatique ajuste la capacité provisionnée en fonction de pourcentages d’utilisation cibles. Nous allons ensuite étudier les Global Secondary Indexes et les Local Secondary Indexes pour prendre en charge d’autres modes de requête.