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. # Optimisation des coûts des tables Amazon Keyspaces Cette section décrit les meilleures pratiques pour optimiser les coûts de vos tables Amazon Keyspaces existantes. Vous devez examiner les stratégies suivantes pour déterminer la stratégie d’optimisation des coûts qui répond le mieux à vos besoins et les aborder de manière itérative. Chaque stratégie fournit une vue d'ensemble de ce qui pourrait avoir un impact sur vos coûts, la manière de rechercher des opportunités d'optimisation des coûts et des conseils prescriptifs sur la manière de mettre en œuvre ces meilleures pratiques pour vous aider à économiser. **Topics** + [Évaluer les coûts au niveau de la table](CostOptimization_TableLevelCostAnalysis.md) + [Évaluez le mode capacité de votre table](CostOptimization_TableCapacityMode.md) + [Évaluez les paramètres Application Auto Scaling de votre table](CostOptimization_AutoScalingSettings.md) + [Identifiez vos ressources inutilisées pour optimiser les coûts dans Amazon Keyspaces](CostOptimization_UnusedResources.md) + [Évaluez les modèles d'utilisation de vos tables pour optimiser les performances et les coûts](CostOptimization_TableUsagePatterns.md) + [Évaluer la capacité allouée pour un dimensionnement approprié](CostOptimization_RightSizedProvisioning.md) # Évaluer les coûts au niveau de la table L'outil Cost Explorer qui se trouve dans le AWS Management Console permet de visualiser les coûts ventilés par type, par exemple les frais de lecture, d'écriture, de stockage et de sauvegarde. Vous pouvez également voir ces coûts résumés par période, par mois ou par jour. L'un des problèmes courants de Cost Explorer est que vous ne pouvez pas facilement consulter les coûts d'une seule table en particulier, car Cost Explorer ne vous permet pas de filtrer ou de regrouper les coûts d'une table spécifique. **Vous pouvez consulter la **taille métrique de la table facturable (octets)** de chaque table dans l'onglet Monitor de la console Amazon Keyspaces.** Si vous avez besoin de plus d'informations relatives aux coûts par table, cette section explique comment utiliser le [balisage](tagging-keyspaces.md) pour effectuer une analyse des coûts de table individuelle dans Cost Explorer. **Topics** + [Comment consulter les coûts d'un seul tableau Amazon Keyspaces](#CostOptimization_TableLevelCostAnalysis_ViewInfo) + [Vue par défaut de Cost Explorer](#CostOptimization_TableLevelCostAnalysis_CostExplorer) + [Comment utiliser et appliquer des balises de table dans Cost Explorer](#CostOptimization_TableLevelCostAnalysis_Tagging) ## Comment consulter les coûts d'un seul tableau Amazon Keyspaces Vous pouvez consulter des informations de base sur une table Amazon Keyspaces dans la console, notamment le schéma de clé primaire, la taille de la table facturable et les statistiques relatives à la capacité. Vous pouvez utiliser la taille de la table pour calculer le coût de stockage mensuel de la table. Par exemple, 0,25\$1 par Go dans l'est des États-Unis (Virginie du Nord) Région AWS. Si la table utilise le mode capacité provisionnée, les paramètres actuels de l'unité de capacité de lecture (RCU) et de l'unité de capacité d'écriture (WCU) sont également renvoyés. Vous pouvez utiliser ces informations pour calculer les coûts actuels de lecture et d'écriture de la table. Notez que ces coûts peuvent changer, en particulier si vous avez configuré le tableau avec le dimensionnement automatique d'Amazon Keyspaces. ## Vue par défaut de Cost Explorer La vue par défaut de Cost Explorer fournit des graphiques indiquant le coût des ressources consommées, par exemple le débit et le stockage. Vous pouvez choisir de regrouper ces coûts par période, par exemple les totaux par mois ou par jour. Les coûts de stockage, de lecture, d'écriture et d'autres catégories peuvent également être ventilés et comparés. ![\[Image montrant le coût des ressources consommées dans la vue de Cost Explorer.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/CostOptimization/CostExplorerView.png) ## Comment utiliser et appliquer des balises de table dans Cost Explorer Par défaut, Cost Explorer ne fournit pas de résumé des coûts pour une table spécifique, car il combine les coûts de plusieurs tables pour obtenir un total. Vous pouvez toutefois utiliser le [balisage des ressources AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) pour identifier chaque table à l’aide d’une balise de métadonnées. Les balises sont des paires clé-valeur que vous pouvez utiliser à diverses fins, par exemple pour identifier toutes les ressources appartenant à un projet ou à un département. Pour de plus amples informations, veuillez consulter [Utilisation de balises et d'étiquettes pour les ressources Amazon Keyspaces](tagging-keyspaces.md). Pour cet exemple, nous utilisons une table portant le nom **MyTable**. 1. Définissez une balise avec la clé **table\$1name** et la valeur de. **MyTable** 1. [Activez la balise dans Cost Explorer](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html), puis filtrez sur la valeur de la balise pour obtenir une meilleure visibilité sur les coûts de chaque table. **Note** Cela peut prendre un ou deux jours pour que la balise commence à apparaître dans Cost Explorer Vous pouvez définir vous-même les balises de métadonnées dans la console ou par programmation à l'aide de CQL AWS CLI, du SDK ou du SDK. AWS Envisagez d’exiger la définition d’une balise **table\$1name** dans le cadre du nouveau processus de création de tables de votre organisation. Pour de plus amples informations, veuillez consulter [Créez des rapports de répartition des coûts à l'aide de balises pour Amazon Keyspaces](CostAllocationReports.md). # Évaluez le mode capacité de votre table Cette section explique comment sélectionner le mode de capacité approprié pour votre table Amazon Keyspaces. Chaque mode est réglé de façon à répondre aux besoins d’une charge de travail différente en termes de réactivité face à l’évolution du débit, ainsi que de facturation de cette utilisation. Vous devez tenir compte de ces facteurs lorsque vous prenez votre décision. **Topics** + [Quels sont les modes de capacité de table disponibles ?](#CostOptimization_TableCapacityMode_Overview) + [Quand sélectionner le mode de capacité à la demande ?](#CostOptimization_TableCapacityMode_OnDemand) + [Quand sélectionner le mode de capacité provisionnée ?](#CostOptimization_TableCapacityMode_Provisioned) + [Autres facteurs à prendre en compte lors du choix d’un mode de capacité de table](#CostOptimization_TableCapacityMode_AdditionalFactors) ## Quels sont les modes de capacité de table disponibles ? Lorsque vous créez une table Amazon Keyspaces, vous devez sélectionner le mode de capacité à la demande ou le mode de capacité provisionnée. Pour de plus amples informations, veuillez consulter [Configurer les modes de read/write capacité dans Amazon Keyspaces](ReadWriteCapacityMode.md). **Mode de capacité à la demande** Le mode de capacité à la demande est conçu pour éliminer le besoin de planifier ou de provisionner la capacité de votre table Amazon Keyspaces. Dans ce mode, votre table répond instantanément aux demandes sans qu'il soit nécessaire d'augmenter ou de diminuer les ressources (jusqu'à deux fois le débit maximal précédent de la table). Les tables à la demande sont facturées en comptant le nombre de demandes réelles par rapport à la table, de sorte que vous ne payez que pour ce que vous utilisez plutôt que pour ce qui a été provisionné. **Mode de capacité provisionnée** Le mode de capacité provisionnée est un modèle plus traditionnel dans lequel vous pouvez définir la capacité dont la table dispose pour les demandes, soit directement, soit à l'aide d'Application Auto Scaling. Dans la mesure où une capacité spécifique est mise en service pour la table à tout moment, la facturation est basée sur la capacité fournie plutôt que sur le nombre de demandes. Le dépassement de la capacité allouée peut également entraîner le rejet des demandes par la table et réduire l'expérience des utilisateurs de votre application. Le mode de capacité provisionnée nécessite un équilibre entre le fait de ne pas surprovisionner ou sous-provisionner la table pour atteindre les deux objectifs, la faible occurrence d'erreurs de capacité de débit insuffisante et l'optimisation des coûts. ## Quand sélectionner le mode de capacité à la demande ? Lorsque vous optimisez en fonction des coûts, le mode à la demande est votre meilleur choix lorsque vous avez une charge de travail imprévisible similaire à celle illustrée dans le graphique suivant. Les facteurs suivants contribuent à ce type de charge de travail : + Caractère imprévisible des demandes (entraînant des pics de trafic) + Volume variable des demandes (en raison des charges de travail par lots) + Baisse à zéro ou en dessous de 18 % du pic pendant une heure donnée (en raison des environnements de développement ou de test) ![\[Image montrant une charge de travail élevée avec des pics de trafic aléatoires.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png) Pour les charges de travail présentant les caractéristiques ci-dessus, l'utilisation d'Application Auto Scaling pour maintenir une capacité suffisante pour que la table puisse répondre aux pics de trafic peut entraîner des résultats indésirables. Il se peut que la table soit surprovisionnée et coûte plus cher que nécessaire, soit qu'elle soit sous-approvisionnée et que les demandes entraînent des erreurs de débit inutiles liées à une faible capacité. Dans de tels cas, les tables à la demande sont le meilleur choix. Les tables à la demande étant facturées sur demande, vous n'avez rien d'autre à faire au niveau des tables pour optimiser les coûts. Vous devez régulièrement évaluer vos tables à la demande pour vérifier que la charge de travail présente toujours les caractéristiques ci-dessus. Si la charge de travail s'est stabilisée, envisagez de passer en mode provisionné afin de maintenir l'optimisation des coûts. ## Quand sélectionner le mode de capacité provisionnée ? Une charge de travail idéale pour le mode de capacité allouée est une charge de travail dont le modèle d'utilisation est plus prévisible, comme le montre le graphique ci-dessous. Les facteurs suivants contribuent à une charge de travail prévisible : + Trafic prévisible/cyclique pour une heure ou une journée donnée + Rafales de trafic limitées à court terme ![\[Image montrant une charge de travail relativement prévisible avec des pics de trafic limités.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png) Étant donné que les volumes de trafic sont plus stables à une heure ou à une journée donnée, vous pouvez définir la capacité allouée de manière relativement proche de la capacité réellement consommée de la table. L'optimisation des coûts d'un tableau des capacités provisionnées consiste en fin de compte à faire en sorte que la capacité provisionnée (ligne bleue) soit aussi proche que possible de la capacité consommée (ligne orange) sans augmenter le nombre d'`ThrottledRequests`événements associés au tableau. L'espace entre les deux lignes représente à la fois une perte de capacité et une assurance contre une mauvaise expérience utilisateur due à des erreurs de capacité de débit insuffisante. Amazon Keyspaces fournit Application Auto Scaling pour les tables de capacité provisionnées, qui équilibre automatiquement ces données en votre nom. Vous pouvez suivre votre capacité consommée tout au long de la journée et configurer la capacité provisionnée de la table en fonction de quelques variables. **Unités de capacité minimale** Vous pouvez définir la capacité minimale d'une table pour limiter les erreurs de capacité de débit insuffisante, mais cela ne réduit pas le coût de la table. Si votre table connaît des périodes de faible utilisation suivies d'une augmentation soudaine d'utilisation, le fait de définir la valeur minimale peut empêcher Application Auto Scaling de définir une capacité trop faible de la table. **Unité de capacité maximale** Vous pouvez définir la capacité maximale d’une table afin de limiter la mise à l’échelle d’une table en utilisant une valeur supérieure à celle prévue. Envisagez d'appliquer un maximum pour les tables de développement ou de test, où les tests de charge à grande échelle ne sont pas souhaités. Vous pouvez définir un maximum pour n'importe quelle table, mais veillez à évaluer régulièrement ce paramètre par rapport à la base de référence du tableau lorsque vous l'utilisez en production, afin d'éviter les erreurs accidentelles liées à une capacité de débit insuffisante. **Utilisation cible** La définition de l’utilisation cible de la table est le principal moyen d’optimiser les coûts pour une table à capacité provisionnée. La définition d'une valeur en pourcentage inférieure augmente le surprovisionnement de la table, ce qui augmente les coûts, mais réduit le risque d'erreurs liées à une capacité de débit insuffisante. La définition d'une valeur de pourcentage plus élevée réduit le surprovisionnement de la table, mais augmente le risque d'erreurs liées à une capacité de débit insuffisante. ## Autres facteurs à prendre en compte lors du choix d’un mode de capacité de table Au moment de choisir entre les deux modes de capacité, certains facteurs supplémentaires méritent d'être pris en compte. Lorsque vous choisissez entre les deux modes de table, considérez dans quelle mesure cette réduction supplémentaire affecte le coût de la table. Dans de nombreux cas, même une charge de travail relativement imprévisible peut s'avérer plus rentable à exécuter sur une table de capacité provisionnée surdimensionnée avec des capacités réservées. **Améliorer la prévisibilité de votre charge de travail** Dans certaines situations, une charge de travail peut apparemment présenter à la fois un schéma prévisible et un schéma imprévisible. Bien que cela puisse être facilement pris en charge par un tableau à la demande, les coûts seront probablement inférieurs si les modèles imprévisibles de la charge de travail peuvent être améliorés. Les importations par lots sont l'une des causes les plus fréquentes de ces tendances. Ce type de trafic peut souvent dépasser la capacité de base de la table à un point tel que des erreurs de capacité de débit insuffisante se produiraient en cas d'exécution. Pour qu’une charge de travail comme celle-ci soit exécutée sur une table à capacité provisionnée, considérez les options suivantes : + Si le lot se produit à des heures planifiées, vous pouvez planifier une augmentation de la capacité d'autodimensionnement de votre application avant son exécution. + Si le lot se produit de manière aléatoire, pensez à essayer de prolonger le temps d'exécution plutôt que de l'exécuter le plus rapidement possible. + Ajoutez une période d'accélération à l'importation, au cours de laquelle la vitesse de l'importation commence lentement mais augmente lentement en quelques minutes jusqu'à ce qu'Application Auto Scaling ait eu l'opportunité de commencer à ajuster la capacité de la table. # Évaluez les paramètres Application Auto Scaling de votre table Cette section explique comment évaluer les paramètres Application Auto Scaling de vos tables Amazon Keyspaces. [Amazon Keyspaces Application Auto Scaling](autoscaling.md) est une fonctionnalité qui gère le débit des tables en fonction du trafic de votre application et de votre indicateur d'utilisation cible. Cela garantit que vos tables disposent de la capacité requise pour vos modèles d'application. Le service Application Auto Scaling surveille l'utilisation actuelle de votre table et la compare à la valeur d'utilisation cible :`TargetValue`. Il vous indique s'il est temps d'augmenter ou de diminuer la capacité allouée. **Topics** + [Comprendre les paramètres de votre Application Auto Scaling](#CostOptimization_AutoScalingSettings_UnderProvisionedTables) + [Comment identifier les tables présentant une faible cible d’utilisation (<= 50 %)](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization) + [Comment gérer les charges de travail liées aux variations saisonnières](#CostOptimization_AutoScalingSettings_SeasonalVariance) + [Comment gérer les pics de charge de travail imprévisibles](#CostOptimization_AutoScalingSettings_UnknownPatterns) + [Comment gérer les charges de travail avec des applications liées](#CostOptimization_AutoScalingSettings_BetweenRanges) ## Comprendre les paramètres de votre Application Auto Scaling Pour définir la valeur correcte correspondant à l’utilisation cible, ainsi que l’étape initiale et les valeurs finales, vous devez faire appel à l’équipe des opérations. Cela vous permet de définir correctement les valeurs en fonction de l'utilisation historique de l'application, qui est utilisée pour déclencher les politiques Application Auto Scaling. L'objectif d'utilisation est le pourcentage de votre capacité totale qui doit être atteint pendant un certain temps avant que les règles d'Application Auto Scaling ne s'appliquent. Lorsque vous définissez un **objectif d'utilisation élevé (un objectif d'environ 90 %)**, cela signifie que votre trafic doit être supérieur à 90 % pendant un certain temps avant que l'Application Auto Scaling ne soit activée. Il est préférable de ne pas utiliser une cible d’utilisation élevée, sauf si votre application est très constante et ne fait l’objet d’aucun pic de trafic. Lorsque vous définissez un taux d'**utilisation très faible (un objectif inférieur à 50 %)**, cela signifie que votre application doit atteindre 50 % de la capacité allouée avant de déclencher une politique Application Auto Scaling. À moins que le trafic de vos applications n’augmente à un rythme très soutenu, cela se traduit généralement par une capacité inutilisée et un gaspillage de ressources. ## Comment identifier les tables présentant une faible cible d’utilisation (<= 50 %) Vous pouvez utiliser le AWS CLI ou AWS Management Console pour surveiller et identifier les `TargetValues` politiques de votre Application Auto Scaling dans vos ressources Amazon Keyspaces. **Note** Lorsque vous utilisez des tables multirégionales en mode capacité allouée avec le dimensionnement automatique d'Amazon Keyspaces, veillez à utiliser les opérations de l'API Amazon Keyspaces pour configurer le dimensionnement automatique. Les opérations d'API Application Auto Scaling sous-jacentes qu'Amazon Keyspaces appelle en votre nom ne disposent pas de fonctionnalités multirégionales. Pour de plus amples informations, veuillez consulter [Afficher les paramètres de capacité allouée et de dimensionnement automatique pour une table multirégionale dans Amazon Keyspaces](tables-mrr-view.md). ------ #### [ AWS CLI ] 1. Pour afficher la liste complète des ressources, exécutez la commande suivante : ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra ``` Cette commande renverra la liste complète des politiques Application Auto Scaling émises pour n'importe quelle ressource Amazon Keyspaces. Pour récupérer uniquement les ressources d’une table particulière, vous pouvez ajouter le `–resource-id parameter`. Par exemple : ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` 1. Renvoie uniquement les politiques de dimensionnement automatique pour une table particulière en exécutant la commande suivante ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` Les valeurs des politiques Application Auto Scaling sont mises en évidence ci-dessous. Vous devez vous assurer que la valeur cible est supérieure à 50 % pour éviter le surprovisionnement. Le résultat doit ressembler à ce qui suit : ``` { "ScalingPolicies": [ { "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy", "PolicyName": $”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesWriteCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:48.641000+10:00" }, { "PolicyARN": "arn:aws:autoscaling:us-east-1:111122223333:scalingPolicy::resource/keyspaces/table/table-name-scaling-policy", "PolicyName":$”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:ReadCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesReadCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:47.820000+10:00" } ] } ``` ------ #### [ AWS Management Console ] 1. Connectez-vous au AWS Management Console et accédez à la page de CloudWatch service sur [Getting Started with the AWS Management Console](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). Sélectionnez la solution appropriée Région AWS si nécessaire. 1. Dans le volet de navigation, sélectionnez **Tables**. Sur la page **Tables**, sélectionnez le **nom** de la table. 1. Sur la page **Détails de la table** de l'onglet **Capacity**, passez en revue les paramètres Application Auto Scaling de votre table. ------ Si vos valeurs d’utilisation cibles sont inférieures ou égales à 50 %, explorez les métriques d’utilisation de vos tables pour déterminer si elles sont [sous-provisionnées ou surprovisionnées](CostOptimization_RightSizedProvisioning.md). ## Comment gérer les charges de travail liées aux variations saisonnières Envisagez le scénario suivant : votre application fonctionne en dessous d’une valeur moyenne minimale la plupart du temps, mais la cible d’utilisation est faible. Votre application peut donc réagir rapidement aux événements qui se produisent à certaines heures de la journée et vous disposez d’une capacité suffisante pour éviter les ralentissements. Ce scénario est courant avec les applications qui sont très actives pendant les heures normales de bureau (de 9 h à 17 h), mais qui fonctionnent ensuite à un niveau de base en dehors de cette plage horaire. Comme certains utilisateurs commencent à se connecter avant 9 heures du matin, l'application utilise ce seuil bas pour augmenter rapidement afin d'atteindre la capacité *requise* aux heures de pointe. Ce scénario peut se présenter comme suit : + Entre 17 h et 9 h, les unités `ConsumedWriteCapacityUnits` restent entre 90 et 100. + Les utilisateurs commencent à se connecter à l’application avant 9 heures du matin et les unités de capacité augmentent considérablement (la valeur maximale que vous avez vue est de 1 500 WCU). + En moyenne, l’utilisation de vos applications varie entre 800 et 1 200 pendant les heures de travail. Si le scénario précédent s'applique à votre application, envisagez d'utiliser le [dimensionnement automatique des applications planifié](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html), dans lequel une règle Application Auto Scaling peut toujours être configurée sur votre table, mais avec une utilisation cible moins agressive qui ne fournit la capacité supplémentaire qu'aux intervalles spécifiques dont vous avez besoin. Vous pouvez utiliser le AWS CLI pour exécuter les étapes suivantes afin de créer une règle de dimensionnement automatique planifiée qui s'exécute en fonction de l'heure du jour et du jour de la semaine. 1. Enregistrez votre table Amazon Keyspaces en tant que cible évolutive avec. Application Auto Scaling Une cible pouvant être mise à l’échelle avec est une ressource dont Application Auto Scaling peut augmenter ou réduire la capacité. ``` aws application-autoscaling register-scalable-target \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --min-capacity 90 \ --max-capacity 1500 ``` 1. Configurez les actions planifiées en fonction de vos besoins. Vous avez besoin de deux règles pour couvrir le scénario : l'une pour augmenter la taille et l'autre pour la réduire. La première règle permettant d'étendre l'action planifiée est illustrée dans l'exemple suivant. ``` aws application-autoscaling put-scheduled-action \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --scheduled-action-name my-8-5-scheduled-action \ --scalable-target-action MinCapacity=800,MaxCapacity=1500 \ --schedule "cron(45 8 ? * MON-FRI *)" \ --timezone "Australia/Brisbane" ``` La deuxième règle permettant de réduire l'action planifiée est illustrée dans cet exemple. ``` aws application-autoscaling put-scheduled-action \ --service-namespace cassandra \ --scalable-dimension cassandra:table:WriteCapacityUnits \ --resource-id keyspace/keyspace-name/table/table-name \ --scheduled-action-name my-5-8-scheduled-down-action \ --scalable-target-action MinCapacity=90,MaxCapacity=1500 \ --schedule "cron(15 17 ? * MON-FRI *)" \ --timezone "Australia/Brisbane" ``` 1. Exécutez la commande suivante pour confirmer que les deux règles ont été activées : ``` aws application-autoscaling describe-scheduled-actions --service-namespace cassandra ``` Vous devriez obtenir le résultat suivant : ``` { "ScheduledActions": [ { "ScheduledActionName": "my-5-8-scheduled-down-action", "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-5-8-scheduled-down-action", "ServiceNamespace": "cassandra", "Schedule": "cron(15 17 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 90, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:30:25.100000+10:00" }, { "ScheduledActionName": "my-8-5-scheduled-action", "ScheduledActionARN": "arn:aws:autoscaling:us-east-1:111122223333:scheduledAction::resource/keyspaces/table/table-name:scheduledActionName/my-8-5-scheduled-action", "ServiceNamespace": "cassandra", "Schedule": "cron(45 8 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:table:WriteCapacityUnits", "ScalableTargetAction": { "MinCapacity": 800, "MaxCapacity": 1500 }, "CreationTime": "2022-03-15T17:28:57.816000+10:00" } ] } ``` L’image suivante montre un exemple de charge de travail qui maintient en permanence une cible d’utilisation de 70 %. Remarquez que les règles de dimensionnement automatique s'appliquent toujours et que le débit ne diminue pas. ![\[Un graphique qui montre l'utilisation de l'écriture en unités par seconde en comparant la capacité allouée à la capacité consommée sur une période d'une journée.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings3.png) En zoomant, nous pouvons constater qu'un pic dans l'application a déclenché le seuil de 70 %, forçant ainsi la mise à l'échelle automatique à démarrer et à fournir la capacité supplémentaire requise pour la table. L'action de mise à l'échelle automatique planifiée affectera les valeurs maximales et minimales, et il est de votre responsabilité de les configurer. ![\[Vue plus détaillée du graphique qui montre l'utilisation de l'écriture en unités par seconde, en comparant la capacité allouée à la capacité consommée, en zoomant sur un moment précis.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings4.png) ![\[Affichage de la vue détaillée du graphique qui montre l'utilisation de l'écriture en unités par seconde en comparant la capacité allouée à la capacité consommée sur une période d'une journée.\]](http://docs.aws.amazon.com/fr_fr/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings5.png) ## Comment gérer les pics de charge de travail imprévisibles Dans ce scénario, l'application utilise un objectif d'utilisation très faible, car vous ne connaissez pas encore les modèles d'application et vous voulez vous assurer que votre charge de travail ne rencontre pas d'erreurs de débit liées à une faible capacité. Vous pouvez ici envisager d’utiliser le [mode de capacité à la demande](ReadWriteCapacityMode.OnDemand.md). Les tables à la demande sont idéales pour les charges de travail exigeantes pour lesquelles vous ne connaissez pas les tendances de trafic. Avec le mode de capacité à la demande, vous payez à la demande les lectures et écritures de données que votre application effectue sur vos tables. Vous n'avez pas besoin de spécifier le débit de lecture et d'écriture que vous souhaitez que votre application atteigne, car Amazon Keyspaces s'adapte instantanément à vos charges de travail à mesure qu'elles augmentent ou diminuent. ## Comment gérer les charges de travail avec des applications liées Dans ce scénario, l’application dépend d’autres systèmes, tels que les scénarios de traitement par lots dans lesquels vous pouvez avoir de forts pics de trafic en fonction des événements dans la logique de l’application. Envisagez de développer une logique d'auto-scaling des applications personnalisée qui réagit aux événements susceptibles d'augmenter la capacité des tables et `TargetValues` en fonction de vos besoins spécifiques. Vous pourriez bénéficier Amazon EventBridge et utiliser une combinaison de AWS services tels que λ et Step Functions pour répondre aux besoins spécifiques de votre application. # Identifiez vos ressources inutilisées pour optimiser les coûts dans Amazon Keyspaces Cette section explique comment évaluer régulièrement vos ressources inutilisées. Au fur et à mesure que les exigences de votre application évoluent, vous devez vous assurer qu'aucune ressource n'est inutilisée et qu'elle ne contribue à des coûts inutiles liés à Amazon Keyspaces. Les procédures décrites ci-dessous utilisent CloudWatch les métriques Amazon pour identifier les ressources inutilisées et prendre des mesures pour réduire les coûts. Vous pouvez surveiller Amazon Keyspaces à l'aide d'Amazon Keyspaces CloudWatch, qui collecte et traite les données brutes d'Amazon Keyspaces pour en faire des indicateurs lisibles en temps quasi 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 d'Amazon Keyspaces sont envoyées automatiquement à CloudWatch . Pour plus d'informations, consultez [Qu'est-ce qu'Amazon CloudWatch ?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) et [conservation des métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#metrics-retention) dans le *guide de CloudWatch l'utilisateur Amazon*. **Topics** + [Comment identifier les ressources inutilisées](#CostOptimization_UnusedResources_Identifying) + [Identification des ressources de table inutilisées](#CostOptimization_UnusedResources_Tables) + [Nettoyage des ressources de table inutilisées](#CostOptimization_UnusedResources_Tables_Cleanup) + [Nettoyage des sauvegardes de point-in-time restauration non utilisées (PITR)](#CostOptimization_UnusedResources_Backups) ## Comment identifier les ressources inutilisées Pour identifier les tables inutilisées, vous pouvez examiner 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 une table spécifique : **`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 récupérer la capacité de lecture totale consommée pour une table. **`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 récupérer la capacité d'écriture totale consommée pour une table. ## Identification des ressources de table inutilisées Amazon CloudWatch est un service de surveillance et d'observabilité qui fournit les statistiques du tableau Amazon Keyspaces que vous pouvez utiliser 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. ------ #### [ AWS Command Line Interface ] Pour afficher les statistiques de vos tables via le AWS Command Line Interface, vous pouvez utiliser les commandes suivantes. 1. Tout d’abord, évaluez les lectures de votre table : **Note** Si le nom de la table n'est pas unique au sein de votre compte, vous devez également spécifier le nom de l'espace-clé. ``` aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` Pour éviter de faussement identifier une table comme étant inutilisée, évaluez les indicateurs sur une période plus longue. **Choisissez une plage d'heures de début et de fin appropriées, 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 une table recevant du trafic de lecture au cours de la période évaluée : ``` { "Timestamp": "2022-08-25T19:40:00Z", "Sum": 36023355.0, "Unit": "Count" }, { "Timestamp": "2022-08-12T19:40:00Z", "Sum": 38025777.5, "Unit": "Count" }, ``` Le résultat suivant montre qu’une table n’a pas reçu de trafic de lecture au cours de la période évaluée : ``` { "Timestamp": "2022-08-01T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-20T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, ``` 1. Ensuite, évaluez les écritures dans votre table : ``` aws cloudwatch get-metric-statistics --metric-name ConsumedWriteCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` 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 une table recevant du trafic d’écriture au cours de la période évaluée : ``` { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 41014457.0, "Unit": "Count" }, { "Timestamp": "2022-08-18T20:15:00Z", "Sum": 40048531.0, "Unit": "Count" }, ``` Le résultat suivant montre qu’une table n’a pas reçu de trafic d’écriture au cours de la période évaluée : ``` { "Timestamp": "2022-07-31T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, ``` ------ #### [ AWS Management Console ] Les étapes suivantes vous permettent d'évaluer l'utilisation de vos ressources à l'aide du AWS Management Console. 1. Connectez-vous au AWS Management Console et accédez à la page de CloudWatch service à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). Sélectionnez l'option appropriée Région AWS en haut à droite de la console, si nécessaire. 1. Dans la barre de navigation de gauche, recherchez la section **Mesures** et choisissez **Toutes les mesures**. 1. L'action ci-dessus ouvre un tableau de bord avec deux panneaux. Dans le panneau supérieur, vous pouvez voir les statistiques actuellement représentées graphiquement. En bas, vous pouvez sélectionner les indicateurs disponibles pour le graphe. Choisissez Amazon Keyspaces dans le panneau inférieur. 1. Dans le panneau de sélection des statistiques d'Amazon Keyspaces, choisissez la catégorie **Tableau Metrics** pour afficher les statistiques relatives à vos tables dans la région actuelle. 1. Identifiez le nom de votre table en faisant défiler le menu vers le bas, puis choisissez les métriques `ConsumedReadCapacityUnits` et `ConsumedWriteCapacityUnits` pour votre tableau. 1. **Choisissez l'onglet **Mesures graphiques (2)** et réglez la colonne **Statistiques** sur Somme.** 1. Pour éviter d'identifier à tort une table comme étant inutilisée, évaluez les métriques de la table sur une période plus longue. En haut du panneau graphique, choisissez une période appropriée, par exemple un mois, pour évaluer votre tableau. Choisissez **Personnalisé**, choisissez **1 mois** dans le menu déroulant, puis choisissez **Appliquer**. 1. Évaluez les métriques représentées graphiquement pour votre table afin de déterminer si elle est utilisée. Les métriques supérieures à **0** indiquent qu’une table a été utilisée pendant la période évaluée. Un graphique plat à **0** en lecture et en écriture indique qu'une table n'est pas utilisée. ------ ## 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. Dans le cas contraire, vous pouvez envisager de supprimer le tableau. **Modes de capacité** Amazon Keyspaces facture la lecture, l'écriture et le stockage de données dans vos tables Amazon Keyspaces. Amazon Keyspaces propose [deux modes de capacité](ReadWriteCapacityMode.md), dotés d'options de facturation spécifiques pour le traitement des lectures et des écritures sur vos tables : à la demande et provisionné. Le mode read/write capacité contrôle la façon dont vous êtes facturé pour le débit de lecture et d'écriture et la façon dont vous gérez 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. Amazon Keyspaces vous facture les opérations de lecture et d'écriture effectuées par votre application sur vos tables 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, vous ne payez pas pour le débit, mais vous devez tout de même payer des frais de stockage. **Suppression des tables** Si vous avez découvert une table inutilisée et que vous souhaitez la supprimer, pensez d'abord à effectuer une sauvegarde ou à exporter les données. Les sauvegardes effectuées 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 documentation sur la [gestion des plans de sauvegarde](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans) pour savoir comment utiliser un cycle de vie pour transférer votre sauvegarde vers un stockage à froid. Une fois votre table sauvegardée, vous pouvez choisir de la supprimer via la AWS Management Console ou via l’ AWS Command Line Interface. ## Nettoyage des sauvegardes de point-in-time restauration non utilisées (PITR) Amazon Keyspaces propose la Point-in-time restauration, qui fournit des sauvegardes continues pendant 35 jours afin de vous protéger contre les écritures ou les suppressions accidentelles. Les sauvegardes PITR sont associées à des coûts. Reportez-vous à la documentation [Backup et restauration des données avec point-in-time restauration pour Amazon Keyspaces](PointInTimeRecovery.md) à l'adresse suivante pour déterminer si des sauvegardes sont activées sur vos tables et qu'elles ne sont peut-être plus nécessaires. # Évaluez les modèles d'utilisation de vos tables pour optimiser les performances et les coûts Cette section explique comment évaluer si vous utilisez efficacement vos tables Amazon Keyspaces. Certains modèles d'utilisation ne sont pas optimaux pour Amazon Keyspaces, et ils peuvent être optimisés tant du point de vue des performances que du point de vue des coûts. **Topics** + [Effectuer moins d’opérations de lecture fortement cohérente](#CostOptimization_TableUsagePatterns_StronglyConsistentReads) + [Activer la durée de vie (TTL)](#CostOptimization_TableUsagePatterns_TTL) ## Effectuer moins d’opérations de lecture fortement cohérente Amazon Keyspaces vous permet de configurer la [cohérence de lecture](consistency.md#ReadConsistency) pour chaque demande. Les demandes de lecture sont « éventuellement cohérentes » par défaut. Finalement, les lectures cohérentes sont facturées à 0,5 RCU pour un maximum de 4 Ko de données. La plupart des éléments des charges de travail distribuées sont flexibles et peuvent tolérer une éventuelle cohérence. Cependant, certains modèles d’accès peuvent nécessiter des lectures fortement cohérentes. Les lectures très cohérentes sont facturées à 1 RCU pour un maximum de 4 Ko de données, ce qui double essentiellement vos coûts de lecture. Amazon Keyspaces vous offre la possibilité d'utiliser les deux modèles de cohérence sur la même table. Vous pouvez évaluer votre charge de travail et le code de votre application pour vérifier si les lectures fortement cohérentes ne sont utilisées que lorsque cela est nécessaire. ## Activer la durée de vie (TTL) [Time to Live (TTL)](TTL.md) vous aide à simplifier la logique de votre application et à optimiser le prix du stockage en expirant automatiquement les données des tables. Les données dont vous n'avez plus besoin sont automatiquement supprimées de votre tableau en fonction de la valeur Time to Live que vous avez définie. # Évaluer la capacité allouée pour un dimensionnement approprié Cette section explique comment évaluer si vous disposez d'un provisionnement de taille appropriée sur vos tables Amazon Keyspaces. À mesure que votre charge de travail évolue, vous devez modifier vos procédures opérationnelles de manière appropriée, en particulier lorsque votre table Amazon Keyspaces est configurée en mode provisionné et que vous courez le risque de surprovisionner ou de sous-approvisionner vos tables. Les procédures décrites dans cette section nécessitent des informations statistiques qui doivent être capturées à partir des tables Amazon Keyspaces qui prennent en charge votre application de production. Pour comprendre le comportement de votre application, vous devez définir une période suffisamment importante pour saisir le caractère saisonnier des données de votre application. 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é, pour les tables Amazon Keyspaces, vous pouvez configurer les unités de **capacité de lecture (RCUs) et les unités** de **capacité d'écriture (WCU**) indépendamment. **Topics** + [Comment récupérer les statistiques de consommation à partir de vos tableaux Amazon Keyspaces](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics) + [Comment identifier les tables Amazon Keyspaces sous-approvisionnées](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables) + [Comment identifier les tables Amazon Keyspaces surapprovisionnées](#CostOptimization_RightSizedProvisioning_OverProvisionedTables) ## Comment récupérer les statistiques de consommation à partir de vos tableaux Amazon Keyspaces Pour évaluer la capacité de la table, surveillez les CloudWatch mesures suivantes et sélectionnez la dimension appropriée pour récupérer les informations de la table : | 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 métriques de consommation du tableau, vous devez 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 de la table. Vous devez mettre à jour certains champs, comme indiqué dans le tableau ci-dessous, pour les adapter à votre environnement. **Note** Si le nom de la table n'est pas unique au sein de votre compte, vous devez également spécifier le nom de l'espace-clé. | Nom de champ | Définition | Exemple | | --- | --- | --- | | | Le nom de la table que vous analysez | SampleTable | | | Période que vous utilisez pour évaluer l'objectif 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 extrait le nombre de WCU provisionnés et consommés au cours de la période correspondant à la plage de dates spécifiée. Il génère également un pourcentage d'utilisation qui peut être utilisé pour l'analyse. Le contenu complet du `write-calc.json` fichier doit ressembler à celui de l'exemple suivant. ``` { "MetricDataQueries": [ { "Id": "provisionedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedWriteCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedWCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "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 une métrique similaire. Ce fichier extrait combien RCUs ont été provisionnés et consommés pendant la période correspondant à la plage de dates spécifiée. Le contenu du `read-calc.json` fichier doit ressembler à celui de cet exemple. ``` { "MetricDataQueries": [ { "Id": "provisionedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "MetricName": "ProvisionedReadCapacityUnits", "Dimensions": [ { "Name": "TableName", "Value": "" } ] }, "Period": , "Stat": "Average" }, "Label": "Provisioned", "ReturnData": false }, { "Id": "consumedRCU", "MetricStat": { "Metric": { "Namespace": "AWS/Cassandra", "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 de l'écriture, exécutez 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 en lecture, exécutez la commande suivante : ``` aws cloudwatch get-metric-data --cli-input-json file://read-calc.json ``` Le résultat des deux requêtes est une série de points de données au format JSON qui peuvent être utilisés pour l'analyse. Vos résultats dépendent du nombre de points de données que vous avez spécifiés, de la période et de vos propres données de charge de travail. Cela pourrait ressembler à l'exemple suivant. ``` { "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 courte période et une longue période, vous devrez peut-être modifier la `MaxDatapoints` valeur, qui est définie par défaut sur 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 au AWS Management Console et accédez à la page de CloudWatch service sur [Getting Started with the AWS Management Console](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). Sélectionnez la solution appropriée Région AWS si nécessaire. 1. Localisez la section Mesures dans la barre de navigation de gauche et choisissez **Toutes les mesures**. 1. Cela ouvre un tableau de bord avec deux panneaux. Le panneau supérieur affiche le graphique, tandis que le panneau inférieur contient les indicateurs que vous souhaitez représenter graphiquement. Choisissez le panneau Amazon Keyspaces. 1. Choisissez la catégorie **Table Metrics** dans les sous-panneaux. Cela vous montre les tables de votre compte actuel Région AWS. 1. Identifiez le nom de votre table en faisant défiler le menu vers le bas, puis sélectionnez les métriques des opérations 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 **Graphed metrics (2)** (Indicateurs graphiques (2)) pour modifier les formules. Par défaut, CloudWatch choisit la fonction statistique **Average** pour les graphiques. 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 **Pourcentage**. Deuxième sélection de la fonction **Pourcentage**. 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, vous devez faire correspondre les noms à ceux que vous avez utilisés dans la AWS CLI section. Cliquez sur l'**ID m1** et remplacez cette valeur par **consumedWCU**. 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, vous pouvez l'ignorer en décochant la case sur la métrique **ad1** nouvellement générée. 1. Répétez l’étape 8 pour remplacer le nom de l’**ID m2** par **provisionedWCU**. Conservez la statistique **Average** (Moyenne). 1. **Choisissez 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, vous pouvez l'ignorer. 1. Vous devriez maintenant avoir deux graphiques : l'un qui indique ce que vous avez provisionné WCUs sur le tableau et l'autre qui indique ce que vous avez consommé WCUs. 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)**. 1. Supprimez la case à cocher de toutes les métriques, à l'exception de **UtilizationPercentage, pour visualiser vos modèles** d'utilisation. L'intervalle par défaut est fixé à 1 minute, mais n'hésitez pas à le modifier selon vos besoins. Les résultats que vous obtenez dépendent des données réelles de votre charge de travail. Les intervalles d'utilisation supérieurs à 100 % sont sujets à des événements d'erreur liés à une faible capacité de débit. Amazon Keyspaces propose une [capacité en rafale](throughput-bursting.md), mais dès qu'elle est épuisée, toute valeur supérieure à 100 % est confrontée à des événements d'erreur liés à une faible capacité de débit. ------ ## Comment identifier les tables Amazon Keyspaces sous-approvisionné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](throughput-bursting.md) est une fonctionnalité d'Amazon Keyspaces 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. Cette capacité de rafale est limitée. Pour plus d'informations, voir[Utilisez efficacement la capacité de pointe dans Amazon Keyspaces](throughput-bursting.md). Dès que les capacités inutilisées RCUs et WCUs épuisées, vous pouvez rencontrer des erreurs de débit en cas de faible capacité si vous essayez de consommer plus de capacité que celle allouée. Lorsque le trafic de votre application atteint un taux d'utilisation proche de 80 %, le risque de rencontrer des erreurs liées au débit de faible capacité 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 spéciaux dans lesquels les données sont faussées lorsque vous les analysez 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 tombent ensuite à presque zéro en dehors des heures de travail), vous pourriez tirer parti de la [planification de l'auto-scaling des applications](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html), dans laquelle vous spécifiez les heures de la journée (et les jours de la semaine) pour augmenter la capacité allouée, ainsi que le moment de la réduire. Au lieu de viser une capacité accrue afin de couvrir les heures de pointe, vous pouvez également bénéficier des configurations d'[auto-scaling des tables Amazon Keyspaces](autoscaling.md) si votre saisonnalité est moins prononcée. ## Comment identifier les tables Amazon Keyspaces surapprovisionné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 votre table contient plusieurs intervalles d'utilisation réduits, vous pouvez tirer parti des politiques Application Auto Scaling, soit en planifiant Application Auto Scaling, soit en configurant simplement les politiques Application Auto Scaling par défaut pour la table, en fonction de l'utilisation. Si votre charge de travail présente un faible rapport utilisation/accélération élevé (**Max () /Min (ThrottleEvents) dans l'intervalleThrottleEvents)**, cela peut se produire lorsque votre charge de travail est très élevée et que le trafic augmente de manière significative certains jours (ou à certaines heures de la journée), mais qu'il est par ailleurs constamment faible. Dans ces scénarios, il peut être avantageux d'utiliser [Application Auto Scaling programmé](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html).