Évaluation de votre capacité provisionnée pour un dimensionnement approprié dans votre table DynamoDB - Amazon DynamoDB
Comment récupérer les métriques de consommation sur vos tables DynamoDBComment identifier les tables DynamoDB sous-provisionnéesComment identifier les tables DynamoDB surprovisionnées

É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 des unités de capacité de lecture (RCU) et des 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’ils consommeront, qui est indépendant des UCU et des WCU de la table de base.

Note

Les index secondaires locaux (LSI) consomment la capacité à partir de la table de base.

Comment récupérer les métriques de consommation sur vos tables DynamoDB

Pour évaluer la capacité de vos tables et des index secondaires globaux, surveillez les métriques CloudWatch suivantes et sélectionnez la dimension appropriée pour récupérer les informations correspondantes :

Unités de capacité de lecture Unités de capacité d’écriture

ConsumedReadCapacityUnits

ConsumedWriteCapacityUnits

ProvisionedReadCapacityUnits

ProvisionedWriteCapacityUnits

ReadThrottleEvents

WriteThrottleEvents

Pour ce faire, vous pouvez utiliser AWS CLI ou AWS Management Console.

AWS CLI

Avant de récupérer les métriques de consommation des tables, il est important de commencer par capturer certains points de données historiques à l’aide de l’API CloudWatch.

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
<table-name> Nom de la table que vous allez analyser TableXXX
<period> 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
<start-time> Début de votre intervalle d’évaluation, spécifié au format ISO8601 2022-02-21T23:00:00
<end-time> Fin de votre intervalle d’évaluation, spécifié au format ISO8601 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": "<table-name>"
            }
          ]
        },
        "Period": <period>,
        "Stat": "Average"
      },
      "Label": "Provisioned",
      "ReturnData": false
    },
    {
      "Id": "consumedWCU",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/DynamoDB",
          "MetricName": "ConsumedWriteCapacityUnits",
          "Dimensions": [
            {
              "Name": "TableName",
              "Value": "<table-name>""
            }
          ]
        },
        "Period": <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": "<start-time>",
  "EndTime": "<ent-time>",
  "ScanBy": "TimestampDescending",
  "MaxDatapoints": 24
}

Le fichier de calculs de lecture utilise un fichier similaire. Ce fichier permet de récupérer le nombre de RCU provisionnées et consommées au cours de 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": "<table-name>"
            }
          ]
        },
        "Period": <period>,
        "Stat": "Average"
      },
      "Label": "Provisioned",
      "ReturnData": false
    },
    {
      "Id": "consumedRCU",
      "MetricStat": {
        "Metric": {
          "Namespace": "AWS/DynamoDB",
          "MetricName": "ConsumedReadCapacityUnits",
          "Dimensions": [
            {
              "Name": "TableName",
              "Value": "<table-name>"
            }
          ]
        },
        "Period": <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": "<start-time>",
  "EndTime": "<end-time>",
  "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

  2. 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 à la AWS Management Console et accédez à la page du service CloudWatch. Sélectionnez une Région AWS appropriée si nécessaire.

  2. Dans la barre de navigation de gauche, sélectionnez la section Métriques, puis sélectionnez Toutes les métriques.

  3. 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.

  4. Sélectionnez Métriques de table. Cette action vous montre les tables de votre région actuelle.

  5. 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.

  6. Sélectionnez l’onglet Métriques graphiques (2) pour modifier les formules. Par défaut, CloudWatch sélectionne la fonction statistique Moyenne pour les graphiques.

    Les métriques graphiques sélectionnées et fonction Moyenne en tant que fonction statistique par défaut.

  7. 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) :

    Console CloudWatch. La fonction Pourcentage est sélectionnée pour les métriques graphiques.

    Deuxième sélection de la fonction Percentage (Pourcentage) :

    Console CloudWatch. La fonction Pourcentage est sélectionnée une seconde fois pour les métriques graphiques.

  8. À ce stade, vous devriez avoir quatre métriques dans le menu inférieur. Travaillons sur le calcul de ConsumedWriteCapacityUnits. Pour être cohérents, nous devons faire correspondre les noms avec ceux que nous avons utilisés dans la section AWS CLI. Cliquez sur l’ID m1 et remplacez cette valeur par consumedWCU.

    Console CloudWatch. La métrique graphique qui possède l’identifiant m1 est renommée consumedWCU.

    Remplacez le nom de l’étiquette ConsumedWriteCapacityUnit par consumedWCU.

    La métrique graphique qui possède l’étiquette ConsumedWriteCapacityUnit est renommée consumedWCU.

  9. Remplacez la statistique Average (Moyenne) par Sum (Somme). Cette action crée automatiquement une autre métrique appelée ANOMALY_DETECTION_BAND. 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.

    Console CloudWatch. La statistique SUM est sélectionnée dans la liste déroulante des métriques graphiques.
    Console CloudWatch. La métrique ANOMALY_DETECTION_BAND est supprimée de la liste des métriques graphiques.

  10. Répétez l’étape 8 pour remplacer le nom de l’ID m2 par provisionedWCU. Conservez la statistique Average (Moyenne).

    Console CloudWatch. La métrique graphique avec l’identifiant m2 est renommée avec provisionedWCU.

  11. Sélectionnez le libellé Expression1 et mettez à jour en remplaçant sa valeur par m1 et son libellé par Consumed WCUs (WCU consommées).

    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_DETECTION_BAND, 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).

  12. Vous devriez maintenant disposer de deux graphiques : l’un qui indique les WCU provisionnées au niveau de la table et l’autre qui indique les WCU consommées. La forme du graphique peut être différente de celle ci-dessous, mais vous pouvez l’utiliser comme référence :

    Graphique avec les WCU provisionnés et les WCU consommés pour la table tracée.

  13. Mettez à jour la formule du pourcentage en sélectionnant le graphique Expression2 (e2). Remplacez le nom des libellés et des identifiants par utilizationPercent. Remplacez le nom de la formule par 100*(m1/provisionedWCU).

    Console CloudWatch. Les étiquettes et les identifiants d’Expression2 sont renommés avec utilizationPercentage.
    Console CloudWatch. La formule de pourcentage d’Expression2 est mise à jour sur 100 x (m1/provisionedWCU).

  14. 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é.

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.

À 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, 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é de débordement est une fonctionnalité de DynamoDB qui permet aux clients de consommer temporairement plus de RCU/WCU que ce qui était initialement prévu (plus que le débit provisionné par seconde défini dans la table). 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 unités RCU et WCU inutilisées sont épuisées, vous êtes limité si vous essayez de consommer plus de capacité que celle allouée. 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é 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 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éterminer plus précisément si vous devez réduire le nombre de WCU et de RCU, réexaminez les autres lectures 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 ratio d’utilisation faible par rapport au taux de limitation (Max(ThrottleEvents)/Min(ThrottleEvents) dans l’intervalle), votre charge de travail est peut-être soumise à des pics ponctuels, où le trafic augmente considérablement certains jours (ou certaines heures) alors qu’il reste faible le reste du temps. Dans ces scénarios, il peut être utile de recourir à l’autoscaling planifié.