Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Ottimizzazione dei costi delle tabelle Amazon Keyspaces Questa sezione illustra le best practice su come ottimizzare i costi per le tabelle Amazon Keyspaces esistenti. Esaminare le seguenti strategie per vedere quale strategia di ottimizzazione dei costi si adatta meglio alle proprie esigenze e affrontarle in modo iterativo. Ogni strategia fornisce una panoramica di ciò che potrebbe influire sui costi, su come cercare opportunità per ottimizzare i costi e linee guida prescrittive su come implementare queste best practice per aiutarti a risparmiare. **Topics** + [Valutazione dei costi a livello di tabella](CostOptimization_TableLevelCostAnalysis.md) + [Valuta la modalità di capacità della tua tabella](CostOptimization_TableCapacityMode.md) + [Valuta le impostazioni di Application Auto Scaling della tua tabella](CostOptimization_AutoScalingSettings.md) + [Identifica le risorse inutilizzate per ottimizzare i costi in Amazon Keyspaces](CostOptimization_UnusedResources.md) + [Valuta i modelli di utilizzo delle tabelle per ottimizzare prestazioni e costi](CostOptimization_TableUsagePatterns.md) + [Valutare la capacità fornita per un provisioning di dimensioni adeguate](CostOptimization_RightSizedProvisioning.md) # Valutazione dei costi a livello di tabella Lo strumento Cost Explorer disponibile all'interno Console di gestione AWS di consente di visualizzare i costi suddivisi per tipo, ad esempio i costi di lettura, scrittura, archiviazione e backup. Puoi anche visualizzare questi costi riepilogati per periodo, ad esempio per mese o per giorno. Un problema comune con Cost Explorer è che non è possibile rivedere facilmente i costi di una sola tabella particolare, perché Cost Explorer non consente di filtrare o raggruppare in base ai costi di una tabella specifica. **Puoi visualizzare la metrica **Billable table size (Byte)** di ogni tabella nella console Amazon Keyspaces nella scheda Monitor della tabella.** Se sono necessarie ulteriori informazioni relative ai costi per tabella, questa sezione mostra come utilizzare i [tag](tagging-keyspaces.md) per eseguire l'analisi dei costi delle singole tabelle in Cost Explorer. **Topics** + [Come visualizzare i costi di una singola tabella Amazon Keyspaces](#CostOptimization_TableLevelCostAnalysis_ViewInfo) + [Visualizzazione predefinita di Esploratore dei costi](#CostOptimization_TableLevelCostAnalysis_CostExplorer) + [Come utilizzare e applicare i tag di tabella in Esploratore dei costi](#CostOptimization_TableLevelCostAnalysis_Tagging) ## Come visualizzare i costi di una singola tabella Amazon Keyspaces Puoi visualizzare le informazioni di base su una tabella Amazon Keyspaces nella console, tra cui lo schema della chiave primaria, la dimensione fatturabile della tabella e i parametri relativi alla capacità. Puoi utilizzare la dimensione della tabella per calcolare il costo di archiviazione mensile della tabella. Ad esempio, 0,25 USD per GB negli Stati Uniti orientali (Virginia settentrionale). Regione AWS Se la tabella utilizza la modalità di capacità fornita, vengono restituite anche le impostazioni correnti dell'unità di capacità di lettura (RCU) e dell'unità di capacità di scrittura (WCU). È possibile utilizzare queste informazioni per calcolare i costi correnti di lettura e scrittura per la tabella. Tieni presente che questi costi potrebbero cambiare, soprattutto se hai configurato la tabella con la scalabilità automatica di Amazon Keyspaces. ## Visualizzazione predefinita di Esploratore dei costi La visualizzazione predefinita in Cost Explorer fornisce grafici che mostrano il costo delle risorse consumate, ad esempio velocità effettiva e archiviazione. È possibile scegliere di raggruppare questi costi per periodo, ad esempio i totali per mese o per giorno. È inoltre possibile suddividere e confrontare i costi di archiviazione, lettura, scrittura e altre categorie. ![\[Immagine che mostra il costo delle risorse consumate nella vista di Esploratore dei costi.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/CostOptimization/CostExplorerView.png) ## Come utilizzare e applicare i tag di tabella in Esploratore dei costi Per impostazione predefinita, Cost Explorer non fornisce un riepilogo dei costi per nessuna tabella specifica, poiché combina i costi di più tabelle in un totale. Tuttavia, puoi utilizzare l'[assegnazione di tag alle risorse AWS](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) per identificare ogni tabella tramite un tag di metadati. I tag sono coppie chiave-valore che è possibile utilizzare per diversi scopi, ad esempio per identificare tutte le risorse appartenenti a un progetto o a un reparto. Per ulteriori informazioni, consulta [Utilizzo di tag ed etichette per le risorse Amazon Keyspaces](tagging-keyspaces.md). Per questo esempio, utilizziamo una tabella con il nome. **MyTable** 1. Imposta un tag con la chiave di **table\$1name e il valore** di. **MyTable** 1. [Attiva il tag in Esploratore dei costi](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html), quindi filtra il valore del tag per ottenere maggiore visibilità sui costi di ogni tabella. **Nota** Potrebbero essere necessari uno o due giorni prima che il tag inizi a comparire in Esploratore dei costi Puoi impostare i tag dei metadati tu stesso nella console o a livello di codice con CQL, the o SDK. AWS CLI AWS Valuta la possibilità di richiedere l'impostazione di un tag **table\$1name** come parte del nuovo processo di creazione delle tabelle dell'organizzazione. Per ulteriori informazioni, consulta [Crea report di allocazione dei costi utilizzando tag per Amazon Keyspaces](CostAllocationReports.md). # Valuta la modalità di capacità della tua tabella Questa sezione fornisce una panoramica su come selezionare la modalità di capacità appropriata per la tabella Amazon Keyspaces. Ogni modalità è ottimizzata per soddisfare le esigenze di un carico di lavoro diverso in termini di capacità di risposta alle variazioni della velocità di trasmissione effettiva e di fatturazione dell'utilizzo. Per prendere una decisione è necessario bilanciare questi fattori. **Topics** + [Modalità di capacità della tabella disponibili](#CostOptimization_TableCapacityMode_Overview) + [Quando selezionare la modalità di capacità on demand](#CostOptimization_TableCapacityMode_OnDemand) + [Quando selezionare la modalità di capacità assegnata](#CostOptimization_TableCapacityMode_Provisioned) + [Fattori aggiuntivi da valutare nella scelta di una modalità di capacità della tabella](#CostOptimization_TableCapacityMode_AdditionalFactors) ## Modalità di capacità della tabella disponibili Quando crei una tabella Amazon Keyspaces, devi selezionare la modalità di capacità on demand o provisioning. Per ulteriori informazioni, consulta [Configura le modalità di read/write capacità in Amazon Keyspaces](ReadWriteCapacityMode.md). **Modalità di capacità on demand** La modalità di capacità su richiesta è progettata per eliminare la necessità di pianificare o fornire la capacità della tabella Amazon Keyspaces. In questa modalità, la tabella soddisfa istantaneamente le richieste senza la necessità di aumentare o ridurre le risorse (fino al doppio del precedente picco di throughput della tabella). Le tabelle on demand vengono fatturate contando il numero di richieste effettive rispetto alla tabella, quindi paghi solo per ciò che utilizzi anziché per ciò che è stato fornito. **Modalità di capacità assegnata** La modalità di capacità fornita è un modello più tradizionale in cui è possibile definire la capacità disponibile nella tabella per le richieste direttamente o con l'assistenza di Application Auto Scaling. Poiché per la tabella viene assegnata una capacità specifica in un dato momento, la fatturazione si basa sulla capacità assegnata anziché sul numero di richieste. Il superamento della capacità allocata può inoltre far sì che la tabella rifiuti le richieste e riduca l'esperienza degli utenti dell'applicazione. La modalità di capacità fornita richiede un equilibrio tra il non sovra-provisioning o l'insufficiente provisioning della tabella per ottenere entrambi i vantaggi, una bassa incidenza di errori di capacità di throughput insufficiente e l'ottimizzazione dei costi. ## Quando selezionare la modalità di capacità on demand Per l'ottimizzazione dei costi, la modalità on demand è la scelta migliore quando si ha un carico di lavoro imprevedibile simile a quello mostrato nel grafico seguente. Questi fattori contribuiscono a questo tipo di carico di lavoro: + Tempi imprevedibili delle richieste (con conseguenti picchi di traffico) + Volume variabile di richieste (derivante da carichi di lavoro in batch) + scende a zero o al di sotto del 18% del picco per una determinata ora (derivante da ambienti di sviluppo o test) ![\[Immagine che mostra un carico di lavoro intenso con picchi di traffico casuali.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeOnDemand.png) Per i carichi di lavoro con le caratteristiche sopra riportate, l'utilizzo di Application Auto Scaling per mantenere una capacità sufficiente per consentire alla tabella di rispondere ai picchi di traffico può portare a risultati indesiderati. È possibile che la tabella abbia un numero eccessivo di risorse e costi più del necessario, oppure che il provisioning della tabella sia insufficiente e le richieste generino inutili errori di throughput a bassa capacità. In casi come questo, le tabelle su richiesta sono la scelta migliore. Poiché le tabelle su richiesta vengono fatturate su richiesta, non è necessario fare altro a livello di tabella per ottimizzare i costi. È consigliabile valutare regolarmente le tabelle su richiesta per verificare che il carico di lavoro abbia ancora le caratteristiche sopra indicate. Se il carico di lavoro si è stabilizzato, valuta la possibilità di passare alla modalità provisioning per mantenere l'ottimizzazione dei costi. ## Quando selezionare la modalità di capacità assegnata Un carico di lavoro ideale per la modalità di provisioning capacity è quello con un modello di utilizzo più prevedibile, come illustrato nel grafico seguente. I seguenti fattori contribuiscono a un carico di lavoro prevedibile: + Traffico prevedibile/ciclico per una determinata ora o giorno + Picchi di traffico limitati e di breve durata ![\[Immagine che mostra un carico di lavoro abbastanza prevedibile con picchi di traffico limitati.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/CostOptimization/TableCapacityModeProvisioned.png) Poiché i volumi di traffico in una determinata ora o giorno sono più stabili, è possibile impostare la capacità assegnata in modo relativamente simile alla capacità effettivamente consumata della tabella. L'ottimizzazione dei costi di una tabella della capacità assegnata consiste in ultima analisi nell'avvicinare il più possibile la capacità fornita (linea blu) alla capacità consumata (linea arancione) senza aumentare `ThrottledRequests` gli eventi della tabella. Lo spazio tra le due linee rappresenta sia uno spreco di capacità che un'assicurazione contro un'esperienza utente negativa dovuta a errori di capacità di throughput insufficiente. Amazon Keyspaces fornisce Application Auto Scaling per le tabelle di capacità assegnate, che bilancia automaticamente questo valore per tuo conto. Puoi tenere traccia della capacità consumata durante il giorno e configurare la capacità fornita della tabella in base a una manciata di variabili. **Unità di capacità minima** È possibile impostare la capacità minima di una tabella per limitare il verificarsi di errori di capacità di throughput insufficiente, ma ciò non riduce il costo della tabella. Se la tabella presenta periodi di utilizzo ridotto seguiti da un'improvvisa esplosione di utilizzo elevato, l'impostazione del minimo può impedire che Application Auto Scaling imposti la capacità della tabella su un valore troppo basso. **Unità di capacità massima** È possibile impostare la capacità massima di una tabella per limitare un dimensionamento della tabella maggiore del previsto. Valuta la possibilità di applicare un valore massimo alle tabelle di sviluppo o di test, dove non è consigliabile eseguire test di carico su larga scala. È possibile impostare un valore massimo per qualsiasi tabella, ma assicuratevi di valutare regolarmente questa impostazione rispetto alla tabella di base quando la utilizzate in produzione, per evitare errori accidentali di capacità di throughput insufficiente. **Utilizzo di destinazione** L'impostazione dell'utilizzo di destinazione della tabella è il mezzo principale per l'ottimizzazione dei costi per una tabella con capacità assegnata. Se si imposta qui un valore percentuale inferiore, si aumenta l'entità del provisioning eccessivo della tabella, aumentando i costi, ma riducendo il rischio di errori di capacità di throughput insufficiente. L'impostazione di un valore percentuale più elevato consente di ridurre il livello di sovra-provisioning della tabella, ma aumenta il rischio di errori di capacità di throughput insufficiente. ## Fattori aggiuntivi da valutare nella scelta di una modalità di capacità della tabella Al momento di decidere tra le due modalità di capacità, vi sono alcuni fattori aggiuntivi che vale la pena considerare. Quando decidi tra le due modalità di tavolo, considera quanto questo sconto aggiuntivo influisca sul costo del tavolo. In molti casi, anche un carico di lavoro relativamente imprevedibile può essere più conveniente se eseguito su una tabella di capacità assegnata in eccesso con capacità riservata. **Miglioramento della prevedibilità del carico di lavoro** In alcune situazioni, un carico di lavoro può apparentemente avere sia uno schema prevedibile che uno imprevedibile. Sebbene ciò possa essere facilmente supportato con una tabella su richiesta, i costi sarebbero probabilmente inferiori se si riuscissero a migliorare gli schemi imprevedibili del carico di lavoro. Una delle cause più comuni di questi modelli sono le importazioni in batch. Questo tipo di traffico può spesso superare la capacità di base della tabella a tal punto che si verificherebbero errori di capacità di trasmissione insufficiente se la stessa venisse eseguita. Per mantenere un carico di lavoro come questo in esecuzione su una tabella con capacità assegnata, valuta le seguenti opzioni: + Se il batch viene eseguito in orari pianificati, è possibile pianificare un aumento della capacità di auto scalabilità dell'applicazione prima dell'esecuzione. + Se il batch viene eseguito in modo casuale, è consigliabile provare a prolungare il tempo necessario per l'esecuzione anziché eseguirlo il più velocemente possibile. + Aggiungete un periodo di accelerazione all'importazione, in cui la velocità di importazione inizia in modo ridotto ma aumenta lentamente nell'arco di alcuni minuti fino a quando Application Auto Scaling non ha avuto l'opportunità di iniziare a regolare la capacità della tabella. # Valuta le impostazioni di Application Auto Scaling della tua tabella Questa sezione fornisce una panoramica su come valutare le impostazioni Application Auto Scaling delle tabelle Amazon Keyspaces. [Amazon Keyspaces Application Auto](autoscaling.md) Scaling è una funzionalità che gestisce il throughput delle tabelle in base al traffico dell'applicazione e alla metrica di utilizzo prevista. Ciò garantisce che le tabelle abbiano la capacità richiesta per i modelli applicativi. Il servizio Application Auto Scaling monitora l'utilizzo corrente della tabella e lo confronta con il valore di utilizzo target:. `TargetValue` Ti avvisa se è il momento di aumentare o diminuire la capacità allocata. **Topics** + [Informazioni sulle impostazioni dell'Application Auto Scaling](#CostOptimization_AutoScalingSettings_UnderProvisionedTables) + [Come identificare le tabelle con un basso utilizzo di destinazione (<=50%)](#CostOptimization_AutoScalingSettings_IdentifyLowUtilization) + [Come gestire i carichi di lavoro con varianza stagionale](#CostOptimization_AutoScalingSettings_SeasonalVariance) + [Come affrontare carichi di lavoro con picchi di lavoro con pattern sconosciuti](#CostOptimization_AutoScalingSettings_UnknownPatterns) + [Come gestire i carichi di lavoro con applicazioni collegate](#CostOptimization_AutoScalingSettings_BetweenRanges) ## Informazioni sulle impostazioni dell'Application Auto Scaling La definizione del valore corretto per l'utilizzo di destinazione, la fase iniziale e i valori finali è un'attività che richiede il coinvolgimento del team operativo. Ciò consente di definire correttamente i valori in base all'utilizzo storico dell'applicazione, utilizzato per attivare le politiche di Application Auto Scaling. L'obiettivo di utilizzo è la percentuale della capacità totale che deve essere soddisfatta durante un periodo di tempo prima che si applichino le regole dell'Application Auto Scaling. Quando imposti un obiettivo di **utilizzo elevato (un obiettivo intorno al 90%)**, significa che il traffico deve essere superiore al 90% per un periodo di tempo prima che l'Application Auto Scaling venga attivato. Non dovresti utilizzare un target di utilizzo elevato a meno che l'applicazione non sia molto costante e non riceva picchi di traffico. Quando si imposta un **utilizzo molto basso (un obiettivo inferiore al 50%)**, significa che l'applicazione deve raggiungere il 50% della capacità fornita prima di attivare una policy di Application Auto Scaling. A meno che il traffico delle applicazioni non cresca a un ritmo molto aggressivo, questo di solito si traduce in capacità inutilizzata e risorse sprecate. ## Come identificare le tabelle con un basso utilizzo di destinazione (<=50%) Puoi utilizzare AWS CLI o Console di gestione AWS per monitorare e identificare le `TargetValues` politiche di Application Auto Scaling nelle tue risorse Amazon Keyspaces. **Nota** Quando utilizzi tabelle multiregionali in modalità di capacità fornita con scalabilità automatica di Amazon Keyspaces, assicurati di utilizzare le operazioni dell'API Amazon Keyspaces per configurare la scalabilità automatica. Le operazioni API Application Auto Scaling sottostanti che Amazon Keyspaces chiama per tuo conto non hanno funzionalità multiregionali. Per ulteriori informazioni, consulta [Visualizza la capacità fornita e le impostazioni di ridimensionamento automatico per una tabella multiregionale in Amazon Keyspaces](tables-mrr-view.md). ------ #### [ AWS CLI ] 1. Restituisce l'intero elenco di risorse eseguendo il seguente comando: ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra ``` Questo comando restituirà l'elenco completo delle politiche di Application Auto Scaling emesse per qualsiasi risorsa Amazon Keyspaces. Se desideri recuperare solo le risorse da una particolare tabella, puoi aggiungere `–resource-id parameter`. Esempio: ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` 1. Restituisce solo le politiche di ridimensionamento automatico per una particolare tabella eseguendo il seguente comando ``` aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” ``` I valori per le policy di Application Auto Scaling sono evidenziati di seguito. È necessario assicurarsi che il valore target sia superiore al 50% per evitare un eccesso di provisioning. Viene visualizzato un risultato simile al seguente: ``` { "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" } ] } ``` ------ #### [ Console di gestione AWS ] 1. Accedi a Console di gestione AWS e vai alla pagina del CloudWatch servizio in [Getting Started with](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html) the. Console di gestione AWS Seleziona quello appropriato, Regione AWS se necessario. 1. Nel riquadro di navigazione sinistro selezionare **Tables** (Tabelle). Nella pagina **Tables** (Tabelle), selezionare il **nome** della tabella. 1. Nella pagina **Dettagli tabella** della scheda **Capacità**, rivedi le impostazioni Application Auto Scaling della tabella. ------ Se i valori di utilizzo di destinazione sono inferiori o uguali al 50%, è consigliabile esaminare le metriche di utilizzo della tabella per vedere se il [provisioning è insufficiente o eccessivo](CostOptimization_RightSizedProvisioning.md). ## Come gestire i carichi di lavoro con varianza stagionale Si consideri il seguente scenario: l'applicazione funziona con un valore medio minimo per la maggior parte del tempo, ma il target di utilizzo è basso, quindi l'applicazione può reagire rapidamente agli eventi che si verificano in determinate ore del giorno e la capacità è sufficiente ed evitare limitazioni della larghezza di banda della rete. Questo scenario è comune quando un'applicazione è molto impegnata durante il normale orario di ufficio (dalle 9:00 alle 17:00) ma funziona a un livello base nelle altre ore. Poiché alcuni utenti iniziano a connettersi prima delle 9:00, l'applicazione utilizza questa soglia bassa per aumentare rapidamente e raggiungere la capacità *richiesta* nelle ore di punta. Lo scenario potrebbe essere simile al seguente: + Tra le 17:00 e le 9:00, le unità `ConsumedWriteCapacityUnits` sono comprese tra 90 e 100 + Gli utenti iniziano a connettersi all'applicazione prima delle 9:00 e le unità di capacità aumentano considerevolmente (il valore massimo che rilevato è 1500 WCU) + In media, l'utilizzo delle applicazioni varia tra 800 e 1.200 durante l'orario di ufficio Se lo scenario precedente si applica alla tua applicazione, prendi in considerazione l'utilizzo della [scalabilità automatica dell'applicazione pianificata](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html), in cui nella tabella potrebbe ancora essere configurata una regola Application Auto Scaling, ma con un utilizzo del target meno aggressivo che fornisca la capacità aggiuntiva solo agli intervalli specifici richiesti. È possibile utilizzare il AWS CLI per eseguire i seguenti passaggi per creare una regola di ridimensionamento automatico pianificata che viene eseguita in base all'ora del giorno e al giorno della settimana. 1. Registra la tua tabella Amazon Keyspaces come destinazione scalabile con. Application Auto Scaling Un target scalabile è una risorsa che Application Auto Scaling può aumentare ridurre orizzontalmente. ``` 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. Impostazione delle operazioni pianificate in base ai requisiti. Sono necessarie due regole per coprire lo scenario: una per la scalabilità verso l'alto e l'altra per la scalabilità verso il basso. La prima regola per aumentare l'azione pianificata è mostrata nell'esempio seguente. ``` 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" ``` In questo esempio viene mostrata la seconda regola per ridurre l'azione pianificata. ``` 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. Esegui il comando seguente per convalidare che entrambe le regole siano state attivate: ``` aws application-autoscaling describe-scheduled-actions --service-namespace cassandra ``` Si dovrebbe ottenere un risultato simile a questo: ``` { "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'immagine seguente mostra un carico di lavoro di esempio che mantiene sempre il 70% di utilizzo di destinazione. Notate come le regole di autoscaling siano ancora valide e la velocità effettiva non venga ridotta. ![\[Un grafico che mostra l'utilizzo di scrittura in unità al secondo, confrontando la capacità fornita con quella consumata nell'arco di un giorno.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings3.png) Ingrandendo, possiamo notare che c'è stato un picco nell'applicazione che ha attivato la soglia di dimensionamento automatico del 70%, forzandolo ad attivarsi e a fornire la capacità aggiuntiva richiesta per la tabella. L'azione di ridimensionamento automatico pianificata influirà sui valori massimi e minimi ed è tua responsabilità configurarli. ![\[Una visualizzazione più dettagliata del grafico che mostra l'utilizzo di scrittura in unità al secondo, confrontando la capacità fornita con quella consumata, con lo zoom su un orario specifico.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings4.png) ![\[Mostra la visualizzazione dettagliata del grafico che mostra l'utilizzo di scrittura in unità al secondo, confrontando la capacità fornita con la capacità consumata nell'arco di un giorno.\]](http://docs.aws.amazon.com/it_it/keyspaces/latest/devguide/images/CostOptimization/AutoScalingSettings5.png) ## Come affrontare carichi di lavoro con picchi di lavoro con pattern sconosciuti In questo scenario, l'applicazione utilizza un obiettivo di utilizzo molto basso, perché non si conoscono ancora i modelli applicativi e si desidera assicurarsi che il carico di lavoro non subisca errori di velocità effettiva a bassa capacità. Si consiglia invece di utilizzare la [modalità di capacità on demand](ReadWriteCapacityMode.OnDemand.md). Le tabelle on demand sono perfette per carichi di lavoro con picchi di lavoro di cui non si conoscono i pattern di traffico. Con la modalità di capacità on demand, si paga in base alla richiesta per le letture e le scritture dei dati che l'applicazione esegue sulle tabelle. Non è necessario specificare la velocità di lettura e scrittura prevista per l'applicazione, poiché Amazon Keyspaces si adatta istantaneamente ai carichi di lavoro man mano che aumentano o diminuiscono. ## Come gestire i carichi di lavoro con applicazioni collegate In questo scenario, l'applicazione dipende da altri sistemi, ad esempio scenari di elaborazione in batch in cui è possibile avere grandi picchi di traffico in base agli eventi nella logica dell'applicazione. Prendi in considerazione lo sviluppo di una logica di auto-scaling delle applicazioni personalizzata che reagisca a quegli eventi in cui puoi aumentare la capacità delle tabelle `TargetValues` e in base alle tue esigenze specifiche. Potresti trarre vantaggio Amazon EventBridge e utilizzare una combinazione di AWS servizi come λ e Step Functions per rispondere alle tue esigenze applicative specifiche. # Identifica le risorse inutilizzate per ottimizzare i costi in Amazon Keyspaces In questa sezione viene fornita una panoramica su come valutare regolarmente le risorse inutilizzate. Man mano che i requisiti delle applicazioni evolvono, devi assicurarti che nessuna risorsa venga inutilizzata e contribuisca a costi non necessari di Amazon Keyspaces. Le procedure descritte di seguito utilizzano i CloudWatch parametri di Amazon per identificare le risorse inutilizzate e agire per ridurre i costi. Puoi monitorare Amazon Keyspaces utilizzando CloudWatch, che raccoglie ed elabora dati grezzi da Amazon Keyspaces in metriche leggibili quasi in tempo reale. Queste statistiche vengono conservate per un determinato periodo di tempo, così da consentire l'accesso a informazioni cronologiche per comprendere meglio l'utilizzo. Per impostazione predefinita, i dati metrici di Amazon Keyspaces vengono inviati automaticamente a. CloudWatch Per ulteriori informazioni, consulta [What is Amazon CloudWatch?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) e [conservazione dei parametri](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#metrics-retention) nella *Amazon CloudWatch User Guide*. **Topics** + [Come identificare le risorse inutilizzate](#CostOptimization_UnusedResources_Identifying) + [Identificazione delle risorse non utilizzate della tabella](#CostOptimization_UnusedResources_Tables) + [Pulizia delle risorse non utilizzate della tabella](#CostOptimization_UnusedResources_Tables_Cleanup) + [Pulizia dei backup di point-in-time ripristino inutilizzati (PITR)](#CostOptimization_UnusedResources_Backups) ## Come identificare le risorse inutilizzate Per identificare le tabelle inutilizzate, puoi dare un'occhiata alle seguenti CloudWatch metriche per un periodo di 30 giorni per capire se ci sono letture o scritture attive su una tabella specifica: **`ConsumedReadCapacityUnits`** Il numero di unità di capacità di lettura utilizzate nel periodo di tempo specificato, per permettere di tenere traccia di quanta capacità viene utilizzata. Puoi recuperare la capacità di lettura totale consumata per una tabella. **`ConsumedWriteCapacityUnits`** Il numero di unità di capacità di scrittura utilizzate nel periodo di tempo specificato, per permettere di tenere traccia di quanta capacità viene utilizzata. È possibile recuperare la capacità di scrittura totale consumata per una tabella. ## Identificazione delle risorse non utilizzate della tabella Amazon CloudWatch è un servizio di monitoraggio e osservabilità che fornisce i parametri della tabella Amazon Keyspaces che puoi utilizzare per identificare le risorse non utilizzate. CloudWatch le metriche possono essere visualizzate sia tramite. Console di gestione AWS AWS Command Line Interface ------ #### [ AWS Command Line Interface ] Per visualizzare le metriche delle tabelle tramite AWS Command Line Interface, puoi utilizzare i seguenti comandi. 1. Per prima cosa, valuta le letture della tabella: **Nota** Se il nome della tabella non è univoco all'interno del tuo account, devi specificare anche il nome del keyspace. ``` aws cloudwatch get-metric-statistics --metric-name ConsumedReadCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` Per evitare di identificare erroneamente una tabella come non utilizzata, valutare i parametri per un periodo più lungo. **Scegliete un intervallo di inizio e fine appropriato, ad esempio **30 giorni**, e un periodo appropriato, ad esempio 86400.** Nei dati restituiti, qualsiasi **somma** superiore a **0** indica che la tabella che stai valutando ha ricevuto traffico di lettura durante quel periodo. Il risultato seguente mostra una tabella che riceve traffico di lettura nel periodo valutato: ``` { "Timestamp": "2022-08-25T19:40:00Z", "Sum": 36023355.0, "Unit": "Count" }, { "Timestamp": "2022-08-12T19:40:00Z", "Sum": 38025777.5, "Unit": "Count" }, ``` Il risultato seguente mostra una tabella che non riceve traffico di lettura nel periodo valutato: ``` { "Timestamp": "2022-08-01T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-20T19:50:00Z", "Sum": 0.0, "Unit": "Count" }, ``` 1. Quindi, valuta le scritture della tabella: ``` aws cloudwatch get-metric-statistics --metric-name ConsumedWriteCapacityUnits --start-time --end-time --period --namespace AWS/Cassandra --statistics Sum -- dimensions Name=TableName,Value= ``` Per evitare di identificare erroneamente una tabella come non utilizzata, consigliamo di valutare i parametri per un periodo più lungo. Scegli un intervallo appropriato di inizio e fine, ad esempio **30 giorni**, e un periodo appropriato, ad esempio **86400**. Nei dati restituiti, qualsiasi **somma** superiore a **0** indica che la tabella che stai valutando ha ricevuto traffico di scrittura durante quel periodo. Il risultato seguente mostra una tabella che riceve traffico di scrittura nel periodo valutato: ``` { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 41014457.0, "Unit": "Count" }, { "Timestamp": "2022-08-18T20:15:00Z", "Sum": 40048531.0, "Unit": "Count" }, ``` Il risultato seguente mostra una tabella che non riceve traffico di scrittura nel periodo valutato: ``` { "Timestamp": "2022-07-31T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, { "Timestamp": "2022-08-19T20:15:00Z", "Sum": 0.0, "Unit": "Count" }, ``` ------ #### [ Console di gestione AWS ] I passaggi seguenti consentono di valutare l'utilizzo delle risorse tramite. Console di gestione AWS 1. Accedi Console di gestione AWS e vai alla pagina del CloudWatch servizio all'indirizzo [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). Se necessario, seleziona l'opzione appropriata Regione AWS in alto a destra della console. 1. Nella barra di navigazione a sinistra, individua la sezione **Metriche** e scegli **Tutte le metriche**. 1. L'azione sopra riportata apre una dashboard con due pannelli. Nel pannello superiore, puoi vedere le metriche attualmente rappresentate graficamente. In basso puoi selezionare le metriche disponibili per il grafico. Scegli Amazon Keyspaces nel pannello inferiore. 1. Nel pannello di selezione delle metriche di Amazon Keyspaces, scegli la categoria **Table Metrics** per mostrare le metriche per le tue tabelle nella regione corrente. 1. Identifica il nome della tabella scorrendo il menu verso il basso, quindi scegli le metriche `ConsumedReadCapacityUnits` e per la tabella. `ConsumedWriteCapacityUnits` 1. **Scegli la scheda **Metriche grafiche (2)** e imposta la colonna **Statistica** su Somma.** 1. Per evitare di identificare erroneamente una tabella come inutilizzata, valuta le metriche della tabella per un periodo più lungo. Nella parte superiore del pannello grafico, scegliete un periodo di tempo appropriato, ad esempio 1 mese, per valutare la tabella. **Scegli **Personalizzato**, scegli **1 mese** nel menu a discesa e scegli Applica.** 1. Valuta i parametri nel grafico della tabella per determinare se viene utilizzata. Parametri superiori a **0** indicano che durante il periodo di tempo preso in considerazione la tabella è stata utilizzata. Un grafico piatto con **0** sia in lettura che in scrittura indica che una tabella non è utilizzata. ------ ## Pulizia delle risorse non utilizzate della tabella Se sono state identificate risorse non utilizzate della tabella, è possibile ridurne i costi correnti nei seguenti modi. **Nota** Se hai identificato una tabella non utilizzata ma desideri comunque mantenerla disponibile nel caso in cui sia necessario accedervi in futuro, valuta la possibilità di passare alla modalità on demand. Altrimenti, puoi prendere in considerazione l'eliminazione della tabella. **Modalità di capacità** Amazon Keyspaces addebita i costi per la lettura, la scrittura e l'archiviazione dei dati nelle tabelle Amazon Keyspaces. Amazon Keyspaces offre [due modalità di capacità](ReadWriteCapacityMode.md), che includono opzioni di fatturazione specifiche per l'elaborazione di letture e scritture sulle tabelle: su richiesta e con provisioning. La modalità read/write di capacità controlla il modo in cui ti viene addebitato il throughput di lettura e scrittura e come gestisci la capacità. Per le tabelle in modalità on demand, non è necessario specificare la velocità effettiva di lettura e scrittura che si prevede l'applicazione esegua. Amazon Keyspaces ti addebita le spese di lettura e scrittura eseguite dall'applicazione sulle tue tabelle in termini di unità di richiesta di lettura e unità di richiesta di scrittura. Se non c'è alcuna attività sul tavolo, non pagherai per la velocità effettiva, ma dovrai comunque sostenere un costo di archiviazione. **Eliminazione delle tabelle** Se hai scoperto una tabella inutilizzata e desideri eliminarla, valuta la possibilità di eseguire prima un backup o esportare i dati. I backup eseguiti AWS Backup possono sfruttare lo storage a freddo su più livelli, riducendo ulteriormente i costi. Consulta la documentazione sulla [gestione dei piani di backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans) per informazioni su come utilizzare un ciclo di vita per spostare il backup nella conservazione a freddo. Dopo aver eseguito il backup della tabella, puoi scegliere di eliminarla tramite la Console di gestione AWS o tramite l' AWS Command Line Interface. ## Pulizia dei backup di point-in-time ripristino inutilizzati (PITR) Amazon Keyspaces offre Point-in-time il ripristino, che fornisce backup continui per 35 giorni per aiutarti a proteggerti da scritture o eliminazioni accidentali. I backup PITR hanno dei costi associati. Consulta la documentazione all'indirizzo [Backup e ripristino dei dati con point-in-time ripristino per Amazon Keyspaces](PointInTimeRecovery.md) per determinare se nelle tabelle sono abilitati backup che potrebbero non essere più necessari. # Valuta i modelli di utilizzo delle tabelle per ottimizzare prestazioni e costi Questa sezione fornisce una panoramica su come valutare se stai utilizzando in modo efficiente le tabelle Amazon Keyspaces. Esistono alcuni modelli di utilizzo che non sono ottimali per Amazon Keyspaces e consentono l'ottimizzazione sia dal punto di vista delle prestazioni che dei costi. **Topics** + [Riduzione del numero di operazioni ad elevata consistenza di lettura](#CostOptimization_TableUsagePatterns_StronglyConsistentReads) + [Abilitazione del Time to Live (TTL)](#CostOptimization_TableUsagePatterns_TTL) ## Riduzione del numero di operazioni ad elevata consistenza di lettura Amazon Keyspaces ti consente di configurare la [coerenza di lettura](consistency.md#ReadConsistency) in base alla richiesta. Le richieste di lettura sono a consistenza finale per impostazione predefinita. Alla fine, le letture coerenti vengono addebitate a 0,5 RCU per un massimo di 4 KB di dati. La maggior parte dei carichi di lavoro distribuiti sono flessibili e possono tollerare la consistenza finale. Tuttavia, possono esserci schemi di accesso che richiedono elevata consistenza di lettura. Le letture estremamente coerenti vengono addebitate a 1 RCU per un massimo di 4 KB di dati, raddoppiando sostanzialmente i costi di lettura. Amazon Keyspaces ti offre la flessibilità necessaria per utilizzare entrambi i modelli di coerenza sulla stessa tabella. È possibile valutare il carico di lavoro e il codice dell'applicazione per verificare se vengono utilizzate letture ad elevata consistenza solo dove necessario. ## Abilitazione del Time to Live (TTL) [Time to Live (TTL)](TTL.md) ti aiuta a semplificare la logica delle applicazioni e a ottimizzare il prezzo dello storage facendo scadere automaticamente i dati dalle tabelle. I dati che non ti servono più vengono eliminati automaticamente dalla tabella in base al valore Time to Live che hai impostato. # Valutare la capacità fornita per un provisioning di dimensioni adeguate Questa sezione fornisce una panoramica su come valutare se il provisioning è della giusta dimensione sulle tabelle Amazon Keyspaces. Man mano che il carico di lavoro si evolve, è necessario modificare le procedure operative in modo appropriato, soprattutto quando la tabella Amazon Keyspaces è configurata in modalità provisioning e si corre il rischio di un provisioning eccessivo o insufficiente delle tabelle. Le procedure descritte in questa sezione richiedono informazioni statistiche che devono essere acquisite dalle tabelle Amazon Keyspaces che supportano l'applicazione di produzione. Per comprendere il comportamento dell'applicazione, è necessario definire un periodo di tempo sufficientemente significativo da acquisire la stagionalità dei dati dell'applicazione. Ad esempio, se l'applicazione mostra pattern settimanali, l'utilizzo di un periodo di tre settimane dovrebbe fornire spazio sufficiente per analizzare le esigenze di velocità di trasmissione effettiva dell'applicazione. Se non sai da dove iniziare, utilizza almeno un mese di utilizzo dei dati per i calcoli seguenti. Durante la valutazione della capacità, per le tabelle Amazon Keyspaces puoi **configurare le unità di capacità di lettura RCUs () e le unità di capacità di scrittura (****WCU**) in modo indipendente. **Topics** + [Come recuperare i parametri di consumo dalle tabelle Amazon Keyspaces](#CostOptimization_RightSizedProvisioning_ConsumptionMetrics) + [Come identificare tabelle Amazon Keyspaces il cui provisioning è insufficiente](#CostOptimization_RightSizedProvisioning_UnderProvisionedTables) + [Come identificare tabelle Amazon Keyspaces sovrafornite](#CostOptimization_RightSizedProvisioning_OverProvisionedTables) ## Come recuperare i parametri di consumo dalle tabelle Amazon Keyspaces Per valutare la capacità della tabella, monitora le seguenti CloudWatch metriche e seleziona la dimensione appropriata per recuperare le informazioni della tabella: | unità di capacità in lettura | Unità di capacità in scrittura | | --- | --- | | `ConsumedReadCapacityUnits` | `ConsumedWriteCapacityUnits` | | `ProvisionedReadCapacityUnits` | `ProvisionedWriteCapacityUnits` | | `ReadThrottleEvents` | `WriteThrottleEvents` | È possibile eseguire questa operazione tramite AWS CLI o il. Console di gestione AWS ------ #### [ AWS CLI ] Prima di recuperare le metriche di consumo della tabella, devi iniziare acquisendo alcuni punti dati storici utilizzando l'API. CloudWatch Inizia creando due file: `write-calc.json` e `read-calc.json`. Questi file rappresentano i calcoli per la tabella. È necessario aggiornare alcuni campi, come indicato nella tabella seguente, in modo che corrispondano all'ambiente in uso. **Nota** Se il nome della tabella non è univoco all'interno del tuo account, devi specificare anche il nome del keyspace. | Nome campo | Definizione | Esempio | | --- | --- | --- | | | Il nome della tabella che stai analizzando | SampleTable | | | Il periodo di tempo utilizzato per valutare l'obiettivo di utilizzo, in secondi | Per un periodo di 1 ora è necessario specificare: 3600 | | | L'inizio dell'intervallo di valutazione, specificato nel formato ISO8601 | 2022-02-21T23:00:00 | | | La fine dell'intervallo di valutazione, specificata nel formato ISO8601 | 2022-02-22T06:00:00 | Il file di calcolo di scrittura recupera il numero di WCU fornite e consumate nel periodo di tempo per l'intervallo di date specificato. Genera inoltre una percentuale di utilizzo che può essere utilizzata per l'analisi. Il contenuto completo del `write-calc.json` file dovrebbe essere simile a quello illustrato nell'esempio seguente. ``` { "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 } ``` Il file di calcolo di lettura utilizza metriche simili. Questo file recupera quanti ne RCUs sono stati forniti e consumati durante il periodo di tempo per l'intervallo di date specificato. Il contenuto del `read-calc.json` file dovrebbe apparire come in questo esempio. ``` { "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 } ``` Dopo aver creato i file, puoi iniziare a recuperare i dati di utilizzo. 1. Per recuperare i dati di utilizzo della scrittura, emettete il seguente comando: ``` aws cloudwatch get-metric-data --cli-input-json file://write-calc.json ``` 1. Per recuperare i dati di utilizzo in lettura, emettete il seguente comando: ``` aws cloudwatch get-metric-data --cli-input-json file://read-calc.json ``` Il risultato per entrambe le query è una serie di punti dati in formato JSON che possono essere utilizzati per l'analisi. I risultati dipendono dal numero di punti dati specificati, dal periodo e dai dati specifici del carico di lavoro. Potrebbe essere come nell'esempio seguente. ``` { "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": [] } ``` **Nota** Se si specifica un periodo breve e un intervallo di tempo lungo, potrebbe essere necessario modificare il `MaxDatapoints` valore, che per impostazione predefinita è impostato su 24 nello script. Ciò rappresenta un punto dati per ora e 24 al giorno. ------ #### [ Console di gestione AWS ] 1. Accedi a Console di gestione AWS e vai alla pagina del CloudWatch servizio in [Getting Started with the Console di gestione AWS](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/getting-started.html). Seleziona quello appropriato, Regione AWS se necessario. 1. Individua la sezione Metriche nella barra di navigazione a sinistra e scegli **Tutte le metriche**. 1. Si apre una dashboard con due pannelli. Il pannello superiore mostra l'immagine e il pannello inferiore contiene le metriche che desideri rappresentare graficamente. Scegli il pannello Amazon Keyspaces. 1. Scegli la categoria **Table Metrics** dai pannelli secondari. Questo ti mostra le tabelle nella tua cartella corrente. Regione AWS 1. Identificare il nome della tabella scorrendo il menu verso il basso e selezionare le metriche dell'operazione di scrittura: `ConsumedWriteCapacityUnits` e `ProvisionedWriteCapacityUnits` **Nota** Questo esempio illustra le metriche delle operazioni di scrittura, ma puoi anche utilizzare questi passaggi per visualizzare graficamente le metriche delle operazioni di lettura. 1. Seleziona la scheda **Graphed metrics (2)** (Metriche nel grafico) per modificare le formule. Per impostazione predefinita, CloudWatch sceglie la funzione statistica **Average** per i grafici. 1. Dopo aver selezionato entrambe le metriche nel grafico (la casella di controllo a sinistra), selezionare il menu **Add math** (Aggiungi matematica), seguito da **Common** (Comune), quindi selezionare la funzione **Percentage** (Percentuale). Ripetere la procedura due volte. È la prima volta che si seleziona la funzione **Percentuale**. Seconda volta che si seleziona la funzione **Percentuale**. 1. A questo punto dovresti avere quattro metriche nel menu in basso. Lavoriamo sul calcolo `ConsumedWriteCapacityUnits`. Per essere coerenti, devi abbinare i nomi a quelli che hai usato nella AWS CLI sezione. Fare clic su **m1 ID** e modificare questo valore in **consumedWCU**. 1. Modifica della statistica da **Average** (Media) a **Sum** (Somma). Questa azione crea automaticamente un'altra metrica chiamata **ANOMALY\$1DETECTION\$1BAND**. **Nell'ambito di questa procedura, puoi ignorarla rimuovendo la casella di controllo sulla metrica ad1 appena generata.** 1. Ripetere il passaggio 8 per rinominare **m2 ID** in **provisionedWCU**. Lasciare la statistica impostata su **Average** (Media). 1. **Scegli l'etichetta **Expression1** e aggiorna il valore su **m1** e l'etichetta su Consumed. WCUs** **Nota** Assicurati di aver selezionato solo **m1** (casella di controllo a sinistra) e **provisionedWCU** per visualizzare correttamente i dati. Aggiorna la formula facendo clic su **Details** (Dettagli) e modificando la formula in **consumedWCU/PERIOD(consumedWCU)**. Questo passaggio potrebbe anche generare un'altra metrica **ANOMALY\$1DETECTION\$1BAND**, ma nell'ambito di questa procedura puoi ignorarla. 1. Ora dovreste avere due grafici: uno che indichi il vostro approvvigionamento sulla tabella e l'altro che indichi il consumo. WCUs WCUs 1. Aggiornare la formula percentuale selezionando il grafico Expression2 (**e2**). **Rinominate le etichette e impostatele su IDs UtilizationPercentage.** Rinominare la formula in modo che corrisponda a **100\$1(m1/provisionedWCU)**. 1. Rimuovi la casella di controllo da tutte le metriche tranne **utilizationPercentage per visualizzare i tuoi modelli di utilizzo**. L'intervallo predefinito è impostato su 1 minuto, ma sentitevi liberi di modificarlo se necessario. I risultati ottenuti dipendono dai dati effettivi del carico di lavoro. Gli intervalli con un utilizzo superiore al 100% sono soggetti a eventi di errore relativi alla bassa capacità di throughput. Amazon Keyspaces offre una capacità di [burst, ma non appena la capacità](throughput-bursting.md) di burst viene esaurita, qualsiasi elemento superiore al 100% presenta eventi di errore di bassa capacità di throughput. ------ ## Come identificare tabelle Amazon Keyspaces il cui provisioning è insufficiente Per la maggior parte dei carichi di lavoro, una tabella viene considerata sottodimensionata quando consuma costantemente più dell'80% della capacità assegnata. La [capacità burst](throughput-bursting.md) è una funzionalità di Amazon Keyspaces che consente ai clienti di consumare temporaneamente RCUs/WCUs più di quanto originariamente fornito (più del throughput al secondo assegnato definito per la tabella). La capacità di espansione è stata creata per assorbire improvvisi aumenti di traffico dovuti a eventi speciali o picchi di utilizzo. Questa capacità di burst è limitata, per ulteriori informazioni, consulta. [Usa la capacità burst in modo efficace in Amazon Keyspaces](throughput-bursting.md) Non appena la capacità inutilizzata RCUs è esaurita, si possono verificare degli errori di throughput a bassa capacità se si tenta di consumare più capacità di quella fornita. WCUs Quando il traffico delle applicazioni si avvicina al tasso di utilizzo dell'80%, il rischio che si verifichino eventi di errore di throughput a bassa capacità è notevolmente maggiore. La regola del tasso di utilizzo dell'80% varia in base alla stagionalità dei dati e alla crescita del traffico. Considerare i seguenti scenari: + Se il traffico è rimasto **stabile** a un tasso di utilizzo di circa il 90% negli ultimi 12 mesi, la tabella ha la capacità corretta + Se il traffico delle applicazioni **aumenta** a un tasso dell'8% mensile in meno di 3 mesi, si arriverà al 100% + Se il traffico delle applicazioni **aumenta** a un tasso dell'5% mensile in meno di 4 mesi, si arriverà al 100% I risultati delle query precedenti forniscono un'immagine del tasso di utilizzo. Utilizzali come guida per valutare ulteriormente altre metriche che possono aiutarti a scegliere di aumentare la capacità della tabella in base alle esigenze (ad esempio: un tasso di crescita mensile o settimanale). Collabora con il tuo team operativo per definire qual è una buona percentuale per il carico di lavoro e le tabelle. Esistono scenari speciali in cui i dati sono distorti quando vengono analizzati su base giornaliera o settimanale. Ad esempio, con le applicazioni stagionali che presentano picchi di utilizzo durante l'orario di lavoro (ma che poi scendono quasi a zero al di fuori dell'orario di lavoro), è possibile trarre vantaggio dalla [pianificazione dell'auto-scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html) delle applicazioni, in cui si specificano le ore del giorno (e i giorni della settimana) per aumentare la capacità fornita, nonché quando ridurla. Invece di puntare a una maggiore capacità per coprire le ore di punta, puoi anche trarre vantaggio dalle configurazioni di [auto-scaling delle tabelle di Amazon Keyspaces](autoscaling.md) se la stagionalità è meno pronunciata. ## Come identificare tabelle Amazon Keyspaces sovrafornite I risultati delle query ottenuti dagli script precedenti forniscono i dati necessari per eseguire alcune analisi iniziali. Se il set di dati presenta valori di utilizzo inferiori al 20% per diversi intervalli, è possibile che la tabella presenti un provisioning eccessivo. Per definire ulteriormente se è necessario ridurre il numero di WCUs RCUS, è necessario rivedere le altre letture negli intervalli. Quando la tabella contiene diversi intervalli di utilizzo ridotti, è possibile trarre vantaggio dall'utilizzo delle politiche di Application Auto Scaling, pianificando Application Auto Scaling o semplicemente configurando le politiche di Application Auto Scaling predefinite per la tabella basate sull'utilizzo. Se hai un carico di lavoro con un basso utilizzo rispetto a un elevato rapporto di accelerazione (**Max (ThrottleEvents) /Min (ThrottleEvents)** nell'intervallo), ciò potrebbe accadere quando hai un carico di lavoro molto intenso in cui il traffico aumenta in modo significativo in giorni (o ore del giorno) specifici, ma per il resto è costantemente basso. In questi scenari, potrebbe essere utile utilizzare l'[Application Auto Scaling pianificato](https://docs.aws.amazon.com/autoscaling/application/userguide/examples-scheduled-actions.html).