Évaluez votre capacité allouée pour un provisionnement adapté 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.

Évaluez votre capacité allouée pour un provisionnement adapté 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 () indépendamment. WCU 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é de la table de base.

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

Pour évaluer la table et la GSI capacité, surveillez les CloudWatch mesures suivantes et sélectionnez la dimension appropriée pour récupérer la table ou GSI les informations :

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 du CloudWatch API.

Commencez par créer deux fichiers : write-calc.json et read-calc.json. Ces fichiers représenteront les calculs pour une table ouGSI. 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 fournitures WCU et de consommations 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 sera une série de points de données au JSON format qui sera utilisé pour 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. Localisez la section Mesures dans la barre de navigation de gauche et sélectionnez Toutes les mesures.

  3. Cela ouvrira un tableau de bord avec deux panneaux. Le panneau supérieur affiche le graphique, tandis que le panneau inférieur affiche les indicateurs que vous souhaitez représenter graphiquement. Choisissez DynamoDB.

  4. Choisissez Table Metrics. 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. Choisissez l'onglet Graphed metrics (2) pour modifier les formules. Par défaut, CloudWatch sélectionne la fonction statistique Average pour les graphiques.

    Les mesures graphiques sélectionnées et la fonction moyenne comme 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 représentées graphiquement.

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

    CloudWatch console. La fonction Pourcentage est sélectionnée une deuxième fois pour les métriques représentées graphiquement.

  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'identifiant m1 et remplacez cette valeur par consumée WCU.

    CloudWatch console. La métrique représentée graphiquement avec l'identifiant m1 est renommée WCUconsumée.

    Renommez l'ConsumedWriteCapacityUnitétiquette enconsumedWCU.

    La métrique représentée graphiquement avec ConsumedWriteCapacityUnitétiquette est renommée WCUconsumée.

  9. Remplacez la statistique Average (Moyenne) par Sum (Somme). Cette action créera automatiquement une autre métrique appelée ANOMALY_ DETECTION _ BAND. Dans le cadre de cette procédure, ignorons-la en supprimant la case à cocher sur la métrique ad1 nouvellement générée.

    CloudWatch console. La statistique SUMest sélectionnée dans la liste déroulante des métriques représentées graphiquement.
    CloudWatch console. La BAND métrique ANOMALYDETECTION_ _ est supprimée de la liste des métriques représentées graphiquement.

  10. Répétez l'étape 8 pour renommer le m2 ID en WCUprovisioned. Conservez la statistique Average (Moyenne).

    CloudWatch console. La métrique graphique avec l'identifiant m2 est renommée en WCUprovisioned.

  11. Sélectionnez l'étiquette Expression1 et mettez à jour la valeur en m1 et l'étiquette en Consumed. WCUs

    Note

    Assurez-vous que vous n'avez sélectionné que m1 (case à cocher sur la gauche) et que vous l'avez configuré WCU pour visualiser correctement les données. Mettez à jour la formule en cliquant sur Détails et en la remplaçant par consuméeWCU/PERIOD(consomméeWCU). Cette étape peut également générer une autre BAND métrique ANOMALYDETECTION_ _, mais dans le cadre de cette procédure, nous pouvons l'ignorer.

    m1 et provisioned WCU sont sélectionnés. Les détails de m1 sont mis à jour sous la forme consuméeWCU/PERIOD(consomméeWCU).

  12. Vous devriez maintenant avoir deux graphiques : l'un qui indique votre provisionnement WCUs sur le tableau et l'autre qui indique la consommationWCUs. 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 libellés et IDs à. utilizationPercentage Renommez la formule pour qu'elle corresponde à 100* (WCUm1/provisionné).

    CloudWatch console. Les libellés et IDs ceux d'Expression2 sont renommés en. utilizationPercentage
    CloudWatch console. La formule de pourcentage pour Expression2 est mise à jour à 100* (m1/provisionné). WCU

  14. Supprimez la case à cocher de tous les indicateurs, sauf utilizationPercentagepour 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 utilizationPercentage métrique 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.

Schéma d'utilisation pendant une période 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 plus deWCUs/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, dans le cas des applications saisonnières dont l'utilisation augmente pendant les heures de travail (mais qui tombe ensuite à presque zéro en dehors des heures de travail), vous pourriez bénéficier de la planification d'une mise à l'échelle automatique dans laquelle vous spécifiez les heures de la journée (et les jours de la semaine) afin d'augmenter la capacité allouée et de savoir quand la réduire. Au lieu de viser une capacité accrue pour couvrir les heures de pointe, vous pouvez également tirer parti des configurations de mise à l'échelle automatique des tables DynamoDB si votre saisonnalité est moins prononcée.

Note

Lorsque vous créez une configuration de dimensionnement automatique DynamoDB pour votre table de base, pensez à inclure une autre configuration GSI pour toutes les configurations associées à la table.

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 si vous devez réduire le nombre de WCUs etRCUS, vous devez revoir les autres lectures dans les intervalles.

Lorsque vos tables contiennent plusieurs intervalles d'utilisation réduits, vous pouvez réellement tirer parti de l'utilisation de politiques de dimensionnement automatique, soit en programmant le dimensionnement automatique, soit en configurant simplement les politiques de dimensionnement automatique 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 avantageux d'utiliser le dimensionnement automatique programmé.