É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

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.

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 par le biais du AWS CLI ou du 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
<table-name> Nom de la table que vous allez analyser SampleTable
<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> Le début de votre intervalle d'évaluation, spécifié au format ISO86 01 2022-02-21T23:00:00
<end-time> La fin de votre intervalle d'évaluation, spécifiée au format ISO86 01 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 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": "<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 page de service AWS Management Console et accédez à la page CloudWatch de service. Sélectionnez une option appropriée Région AWS 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 Average 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) :

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

    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.

  8. À 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.

    Renommez l'ConsumedWriteCapacityUnitétiquette enconsumedWCU.

    La métrique graphique avec ConsumedWriteCapacityUnitétiquette 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.

    CloudWatch console. La statistique SUM est sélectionnée dans la liste déroulante des métriques graphiques.
    CloudWatch console. 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).

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

  11. 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_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 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.

  13. 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*(m1/provisionedWCU).

    CloudWatch console. Les libellés et ceux IDs d'Expression2 sont renommés en UtilizationPercentage.
    CloudWatch console. 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é en rafale 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 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é 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é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é.