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 guida fornisce consigli per scegliere la dimensione e il tipo di nodo del cluster Amazon DynamoDB Accelerator DAX () appropriati per la tua applicazione. Queste istruzioni consentono di valutare il traffico DAX dell'applicazione, selezionando una configurazione del cluster e testandola.
Se hai un cluster DAX esistente e vuoi determinare se ha il numero e la dimensione appropriati dei nodi, fai riferimento a Ridimensionamento di un cluster DAX.
Panoramica
È importante dimensionare il cluster DAX in modo appropriato per il carico di lavoro, sia se stai creando un nuovo cluster o gestendo un cluster esistente. Con il passare del tempo e il carico di lavoro dell'applicazione cambia, quindi devi rivedere periodicamente le decisioni di dimensionamento per assicurarti che siano ancora appropriate.
Il processo in genere è costituito da queste fasi:
-
Stima del traffico. In questa fase, è possibile effettuare previsioni sul volume di traffico che l'applicazione invierà a DAX, sulla natura del traffico (operazioni di lettura e scrittura) e sulla velocità di hit della cache prevista.
-
Test di carico. In questa fase, crei un cluster e invii il traffico rispecchiando le stime del passaggio precedente. Ripeti questo passaggio fino a trovare una configurazione del cluster adatta.
-
Monitoraggio della produzione. Durante l'utilizzo dell'applicazione DAX in produzione, è necessario monitorare il cluster per verificare continuamente che sia ancora dimensionato correttamente man mano che il carico di lavoro cambia nel tempo.
Stima del traffico.
Esistono tre fattori principali che caratterizzano un carico di lavoro DAX tipico:
-
Percentuale di riscontri nella cache
-
Unità di capacità di lettura () RCUs al secondo
-
Unità di capacità di scrittura (WCUs) al secondo
Stima della percentuale di riscontri nella cache
Se disponi già di un DAX cluster, puoi utilizzare i CloudWatch parametri ItemCacheHits e ItemCacheMisses Amazon per determinare la frequenza di accesso alla cache. La percentuale di riscontri nella cache è uguale a ItemCacheHits / (ItemCacheHits + ItemCacheMisses). Se il carico di lavoro include operazioni Query o Scan, è necessario esaminare anche i parametri QueryCacheHits, QueryCacheMisses, ScanCacheHits e ScanCacheMisses. Le percentuali di accesso alla cache variano da un'applicazione all'altra e sono fortemente influenzate dall'impostazione Time to Live (TTL) del cluster. Le percentuali di successo tipiche per le applicazioni utilizzate DAX sono dell'85-95 percento.
Stima delle unità di capacità in lettura e scrittura
Se disponi già di tabelle DynamoDB per la tua applicazione, consulta le metriche e. ConsumedReadCapacityUnitsConsumedWriteCapacityUnits CloudWatch Utilizza la statistica Sum e dividi per il numero di secondi del periodo.
Se disponi già di un DAX cluster, ricorda che la metrica DynamoDB ConsumedReadCapacityUnits tiene conto solo degli errori nella cache. Quindi, per avere un'idea delle unità di capacità in lettura al secondo gestite dal cluster DAX, dividi il numero per il tasso di mancati riscontri della cache (ovvero, 1 - tasso di hit della cache).
Se non disponi già di una tabella DynamoDB, consulta la documentazione sulle unità di capacità di lettura e scrittura per stimare il traffico in base al tasso di richieste stimato dell'applicazione, agli elementi a cui si accede per richiesta e alle dimensioni degli elementi.
Quando effettui le stime del traffico, pianifica la crescita futura e i picchi previsti e imprevisti per garantire che il cluster abbia lo spazio sufficiente per l'aumento del traffico.
Test di caricamento
La fase successiva alla stima del traffico consiste nel testare la configurazione del cluster sotto carico.
-
Per il test di carico iniziale, si consiglia di iniziare con il tipo di nodo
dax.r4.large, le prestazioni fisse a minor costo e il tipo di nodo ottimizzato per la memoria. -
Un cluster con tolleranza ai guasti richiede almeno tre nodi, distribuiti in tre zone di disponibilità. In questo caso, se una zona di disponibilità diventa non disponibile, il numero effettivo di zone di disponibilità viene ridotto di un terzo. Per il test di carico iniziale, si consiglia di iniziare con un cluster a due nodi che simula l'errore di una zona di disponibilità in un cluster a tre nodi.
-
Veicola il traffico prolungato (come stimato nel passaggio precedente) nel cluster di test per tutta la durata del test di carico.
-
Monitora le prestazioni del cluster durante il test di carico.
Idealmente, il profilo di traffico che veicoli durante il test di carico deve essere il più simile possibile al traffico reale dell'applicazione. Ciò include la distribuzione delle operazioni (ad esempio il 70% GetItem, il 25% Query e il 5% PutItem), il tasso di richiesta per ogni operazione, il numero di elementi a cui si accede per richiesta e la distribuzione delle dimensioni degli elementi. Per ottenere una percentuale di riscontri nella cache simile a quello previsto dalla tua applicazione, presta molta attenzione alla distribuzione delle chiavi nel traffico di test.
Nota
Fai attenzione quando testi il carico dei tipi di nodo T2 (dax.t2.small e dax.t2.medium). I tipi di nodi T2 forniscono CPUprestazioni sostenibili che variano nel tempo a seconda del saldo di credito del nodo. CPU Un DAX cluster in esecuzione su nodi T2 potrebbe sembrare che funzioni normalmente, ma se un nodo supera le prestazioni di base dell'istanza, il nodo sta spendendo il saldo del credito accumulato. CPU Quando il saldo di credito è basso, le prestazioni vengono gradualmente ridotte fino al livello di prestazioni di base.
Monitora il cluster DAX durante il test di carico per determinare se il tipo di nodo che stai utilizzando per il test di carico è il tipo di nodo corretto. Inoltre, durante un test di carico, devi monitorare il tasso di richiesta e la percentuale di riscontri nella cache per assicurarti che l'infrastruttura di test stia effettivamente veicolando la quantità di traffico desiderata.
È necessario prestare attenzione al consumo di byte di rete del tipo di istanza cluster selezionata. Il superamento della larghezza di banda di base disponibile per un'EC2istanza Amazon indica che il cluster potrebbe non sostenere il carico di lavoro dell'applicazione e deve essere ridimensionato.
Se il test di carico indica che la configurazione del cluster selezionata non è in grado di sostenere il carico di lavoro dell'applicazione, dovresti passare a un tipo di nodo più grande, soprattutto se riscontri un elevato CPU utilizzo sul nodo principale del cluster, tassi di eliminazione elevati o un utilizzo elevato della memoria cache. Se il tasso di hit è costantemente elevato e il rapporto tra il traffico di lettura e scrittura è alto, valuta l'aggiunta di più nodi al cluster. Fai riferimento a Ridimensionamento di un cluster DAX per ulteriori indicazioni su quando utilizzare un tipo di nodo più grande (dimensionamento verticale) o aggiungere più nodi (dimensionamento orizzontale).
È necessario ripetere il test di carico dopo aver apportato modifiche alla configurazione del cluster.
