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à.
Questa sezione fornisce una panoramica su come valutare le impostazioni Application Auto Scaling delle tabelle Amazon Keyspaces. Amazon Keyspaces Application Auto 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.
Argomenti
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 AWS Management Console 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.
-
Restituisce l'intero elenco di risorse eseguendo il seguente comando:
aws application-autoscaling describe-scaling-policies --service-namespace cassandraQuesto 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. Per esempio:aws application-autoscaling describe-scaling-policies --service-namespace cassandra --resource-id "keyspace/keyspace-name/table/table-name” -
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:<region>:<account-id>:scalingPolicy:<uuid>:resource/keyspaces/table/table-name-scaling-policy", "PolicyName": $<full-gsi-name>”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:index:WriteCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "KeyspacesWriteCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:48.641000+10:00" }, { "PolicyARN": "arn:aws:autoscaling:<region>:<account-id>:scalingPolicy:<uuid>:resource/keyspaces/table/table-name/index/<index-name>:policyName/$<full-gsi-name>-scaling-policy", "PolicyName":$<full-table-name>”, "ServiceNamespace": "cassandra", "ResourceId": "keyspace/keyspace-name/table/table-name", "ScalableDimension": "cassandra:index:ReadCapacityUnits", "PolicyType": "TargetTrackingScaling", "TargetTrackingScalingPolicyConfiguration": { "TargetValue": 70.0, "PredefinedMetricSpecification": { "PredefinedMetricType": "CassandraReadCapacityUtilization" } }, "Alarms": [ ... ], "CreationTime": "2022-03-04T16:23:47.820000+10:00" } ] }
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.
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à
ConsumedWriteCapacityUnitssono 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, 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.
-
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 -
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" -
Esegui il comando seguente per convalidare che entrambe le regole siano state attivate:
aws application-autoscaling describe-scheduled-actions --service-namespace cassandraSi dovrebbe ottenere un risultato simile a questo:
{ "ScheduledActions": [ { "ScheduledActionName": "my-5-8-scheduled-down-action", "ScheduledActionARN": "arn:aws:autoscaling:<region>:<account>:scheduledAction:<uuid>: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:<region>:<account>:scheduledAction:<uuid>: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.
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.
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. 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.
