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à.
Valuta le impostazioni di ridimensionamento automatico della tabella DynamoDB
In questa sezione viene fornita una panoramica su come valutare le impostazioni di dimensionamento automatico sulle tabelle DynamoDB. La scalabilità automatica di Amazon DynamoDB è una funzionalità che gestisce il throughput di tabelle e GSI indici secondari globali () in base al traffico dell'applicazione e alla metrica di utilizzo target. Ciò garantisce che le tabelle o le tabelle GSIs dispongano della capacità richiesta per i modelli applicativi.
Il servizio di scalabilità AWS automatica monitorerà l'utilizzo corrente della tabella e lo confronterà con il valore di utilizzo target:. TargetValue Invierà una notifica se è necessario aumentare o diminuire la capacità allocata.
Argomenti
- Comprendere le impostazioni di dimensionamento automatico
- Come identificare le tabelle con un basso utilizzo di destinazione (<=50%)
- Come gestire i carichi di lavoro con varianza stagionale
- Come affrontare carichi di lavoro con picchi di lavoro con pattern sconosciuti
- Come gestire i carichi di lavoro con applicazioni collegate
Comprendere le impostazioni di dimensionamento automatico
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, che verranno utilizzati per attivare le policy AWS di dimensionamento automatico. Il target di utilizzo è la percentuale della capacità totale che deve essere raggiunta durante un periodo di tempo prima che si applichino le regole di dimensionamento automatico.
Quando si imposta un target di utilizzo elevato (intorno al 90%), significa che il traffico deve essere superiore al 90% per un periodo di tempo prima che si attivi il dimensionamento automatico. 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 target inferiore al 50%), significa che l'applicazione deve raggiungere il 50% della capacità fornita prima di attivare una policy di dimensionamento automatico. 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 policy di auto scaling nelle tue risorse DynamoDB:
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 inizieranno a connettersi prima delle 9:00, l'applicazione utilizza questa soglia bassa per aumentare rapidamente la capacità richiesta nelle ore di punta.
Lo scenario potrebbe essere simile al seguente:
-
Tra le 17:00 e le 9:00, le unità
ConsumedWriteCapacitysono comprese tra 90 e 100 -
Gli utenti iniziano a connettersi all'applicazione prima delle 9:00 e le unità di capacità aumentano notevolmente (il valore massimo che hai visto è 1500) WCU
-
In media, l'utilizzo delle applicazioni varia tra 800 e 1.200 durante l'orario di ufficio
Se lo scenario precedente è applicabile alla propria situazione, prendere in considerazione l'utilizzo del dimensionamento automatico pianificato, in cui la tabella potrebbe comunque avere una regola configurata di dimensionamento automatico dell'applicazione, ma con un utilizzo di destinazione meno aggressivo che fornisca la capacità aggiuntiva solo negli intervalli specifici necessari.
È possibile AWS CLI eseguire i seguenti passaggi per creare una regola di autoscaling pianificato che verrà eseguita in base all'ora del giorno e al giorno della settimana.
-
Registra la tua tabella DynamoDB GSI o 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 dynamodb \ --scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id table/<table-name> \ --min-capacity 90 \ --max-capacity 1500 -
Impostazione delle operazioni pianificate in base ai requisiti.
Avremo bisogno di due regole per coprire lo scenario: una per l'aumento e una per la riduzione. La prima regola per aumentare l'operazione pianificata:
aws application-autoscaling put-scheduled-action \ --service-namespace dynamodb \ --scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id 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 seconda regola per ridurre l'operazione pianificata:
aws application-autoscaling put-scheduled-action \ --service-namespace dynamodb \ --scalable-dimension dynamodb:table:WriteCapacityUnits \ --resource-id 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 dynamodbSi dovrebbe ottenere un risultato simile a questo:
{ "ScheduledActions": [ { "ScheduledActionName": "my-5-8-scheduled-down-action", "ScheduledActionARN": "arn:aws:autoscaling:<region>:<account>:scheduledAction:<uuid>:resource/dynamodb/table/<table-name>:scheduledActionName/my-5-8-scheduled-down-action", "ServiceNamespace": "dynamodb", "Schedule": "cron(15 17 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "table/<table-name>", "ScalableDimension": "dynamodb: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/dynamodb/table/<table-name>:scheduledActionName/my-8-5-scheduled-action", "ServiceNamespace": "dynamodb", "Schedule": "cron(45 8 ? * MON-FRI *)", "Timezone": "Australia/Brisbane", "ResourceId": "table/<table-name>", "ScalableDimension": "dynamodb: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. Si noti come le regole di dimensionamento automatico siano ancora valide e la velocità di trasmissione effettiva non verrà ridotta.
Ingrandendo, possiamo notare che c'è stato un picco nell'applicazione che ha attivato la soglia di autoscaling del 70%, costringendo l'auto scaling ad entrare in gioco e fornire la capacità aggiuntiva richiesta per la tabella. L'operazione di dimensionamento automatico pianificata influirà sui valori massimi e minimi e la configurazione deve essere effettuata dall'utente.
Come affrontare carichi di lavoro con picchi di lavoro con pattern sconosciuti
In questo scenario, l'applicazione utilizza un target di utilizzo molto basso perché non si conoscono ancora i pattern dell'applicazione e si desidera assicurarsi che il carico di lavoro non sia limitato.
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 trasmissione effettiva di lettura e scrittura che si prevede l'applicazione abbia, in quanto DynamoDB adatta istantaneamente i 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.
Prendere in considerazione lo sviluppo di una logica di dimensionamento automatico personalizzata che reagisca a quegli eventi in cui è possibile aumentare la capacità delle tabelle e dei TargetValues base alle esigenze specifiche. Potresti trarre vantaggio Amazon EventBridge e utilizzare una combinazione di AWS servizi come Lambda e Step Functions per rispondere alle esigenze specifiche delle tue applicazioni.
