Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Évaluation de votre capacité provisionnée pour un dimensionnement approprié dans votre table DynamoDB Cette section explique comment évaluer si vous avez alloué la capacité appropriée pour vos tables DynamoDB. À mesure que votre charge de travail évolue, vous devez modifier vos procédures opérationnelles de manière appropriée, notamment lorsque votre table DynamoDB est configurée en mode provisionné et que vous risquez de surprovisionner ou de sous-provisionner vos tables. Les procédures décrites ci-dessous nécessitent des informations statistiques qui doivent être capturées à partir des tables DynamoDB qui prennent en charge votre application de production. Pour comprendre le comportement de votre application, vous devez définir une période suffisamment longue pour tenir compte de la saisonnalité de ses données. Par exemple, si votre application repose sur des cycles hebdomadaires, spécifier une période de trois semaines devrait vous laisser suffisamment de marge pour analyser ses besoins en matière de débit. Si vous ne savez pas par où commencer, utilisez au moins un mois de données pour les calculs ci-dessous. Lors de l'évaluation de la capacité, les tables DynamoDB peuvent **configurer les unités de capacité de lecture RCUs () et les unités** **de capacité d'écriture (WCU) indépendamment**. Si des index secondaires globaux (GSI) sont configurés sur vos tables, vous devez spécifier le débit qu'elles consommeront, qui sera également indépendant de la table de base RCUs et WCUs de celle-ci. **Note** Les index secondaires locaux (LSI) consomment la capacité à partir de la table de base. **Topics** + [Comment récupérer les métriques de consommation sur vos tables DynamoDB](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics) + [Comment identifier les tables DynamoDB sous-provisionnées](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables) + [Comment identifier les tables DynamoDB surprovisionnées](#CostOptimization_RightSizedProvisioning_OverProvisionedTables) ## Comment récupérer les métriques de consommation sur vos tables DynamoDB Pour évaluer la table et la capacité du GSI, surveillez les CloudWatch mesures suivantes et sélectionnez la dimension appropriée pour récupérer les informations du tableau ou du GSI : | Unités de capacité de lecture | Unités de capacité d’écriture | | --- | --- | | `ConsumedReadCapacityUnits` | `ConsumedWriteCapacityUnits` | | `ProvisionedReadCapacityUnits` | `ProvisionedWriteCapacityUnits` | | `ReadThrottleEvents` | `WriteThrottleEvents` | Vous pouvez le faire via le AWS CLI ou le AWS Management Console. ------ #### [ AWS CLI ] Avant de récupérer les indicateurs de consommation du tableau, nous devons commencer par capturer certains points de données historiques à l'aide de l' CloudWatch API. Commencez par créer deux fichiers : `write-calc.json` et `read-calc.json`. Ces fichiers représentent les calculs pour une table ou un index secondaire global. Vous devrez mettre à jour certains champs, comme indiqué dans le tableau ci-dessous, pour les adapter à votre environnement. | Nom de champ | Définition | Exemple | | --- | --- | --- | | | Nom de la table que vous allez analyser | SampleTable | | | Période que vous utiliserez pour évaluer la cible d’utilisation, en secondes | Pour une période d’une heure, vous devez spécifier : 3 600 | | | Le début de votre intervalle d'évaluation, spécifié dans le ISO8601 format | 2022-02-21T23:00:00 | | | La fin de votre intervalle d'évaluation, spécifiée dans le ISO8601 format | 2022-02-22T06:00:00 | Le fichier de calculs d’écriture récupérera le nombre de WCU provisionnées et consommées au cours de la période correspondant à la plage de dates spécifiée. Il générera également un pourcentage d’utilisation qui sera utilisé pour l’analyse. Le contenu entier du fichier `write-calc.json` doit se présenter comme suit : ``` { "MetricDataQueries": [ { "Id": "provisionedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ProvisionedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ConsumedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": """ } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedWCU/PERIOD(consumedWCU)", "Label": "Consumed WCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedWCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` Le fichier de calculs de lecture utilise un fichier similaire. Ce fichier récupérera combien RCUs ont été approvisionnés et consommés pendant la période correspondant à la plage de dates spécifiée. Le contenu du fichier `read-calc.json` doit se présenter comme suit : ``` { "MetricDataQueries": [ { "Id": "provisionedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ProvisionedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/DynamoDB", "MetricName": "ConsumedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Sum" }, "Label": "", "ReturnData": false }, { "Id": "m1", "Expression": "consumedRCU/PERIOD(consumedRCU)", "Label": "Consumed RCUs", "ReturnData": false }, { "Id": "utilizationPercentage", "Expression": "100*(m1/provisionedRCU)", "Label": "Utilization Percentage", "ReturnData": true } ], "StartTime": "", "EndTime": "", "ScanBy": "TimestampDescending", "MaxDatapoints": 24 } ``` Une fois les fichiers créés, vous pouvez commencer à récupérer les données d’utilisation. 1. Pour récupérer les données d’utilisation des écritures, émettez la commande suivante : ``` aws cloudwatch get-metric-data --cli-input-json file://write-calc.json ``` 1. Pour récupérer les données d’utilisation des lectures, émettez la commande suivante : ``` aws cloudwatch get-metric-data --cli-input-json file://read-calc.json ``` Le résultat des deux requêtes correspond à une série de points de données au format JSON qui serviront à l’analyse. Votre résultat dépendra du nombre de points de données que vous avez spécifiés, de la période et de vos données de charge de travail spécifiques. Voici ce à quoi il pourrait ressembler : ``` { "MetricDataResults": [ { "Id": "utilizationPercentage", "Label": "Utilization Percentage", "Timestamps": [ "2022-02-22T05:00:00+00:00", "2022-02-22T04:00:00+00:00", "2022-02-22T03:00:00+00:00", "2022-02-22T02:00:00+00:00", "2022-02-22T01:00:00+00:00", "2022-02-22T00:00:00+00:00", "2022-02-21T23:00:00+00:00" ], "Values": [ 91.55364583333333, 55.066631944444445, 2.6114930555555556, 24.9496875, 40.94725694444445, 25.61819444444444, 0.0 ], "StatusCode": "Complete" } ], "Messages": [] } ``` **Note** Si vous spécifiez une période courte et une plage de temps longue, vous devrez peut-être modifier la valeur `MaxDatapoints` par défaut, qui est de 24, dans le script. Cela représente un seul point de données par heure et donc 24 points de données par jour. ------ #### [ AWS Management Console ] 1. Connectez-vous AWS Management Console et accédez à la page CloudWatch de service. Sélectionnez une option appropriée Région AWS si nécessaire. 1. Dans la barre de navigation de gauche, sélectionnez la section **Métriques**, puis sélectionnez **Toutes les métriques**. 1. Cela ouvrira un tableau de bord avec deux panneaux. Le panneau supérieur affiche le graphique, tandis que le panneau inférieur contient les métriques que vous souhaitez représenter graphiquement. Choisissez **DynamoDB**. 1. Sélectionnez **Métriques de table**. Cette action vous montre les tables de votre région actuelle. 1. Utilisez le champ de recherche pour rechercher le nom de votre table et choisir les métriques de l’opération d’écriture : `ConsumedWriteCapacityUnits` et `ProvisionedWriteCapacityUnits`. **Note** Cet exemple décrit les métriques des opérations d’écriture, mais vous pouvez également suivre ces étapes pour représenter graphiquement les métriques des opérations de lecture. 1. Sélectionnez l’onglet **Métriques graphiques (2)** pour modifier les formules. Par défaut, CloudWatch sélectionne la fonction statistique **Average** pour les graphiques. ![\[Les métriques graphiques sélectionnées et fonction Moyenne en tant que fonction statistique par défaut.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning1.png) 1. Lorsque les deux mesures représentées dans le graphique sont sélectionnées (case à cocher sur la gauche), sélectionnez le menu **Add math** (Ajouter une formule), suivi de **Common** (Commun), puis sélectionnez la fonction **Percentage** (Pourcentage). Répétez cette procédure deux fois. Première sélection de la fonction **Percentage** (Pourcentage) : ![\[CloudWatch console. La fonction Pourcentage est sélectionnée pour les métriques graphiques.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning2.png) Deuxième sélection de la fonction **Percentage** (Pourcentage) : ![\[CloudWatch console. La fonction Pourcentage est sélectionnée une seconde fois pour les métriques graphiques.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning3.png) 1. À ce stade, vous devriez avoir quatre métriques dans le menu inférieur. Travaillons sur le calcul de `ConsumedWriteCapacityUnits`. Par souci de cohérence, nous devons faire correspondre les noms de ceux que nous avons utilisés dans la AWS CLI section. Cliquez sur l’**ID m1** et remplacez cette valeur par **consumedWCU**. ![\[CloudWatch console. La métrique graphique qui possède l’identifiant m1 est renommée consumedWCU.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning4.png) Renommez l'**ConsumedWriteCapacityUnit**étiquette en**consumedWCU**. ![\[La métrique graphique avec ConsumedWriteCapacityUnitétiquette est renommée ConsumedWCU.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning5.png) 1. Remplacez la statistique **Average** (Moyenne) par **Sum** (Somme). Cette action crée automatiquement une autre métrique appelée **ANOMALY\$1DETECTION\$1BAND**. Dans le cadre de cette procédure, nous pouvons l’ignorer en supprimant la case à cocher au niveau de la **métrique ad1** qui vient d’être générée. ![\[CloudWatch console. La statistique SUM est sélectionnée dans la liste déroulante des métriques graphiques.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning6.png) ![\[CloudWatch console. La métrique ANOMALY_DETECTION_BAND est supprimée de la liste des métriques graphiques.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning7.png) 1. Répétez l’étape 8 pour remplacer le nom de l’**ID m2** par **provisionedWCU**. Conservez la statistique **Average** (Moyenne). ![\[CloudWatch console. La métrique graphique avec l’identifiant m2 est renommée avec provisionedWCU.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning8.png) 1. **Sélectionnez l'étiquette **Expression1** et mettez à jour la valeur en **m1** et l'étiquette en Consumed. WCUs** **Note** Assurez-vous de n’avoir sélectionné que **m1** (case à cocher sur la gauche) et **provisionedWCU** pour visualiser correctement les données. Mettez à jour la formule en cliquant sur **Details** (Détails) et en remplaçant la formule par **consumedWCU/PERIOD(consumedWCU)**. Cette étape peut également générer une autre métrique **ANOMALY\$1DETECTION\$1BAND**, mais dans le cadre de cette procédure, nous pouvons l’ignorer. ![\[m1 et provisionedWCU sont sélectionnés. Les détails de m1 sont mis à jour sous la forme consumedWCU/PERIOD(consumedWCU).\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning10.png) 1. Vous devriez maintenant avoir deux graphiques : l'un qui indique votre provisionnement WCUs sur le tableau et l'autre qui indique la consommation WCUs. La forme du graphique peut être différente de celle ci-dessous, mais vous pouvez l’utiliser comme référence : ![\[Graphique illustrant les ressources provisionnées WCUs et consommées WCUs pour le tableau.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning11.png) 1. Mettez à jour la formule du pourcentage en sélectionnant le graphique Expression2 (**e2**). Renommez les étiquettes en IDs **UtilizationPercentage**. Remplacez le nom de la formule par **100\$1(m1/provisionedWCU)**. ![\[CloudWatch console. Les labels et IDs pour Expression2 sont renommés en UtilizationPercentage.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning12.png) ![\[CloudWatch console. La formule de pourcentage d’Expression2 est mise à jour sur 100 x (m1/provisionedWCU).\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning13.png) 1. Décochez la case de toutes les métriques, à l’exception de la métrique **utilizationPercent** pour visualiser vos modèles d’utilisation. L’intervalle par défaut est défini sur 1 minute, mais n’hésitez pas à le modifier selon vos besoins. ![\[Graphique de la métrique utilizationPercentage pour l’intervalle de temps sélectionné.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning14.png) Voici une vue d’une période plus longue ainsi que d’une période d’une heure. Vous pouvez constater que l’utilisation était supérieure à 100 % à certains intervalles, mais cette charge de travail particulière présente des intervalles plus longs avec une utilisation nulle. ![\[Modèle d’utilisation pour une période de temps prolongée. Il met en évidence les périodes d’utilisation supérieures à 100 % et nulles.\]](http://docs.aws.amazon.com/fr_fr/amazondynamodb/latest/developerguide/images/CostOptimization/RightSizedProvisioning15.png) À ce stade, les résultats peuvent différer de ceux des images de cet exemple. Tout dépend des données de votre charge de travail. Les intervalles avec une utilisation supérieure à 100 % sont sujets à des événements de limitation. DynamoDB offre une [capacité de débordement](burst-adaptive-capacity.md#burst-capacity), mais dès que cette capacité est atteinte, tout ce qui dépasse 100 % est limité. ------ ## Comment identifier les tables DynamoDB sous-provisionnées Pour la plupart des charges de travail, une table est considérée comme sous-provisionnée lorsqu’elle consomme constamment plus de 80 % de sa capacité provisionnée. La [capacité en rafale](burst-adaptive-capacity.md#burst-capacity) est une fonctionnalité de DynamoDB qui permet aux clients de consommer temporairement RCUs/WCUs plus que ce qui était initialement prévu (plus que le débit provisionné par seconde défini dans le tableau). La capacité de débordement a été créée pour absorber les augmentations soudaines du trafic dues à des événements spéciaux ou à des pics d’utilisation. Elle ne dure pas éternellement. Dès que les capacités inutilisées RCUs et épuisées WCUs sont épuisées, vous serez limité si vous essayez de consommer plus de capacité que celle prévue. Lorsque le trafic de votre application approche le taux d’utilisation de 80 %, le risque de limitation est nettement plus élevé. La règle du taux d’utilisation de 80 % varie en fonction de la saisonnalité de vos données et de la croissance du trafic. Réfléchissez aux scénarios suivants : + Si le trafic est resté **stable à un** taux d’utilisation d’environ 90 % au cours des 12 derniers mois, votre table dispose de la capacité idéale + Si le trafic de vos applications **augmente** à un rythme de 8 % par mois en moins de 3 mois, vous allez atteindre une utilisation de 100 % + Si le trafic de vos applications **augmente** à un rythme de 5 % en un peu plus de 4 mois, vous allez tout de même atteindre une utilisation de 100 % Les résultats des requêtes ci-dessus donnent une idée de votre taux d’utilisation. Utilisez-les comme guide pour évaluer plus en détail d’autres métriques qui pourront vous aider à choisir d’augmenter la capacité de votre table selon vos besoins (par exemple, à un taux de croissance mensuel ou hebdomadaire). Travaillez avec l’équipe des opérations pour définir le pourcentage approprié pour votre charge de travail et vos tables. Il existe des scénarios particuliers dans lesquels les données sont biaisées lorsque nous les analysons sur une base quotidienne ou hebdomadaire. Par exemple, pour les applications saisonnières qui connaissent des pics d’utilisation pendant les heures de travail (mais qui tombent ensuite presque à zéro en dehors de ces plages horaires), vous pourriez bénéficier de l’[autoscaling planifié](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html) qui permet de spécifier les heures de la journée (et les jours de la semaine) pour lesquels vous souhaitez augmenter la capacité provisionnée, et quand la réduire. Au lieu de viser une capacité plus élevée pour couvrir les heures de pointe, vous pouvez également tirer parti des configurations de l’[autoscaling des tables DynamoDB](AutoScaling.md) si la saisonnalité de vos données est moins prononcée. **Note** Lorsque vous créez une configuration de mise à l’échelle automatique de DynamoDB pour votre table de base, n’oubliez pas d’inclure une autre configuration pour les index secondaires globaux qui y sont associés. ## Comment identifier les tables DynamoDB surprovisionnées Les résultats de requête obtenus à partir des scripts ci-dessus fournissent les points de données nécessaires pour effectuer une analyse initiale. Si votre ensemble de données présente des valeurs d’utilisation inférieures à 20 % pendant plusieurs intervalles, votre table est peut-être surprovisionnée. Pour définir plus précisément s'il est nécessaire de réduire le nombre de RCUS WCUs et de RCUS, vous devez revoir les autres relevés dans les intervalles. Lorsque des tables contiennent plusieurs intervalles d’utilisation faibles, vous pouvez tirer parti de l’utilisation de politiques d’autoscaling automatique en planifiant l’autoscaling automatique ou en configurant simplement les politiques d’autoscaling par défaut pour la table en fonction de l’utilisation. Si votre charge de travail présente un faible ratio d'utilisation/accélération élevé (**Max (ThrottleEvents) /Min (ThrottleEvents)** dans l'intervalle), cela peut se produire lorsque vous avez une charge de travail très élevée où le trafic augmente considérablement pendant certains jours (ou heures), mais en général, le trafic est constamment faible. Dans ces scénarios, il peut être utile de recourir à l’[autoscaling planifié](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html).