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.
Identifiez vos ressources inutilisées dans DynamoDB
Cette section explique comment évaluer régulièrement vos ressources inutilisées. À mesure que les exigences de votre application évoluent, vous devez vous assurer qu'aucune ressource n'est inutilisée et ne contribue à des coûts inutiles pour Amazon DynamoDB. Les procédures décrites ci-dessous utiliseront les CloudWatch métriques Amazon pour identifier les ressources inutilisées et vous aideront à identifier ces ressources et à prendre les mesures nécessaires pour réduire les coûts.
Vous pouvez surveiller DynamoDB à CloudWatch l'aide de ce qui collecte et traite les données brutes de DynamoDB en métriques lisibles quasiment en temps réel. Ces statistiques étant conservées pendant un certain temps, vous pouvez accéder aux informations historiques pour acquérir une meilleure compréhension de votre utilisation. Par défaut, les données métriques DynamoDB sont envoyées automatiquement à. CloudWatch Pour plus d'informations, consultez Qu'est-ce qu'Amazon CloudWatch ? et conservation des métriques dans le guide de CloudWatch l'utilisateur Amazon.
Rubriques
- Comment identifier les ressources inutilisées
- Identification des ressources de table inutilisées
- Nettoyage des ressources de table inutilisées
- Identification des GSI ressources inutilisées
- Nettoyage des GSI ressources inutilisées
- Nettoyage des tables globales inutilisées
- Nettoyage des sauvegardes ou point-in-time des restaurations non utilisées (PITR)
Comment identifier les ressources inutilisées
Pour identifier les tables ou les index inutilisés, nous examinerons les CloudWatch indicateurs suivants sur une période de 30 jours afin de déterminer s'il existe des lectures ou des écritures actives sur la table ou des lectures sur les index secondaires globaux () GSIs :
ConsumedReadCapacityUnits
Nombre d'unités de capacité de lecture consommées sur la période spécifiée, de sorte que vous puissiez suivre la capacité consommée. Vous pouvez extraire la capacité totale de lecture consommée pour une table et tous ses index secondaires globaux, ou pour un index secondaire global particulier.
ConsumedWriteCapacityUnits
Nombre d'unités de capacité d'écriture consommées sur la période spécifiée, de sorte que vous puissiez suivre la capacité consommée. Vous pouvez extraire la capacité totale d'écriture consommée pour une table et tous ses index secondaires globaux, ou pour un index secondaire global particulier.
Identification des ressources de table inutilisées
Amazon CloudWatch est un service de surveillance et d'observabilité qui fournit les métriques des tables DynamoDB que vous utiliserez pour identifier les ressources inutilisées. CloudWatch les métriques peuvent être consultées à AWS Management Console la fois par le biais du AWS Command Line Interface.
Nettoyage des ressources de table inutilisées
Si vous avez identifié des ressources de table inutilisées, vous pouvez réduire leurs coûts permanents de la manière suivante.
Note
Si vous avez identifié une table non utilisée mais que vous souhaitez la garder à disposition pour un accès futur, pensez à la passer en mode à la demande. Sinon, vous pouvez envisager de sauvegarder et de supprimer entièrement la table.
Modes de capacité
DynamoDB facture la lecture, l'écriture et le stockage de données dans vos tables DynamoDB.
DynamoDB propose deux modes de capacité, qui offrent des options de facturation spécifiques pour traiter les lectures et écritures dans vos tables. Le mode de capacité en lecture/écriture détermine la façon dont le débit de lecture et écriture vous est facturé et votre façon de gérer la capacité.
Pour les tables en mode à la demande, vous devez spécifier le débit de lecture et d'écriture que votre application est supposée atteindre. DynamoDB facture les lectures et écritures que votre application effectue dans vos tables, comptabilisées en termes d'unités de demande de lecture et d'unités de demande d'écriture. S'il n'y a aucune activité sur votre table/index, vous ne payez pas le débit, mais vous devrez tout de même payer des frais de stockage.
Classe de table
DynamoDB propose deux classes de tables conçues pour vous aider à optimiser vos coûts. La classe de tables DynamoDB Standard est la classe par défaut. Elle est recommandée pour la plupart des charges de travail. La classe de tables DynamoDB Standard-Inrequent Access (DynamoDB Standard-IA) est optimisée pour les tables où le stockage est le coût dominant.
S'il n'y a aucune activité sur votre table ou votre index, le stockage sera probablement le principal coût et le changement de classe de table permettra de réaliser des économies importantes.
Suppression des tables
Si vous avez découvert une table inutilisée et que vous souhaitez la supprimer, vous pouvez d'abord effectuer une sauvegarde ou une exportation des données.
Les sauvegardes effectuées via AWS Backup peuvent tirer parti de la hiérarchisation du stockage à froid, ce qui permet de réduire encore les coûts. Reportez-vous à la Utilisation AWS Backup avec DynamoDB documentation pour savoir comment activer les sauvegardes via AWS Backup, ainsi qu'à la documentation sur la gestion des plans de sauvegarde pour savoir comment utiliser le cycle de vie pour transférer votre sauvegarde vers un stockage à froid.
Vous pouvez également choisir d'exporter les données de votre table vers S3. Pour ce faire, consultez la documentation relative à l'exportation vers Amazon S3. Une fois vos données exportées, si vous souhaitez tirer parti de S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval ou S3 Glacier Deep Archive afin de réduire davantage les coûts, consultez Gestion de votre cycle de vie de stockage.
Une fois votre table sauvegardée, vous pouvez choisir de la supprimer via la AWS Management Console ou via l' AWS Command Line Interface.
Identification des GSI ressources inutilisées
Les étapes d'identification d'un secondaire global non utilisé sont similaires à celles d'identification d'une table non utilisée. Étant donné que DynamoDB réplique les éléments écrits dans votre table de base dans GSI votre s'ils contiennent l'attribut utilisé comme GSI clé de partition, une valeur GSI non utilisée est susceptible d'ConsumedWriteCapacityUnits
avoir une valeur supérieure à 0 si sa table de base est utilisée. Par conséquent, vous n'évaluerez que la ConsumedReadCapacityUnits
métrique pour déterminer si la vôtre n'GSIest pas utilisée.
Pour consulter vos GSI statistiques via le AWS AWS CLI, vous pouvez utiliser les commandes suivantes pour évaluer les lectures de vos tables :
aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time <start-time> --end-time <end- time> --period <period> --namespace AWS/DynamoDB --statistics Sum -- dimensions Name=TableName,Value=<table-name> Name=GlobalSecondaryIndexName,Value=<index-name>
Pour éviter de faussement identifier une table comme étant inutilisée, vous devez évaluer les indicateurs sur une période plus longue. Choisissez une plage d'heure de début et de fin appropriée, par exemple 30 jours, et une période appropriée, telle que 86400.
Dans les données renvoyées, toute somme supérieure à 0 indique que la table que vous évaluez a reçu du trafic de lecture pendant cette période.
Le résultat suivant montre un trafic de lecture GSI reçu au cours de la période évaluée :
{ "Timestamp": "2022-08-17T21:20:00Z", "Sum": 36319167.0, "Unit": "Count" }, { "Timestamp": "2022-08-11T21:20:00Z", "Sum": 1869136.0, "Unit": "Count" },
Le résultat suivant indique un trafic de lecture minimal GSI reçu au cours de la période évaluée :
{ "Timestamp": "2022-08-28T21:20:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-15T21:20:00Z", "Sum": 2.0, "Unit": "Count" },
Le résultat suivant montre un trafic GSI reçu sans lecture au cours de la période évaluée :
{ "Timestamp": "2022-08-17T21:20:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-11T21:20:00Z", "Sum": 0.0, "Unit": "Count" },
Nettoyage des GSI ressources inutilisées
Si vous avez identifié un élément inutiliséGSI, vous pouvez choisir de le supprimer. Comme toutes les données présentes dans un GSI sont également présentes dans la table de base, aucune sauvegarde supplémentaire n'est nécessaire avant de supprimer unGSI. Si, à l'avenir, il GSI est à nouveau nécessaire, il pourra être ajouté à nouveau au tableau.
Si vous avez identifié une application peu utiliséeGSI, vous devez envisager de modifier la conception de votre application afin de la supprimer ou de réduire son coût. Par exemple, alors que les analyses DynamoDB doivent être utilisées avec parcimonie car elles peuvent consommer de grandes quantités de ressources système, elles peuvent être plus rentables que si le modèle GSI d'accès qu'elles prennent en charge est très peu utilisé.
De plus, si a GSI est requis pour prendre en charge un modèle d'accès peu fréquent, envisagez de projeter un ensemble d'attributs plus limité. Bien que cela puisse nécessiter des requêtes ultérieures sur la table de base pour prendre en charge vos modèles d'accès peu fréquents, cela peut potentiellement permettre de réduire considérablement les coûts de stockage et d'écriture.
Nettoyage des tables globales inutilisées
Les tables globales Amazon DynamoDB fournissent une solution entièrement gérée pour déployer une base de données multiactive et multirégion sans devoir créer et gérer votre propre solution de réplication.
Les tables globales sont idéales pour fournir un accès à faible latence aux données à proximité des utilisateurs et constituent une région secondaire pour la reprise après sinistre.
Si l'option des tables globales est activée pour une ressource afin de fournir un accès à faible latence aux données, mais que cela ne fait pas partie de votre stratégie de reprise après sinistre, vérifiez que les deux répliques desservent activement le trafic de lecture en évaluant leurs CloudWatch indicateurs. Si un réplica ne sert pas le trafic de lecture, il s'agit peut-être d'une ressource inutilisée.
Si les tables globales font partie de votre stratégie de reprise après sinistre, un réplica ne recevant pas de trafic de lecture peut être attendu dans le cadre d'un schéma actif/en veille.
Nettoyage des sauvegardes ou point-in-time des restaurations non utilisées (PITR)
DynamoDB propose deux styles de sauvegarde. Point-in-timeLa restauration fournit des sauvegardes continues pendant 35 jours pour vous protéger contre les écritures ou les suppressions accidentelles, tandis que la sauvegarde à la demande permet de créer des instantanés qui peuvent être enregistrés à long terme. Les deux types de sauvegardes sont associés à des coûts.
Reportez-vous à la documentation Backup et restauration pour DynamoDB et oint-in-time Sauvegardes P pour DynamoDB afin de déterminer si vos tables disposent de sauvegardes activées qui ne sont peut-être plus nécessaires.