Pilastro dell'efficienza delle prestazioni delle lenti Amazon ElastiCache Well-Architected - Amazon ElastiCache
PE 1: Come monitorate le prestazioni del vostro ElastiCache cluster Amazon?PE 2: Come state distribuendo il lavoro tra i ElastiCache nodi del cluster?EP 3: come si monitora e si segnala l'efficacia e le prestazioni della cache per i carichi di lavoro con memorizzazione nella cache? EP 4: in che modo il carico di lavoro ottimizza l'uso delle risorse e delle connessioni di rete?EP 5: come si gestisce l'eliminazione e/o l'espulsione delle chiavi?PE 6: In che modo modellate e interagite con i dati ElastiCache? PE 7: Come si registrano i comandi a esecuzione lenta nel ElastiCache cluster Amazon?PE8: In che modo l'Auto Scaling aiuta ad aumentare le prestazioni del ElastiCache cluster?

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à.

Pilastro dell'efficienza delle prestazioni delle lenti Amazon ElastiCache Well-Architected

Il pilastro dell'efficienza delle prestazioni si concentra sull'uso efficiente delle risorse IT e di calcolo. Gli argomenti chiave includono la selezione delle dimensioni e dei tipi corretti per le risorse in base ai requisiti del carico di lavoro, il monitoraggio delle prestazioni e il processo per prendere decisioni informate e mantenere l'efficienza man mano che le esigenze aziendali cambiano.

PE 1: Come monitorate le prestazioni del vostro ElastiCache cluster Amazon?

Introduzione della domanda: comprendendo le metriche di monitoraggio esistenti è possibile determinare l'utilizzo corrente. Un monitoraggio adeguato può aiutare a individuare i potenziali ostacoli che influiscono sulle prestazioni del cluster.

Vantaggio della domanda: la comprensione delle metriche associate al cluster può aiutare nella definizione delle tecniche di ottimizzazione volte a conseguire la riduzione della latenza e l'aumento della velocità di trasmissione effettiva.

  • [Obbligatorio] Test delle prestazioni di base utilizzando un sottoinsieme del carico di lavoro.

    • È necessario monitorare le prestazioni del carico di lavoro effettivo utilizzando meccanismi come i test di carico.

    • Monitora le CloudWatch metriche durante l'esecuzione di questi test per comprendere le metriche disponibili e stabilire una base di riferimento delle prestazioni.

  • [Ideale] ElastiCache Per i carichi di lavoro Valkey e Redis OSS, rinomina comandi computazionalmente costosi, ad esempio per limitare la capacità degli utenti di eseguire comandi di blocco sui cluster di produzione. KEYS

    • ElastiCache i carichi di lavoro che eseguono il motore 6.x per Redis OSS possono sfruttare il controllo degli accessi basato sui ruoli per limitare determinati comandi. L'accesso ai comandi può essere controllato creando utenti e gruppi di utenti con la AWS console o la CLI e associando i gruppi di utenti a un cluster. In Redis OSS 6, quando RBAC è abilitato, possiamo usare «- @dangerous" e non consentirà comandi costosi come KEYS, MONITOR, SORT, ecc. per quell'utente.

    • Per la versione 5.x del motore, rinomina i comandi utilizzando il parametro nel gruppo di parametri del clusterrename-commands.

  • [Consigliato] Analizza le query lente ed esamina le tecniche di ottimizzazione.

    • ElastiCache Per i carichi di lavoro Valkey e Redis OSS, scopri di più sulle tue query analizzando lo Slow Log. Ad esempio, puoi utilizzare il seguente comando valkey-cli slowlog get 10 per mostrare gli ultimi 10 comandi che hanno superato la soglia di latenza (10 secondi per impostazione predefinita).

    • Alcune query possono essere eseguite in modo più efficiente utilizzando strutture di dati complesse ElastiCache per Valkey e Redis OSS. Ad esempio, per le ricerche con intervalli di numeri, è possibile implementare nell'applicazione semplici indici numerici con i set ordinati. La gestione di questi indici può ridurre le scansioni eseguite sui set e restituire i dati con prestazioni migliori.

    • ElastiCache Per i carichi di lavoro Valkey e Redis OSS, redis-benchmark fornisce un'interfaccia semplice per testare le prestazioni di diversi comandi utilizzando input definiti dall'utente come il numero di client e la dimensione dei dati.

    • Poiché Memcached supporta solo semplici comandi a livello di chiave, valuta la possibilità di creare altre chiavi come indici per evitare l'iterazione dello spazio delle chiavi per rispondere alle query dei client.

  • [Risorse]:

PE 2: Come state distribuendo il lavoro tra i ElastiCache nodi del cluster?

Introduzione a livello di domanda: il modo in cui l'applicazione si connette ElastiCache ai nodi Amazon può influire sulle prestazioni e sulla scalabilità del cluster.

Vantaggio della domanda: l'uso corretto dei nodi disponibili nel cluster garantisce la distribuzione del lavoro tra le risorse disponibili. Le seguenti tecniche consentono anche di evitare risorse inutilizzate.

  • [Obbligatorio] Consenti ai client di connettersi all'endpoint corretto. ElastiCache

    • ElastiCache per Valkey e Redis OSS implementa diversi endpoint in base alla modalità cluster in uso. Se la modalità cluster è abilitata, ElastiCache fornirà un endpoint di configurazione. Per la modalità cluster disattivata, ElastiCache fornisce un endpoint primario, in genere utilizzato per le scritture, e un endpoint di lettura per bilanciare le letture tra le repliche. L'implementazione corretta di questi endpoint si traduce in prestazioni migliori e operazioni di dimensionamento più semplici. Evita di connetterti ai singoli endpoint dei nodi a meno che non vi sia un requisito specifico in tal senso.

    • Per i cluster Memcached multinodo, fornisce un endpoint di configurazione che abilita l'Auto Discovery ElastiCache . Ti consigliamo di utilizzare un algoritmo di hash per distribuire il lavoro in modo uniforme tra i nodi di cache. Molte librerie client Memcached implementano l'hash in modo coerente. Consulta la documentazione della libreria che utilizzi per verificare se supporta l'hashing coerente e ottenere informazioni su come implementarlo. Ulteriori informazioni sull'implementazione di queste funzionalità sono disponibili qui.

  • [Migliore] Sfrutta i cluster abilitati alla modalità cluster Valkey e Redis OSS ElastiCache per migliorare la scalabilità.

    • ElastiCache per Valkey e Redis OSS (modalità cluster abilitata) i cluster supportano operazioni di scalabilità online () per aiutare a distribuire i dati in modo dinamico tra gli out/in and up/down shard. L'utilizzo dell'endpoint di configurazione garantisce che i client che supportano il cluster possano adattarsi ai cambiamenti nella topologia del cluster.

    • Puoi anche ribilanciare il cluster spostando gli hashslot tra gli shard disponibili nei cluster ElastiCache for Valkey e Redis OSS (modalità cluster abilitata). In tal modo il lavoro viene distribuito in modo più efficiente tra le partizioni disponibili.

  • [Consigliato] Implementa una strategia per identificare e correggere le chiavi hot nel tuo carico di lavoro.

    • Considerate l'impatto delle strutture di dati multidimensionali di Valkey o Redis OSS come elenchi, stream, set, ecc. Queste strutture di dati sono archiviate in singole chiavi, che risiedono su un singolo nodo. Una chiave multidimensionale molto grande può utilizzare più memoria e capacità di rete rispetto ad altri tipi di dati e causare un uso sproporzionato del nodo. Se possibile, progetta il tuo carico di lavoro in modo da distribuire l'accesso ai dati tra molte chiavi discrete.

    • Le chiavi hot del carico di lavoro possono influire sulle prestazioni del nodo in uso. ElastiCache Per i carichi di lavoro Valkey e Redis OSS, è possibile rilevare i tasti di scelta rapida utilizzando valkey-cli --hotkeys se è in atto una politica di memoria massima LFU.

    • Prendi in considerazione la replica delle chiavi hot su più nodi per distribuire l'accesso in modo più uniforme. Questo approccio richiede che il client scriva su più nodi primari (lo stesso nodo Valkey o Redis OSS non fornirà questa funzionalità) e mantenga un elenco di nomi di chiave da cui leggere, oltre al nome della chiave originale.

    • ElastiCache il motore 7.2 per Valkey e versioni successive e la ElastiCache versione 6 per Redis OSS e versioni successive supportano tutti la memorizzazione nella cache lato client assistita dal server. Ciò consente alle applicazioni di attendere le modifiche a una chiave prima di effettuare chiamate di rete a. ElastiCache

  • [Risorse]:

EP 3: come si monitora e si segnala l'efficacia e le prestazioni della cache per i carichi di lavoro con memorizzazione nella cache?

Introduzione a livello di domanda: la memorizzazione nella cache è un carico di lavoro comune ElastiCache ed è importante comprendere come gestire l'efficacia e le prestazioni della cache.

Vantaggio della domanda: l'applicazione potrebbe mostrare segni di rallentamento delle prestazioni. La capacità di utilizzare metriche specifiche della cache per decidere come aumentare le prestazioni delle app è fondamentale per il carico di lavoro della cache.

  • [Obbligatorio] Misura e monitora nel tempo il rapporto dei riscontri della cache. L'efficienza della cache è determinata dal "rapporto di riscontri della cache". Il rapporto di riscontri della cache è definito dal totale dei riscontri delle chiavi diviso per il totale dei riscontri e dei mancati riscontri. Più il rapporto è vicino a 1, più efficace è la cache. Un basso rapporto di riscontri della cache è causato dal volume di mancati riscontri della cache. I mancati riscontri della cache si verificano quando la chiave richiesta non viene trovata nella cache. Una chiave non è nella cache perché è stata rimossa o eliminata, è scaduta o non è mai esistita. Determina il motivo per cui le chiavi non sono nella cache e sviluppa le strategie appropriate per averle nella cache.

    [Risorse]:

  • [Obbligatorio] Misura e raccogli le prestazioni della cache delle applicazioni insieme ai valori di latenza e utilizzo della CPU per capire se è necessario apportare modifiche ai componenti dell'applicazione o ad altri componenti dell'applicazione. time-to-live ElastiCache fornisce un set di CloudWatch metriche per le latenze aggregate per ogni struttura di dati. Queste metriche di latenza vengono calcolate utilizzando la statistica commandstats del comando INFO e non includono la rete e il tempo di I/O. Questo è solo il tempo impiegato per elaborare le operazioni. ElastiCache

    [Risorse]:

  • [Best practice] Scegli la strategia di memorizzazione nella cache giusta per le tue esigenze. Un basso rapporto di riscontri della cache è causato dal volume di mancati riscontri della cache. Se il carico di lavoro è progettato per avere un volume ridotto di mancati riscontri della cache (come la comunicazione in tempo reale), è consigliabile esaminare le strategie di memorizzazione nella cache e applicare le risoluzioni più appropriate per il carico di lavoro, ad esempio la strumentazione delle query per misurare la memoria e le prestazioni. Le strategie effettive utilizzate per implementare il popolamento e la gestione della cache dipende dai dati del client che desideri memorizzare nella cache e dai modelli di accesso a tali dati. Ad esempio, è improbabile che utilizzi in un'applicazione di streaming la stessa strategia per i suggerimenti personalizzati e per le notizie più interessanti.

    [Risorse]:

EP 4: in che modo il carico di lavoro ottimizza l'uso delle risorse e delle connessioni di rete?

Introduzione a livello di domanda: ElastiCache per Valkey, Memcached e Redis OSS sono supportati da molti client applicativi e le implementazioni possono variare. È necessario comprendere la gestione della rete e delle connessioni in uso per analizzare il potenziale impatto sulle prestazioni.

Vantaggio della domanda: l'uso corretto delle risorse di rete può migliorare l'efficienza delle prestazioni del cluster. I seguenti suggerimenti possono ridurre le richieste di rete e migliorare la latenza e la velocità di trasmissione effettiva del cluster.

  • [Obbligatorio] Gestisci in modo proattivo le connessioni al tuo cluster. ElastiCache

    • Il pool di connessioni dell'applicazione riduce la quantità di sovraccarico sul cluster creato dall'apertura e dalla chiusura delle connessioni. Monitora il comportamento della connessione in Amazon CloudWatch utilizzando CurrConnections eNewConnections.

    • Evita di perdere le connessioni client chiudendole correttamente, quando opportuno. Le strategie di gestione delle connessioni includono la corretta chiusura delle connessioni non in uso e l'impostazione del timeout delle connessioni.

    • Per i carichi di lavoro Memcached, esiste una quantità di memoria configurabile riservata alla gestione delle connessioni chiamate, memcached_connections_overhead.

  • [Consigliato] Comprimi gli oggetti di grandi dimensioni per ridurre la memoria e migliorare la velocità di trasmissione effettiva di rete.

    • La compressione dei dati può ridurre la velocità di trasmissione effettiva di rete richiesta (Gbps), ma aumenta la quantità di lavoro dell'applicazione per comprimere e decomprimere i dati.

    • La compressione riduce anche la quantità di memoria consumata dalle chiavi.

    • In base alle esigenze della tua applicazione, considera i compromessi tra rapporto di compressione e velocità di compressione.

  • [Risorse]:

EP 5: come si gestisce l'eliminazione e/o l'espulsione delle chiavi?

Introduzione a livello di domanda: i carichi di lavoro hanno requisiti e comportamenti previsti diversi quando un nodo del cluster si avvicina ai limiti di consumo di memoria. ElastiCache ha politiche diverse per la gestione di queste situazioni.

Vantaggio della domanda: la corretta gestione della memoria disponibile e la comprensione delle policy di espulsione contribuiscono a garantire la consapevolezza del comportamento del cluster quando i limiti di memoria delle istanze vengono superati.

  • [Obbligatorio] Strumenta l'accesso ai dati per valutare quale policy applicare. Identifica una policy per la memoria massima appropriata per controllare se e come vengono eseguite le espulsioni sul cluster.

    • L'espulsione si verifica quando viene consumata la memoria massima del cluster e c'è una policy che consente l'operazione. Il comportamento del cluster in questa situazione dipende dalla policy di espulsione specificata. Questa politica può essere gestita utilizzando il gruppo di parametri maxmemory-policy on the cluster.

    • La policy predefinita volatile-lru libera la memoria espellendo le chiavi con un tempo di scadenza impostato (valore TTL). Le policy per l'utilizzo meno frequente (LFU) e meno recente (LRU) rimuovono le chiavi in base all'utilizzo.

    • Per i carichi di lavoro Memcached, esiste una policy predefinita per LRU che controlla le espulsioni su ogni nodo. Il numero di sfratti sul tuo ElastiCache cluster Amazon può essere monitorato utilizzando la metrica Sfratti su Amazon. CloudWatch

  • [Best practice] Standardizza il comportamento di eliminazione per controllare l'impatto sulle prestazioni del cluster ed evitare imprevisti colli di bottiglia delle prestazioni.

    • ElastiCache Per i carichi di lavoro Valkey e Redis OSS, quando si rimuovono esplicitamente le chiavi dal cluster, UNLINK è come: rimuove le chiavi specificate. DEL Tuttavia, il comando esegue il recupero della memoria effettiva in un thread diverso, quindi non si blocca, contrariamente a DEL. La rimozione effettiva avviene successivamente in modo asincrono.

    • Per la ElastiCache versione 6.x per i carichi di lavoro Redis OSS, il comportamento del DEL comando può essere modificato nel gruppo di parametri utilizzando il parametro. lazyfree-lazy-user-del

  • [Risorse]:

PE 6: In che modo modellate e interagite con i dati ElastiCache?

Introduzione a livello di domanda: ElastiCache dipende in larga misura dall'applicazione dalle strutture di dati e dal modello di dati utilizzati, ma deve anche considerare l'archivio dati sottostante (se presente). Comprendi le strutture di dati disponibili e assicurati di utilizzare le strutture di dati più appropriate per le tue esigenze.

Vantaggio a livello di domanda: la modellazione dei dati ElastiCache ha diversi livelli, tra cui il caso d'uso dell'applicazione, i tipi di dati e le relazioni tra gli elementi di dati. Inoltre, ogni tipo di dati e comando ha le proprie caratteristiche prestazionali ben documentate.

  • [Best practice] Una best practice consiste nel ridurre la sovrascrittura involontaria dei dati. Utilizza una convenzione di denominazione che riduca al minimo la sovrapposizione dei nomi delle chiavi. La convenzione di denominazione delle strutture di dati utilizza il metodo gerarchico APPNAME:CONTEXT:ID, ad esempio ORDER-APP:CUSTOMER:123.

    [Risorse]:

  • [ElastiCache Ideale] perché i comandi OSS di Valkey e Redis hanno una complessità temporale definita dalla notazione Big O. La complessità temporale di un comando è la rappresentazione algoritmica/matematica del suo impatto. Quando si introduce un nuovo tipo di dati nell'applicazione, è necessario esaminare attentamente la complessità temporale dei relativi comandi. I comandi con la complessità temporale O(1) sono costanti nel tempo e non dipendono dalla dimensione dell'input, mentre i comandi con la complessità temporale O(N) sono lineari nel tempo e sono soggetti alla dimensione dell'input. Grazie al design a thread singolo di ElastiCache Valkey e Redis OSS, un grande volume di operazioni ad alta complessità temporale comporterà una riduzione delle prestazioni e potenziali timeout operativi.

    [Risorse]:

  • [Ideale] Utilizzalo APIs per ottenere visibilità tramite interfaccia grafica sul modello di dati nel cluster.

    [Risorse]:

PE 7: Come si registrano i comandi a esecuzione lenta nel ElastiCache cluster Amazon?

Introduzione della domanda: vantaggi dell'ottimizzazione delle prestazioni attraverso l'acquisizione, l'aggregazione e la notifica di comandi di lunga durata. Comprendendo il tempo necessario per l'esecuzione dei comandi, è possibile determinare quali comandi determinano prestazioni scadenti e quali comandi che impediscono al motore di funzionare in modo ottimale. ElastiCache ha anche la capacità di inoltrare queste informazioni ad Amazon CloudWatch o Amazon Kinesis Data Firehose.

Vantaggio della domanda: l'accesso a una posizione permanente dedicata e l'invio di eventi di notifica per i comandi lenti possono aiutare a eseguire un'analisi dettagliata delle prestazioni e possono essere utilizzati per attivare eventi automatizzati.

  • [Richiesto] ElastiCache Esecuzione di un motore Valkey 7.2 o versione successiva o di un motore Redis OSS versione 6.0 o successiva, gruppo di parametri configurato correttamente e registrazione SLOWLOG abilitata sul cluster.

    • I parametri richiesti sono disponibili solo quando la compatibilità della versione del motore è impostata su Valkey 7.2 e versioni successive o Redis OSS versione 6.0 o successiva.

    • La registrazione SLOWLOG si verifica quando l'esecuzione di un comando sul server richiede più tempo del valore specificato. Il comportamento del cluster dipende dai parametri slowlog-log-slower-than e slowlog-max-len del gruppo di parametri associato.

    • Le modifiche diventano effettive immediatamente.

  • [Migliore] Sfrutta le nostre funzionalità di CloudWatch Kinesis Data Firehose.

    • Utilizza le funzionalità di filtro e allarme di CloudWatch CloudWatch Logs Insights e Amazon Simple Notification Services per monitorare le prestazioni e notificare gli eventi.

    • Usa le funzionalità di streaming di Kinesis Data Firehose per archiviare i log SLOWLOG in uno spazio di archiviazione permanente o per attivare l'ottimizzazione automatica dei parametri del cluster.

    • Determina se si adatta meglio alle tue esigenze il formato JSON o TEXT normale.

    • Fornisci le autorizzazioni IAM per la pubblicazione su CloudWatch o su Kinesis Data Firehose.

  • [Consigliato] Configura slowlog-log-slower-than con un valore diverso da quello predefinito.

    • Questo parametro determina per quanto tempo un comando può essere eseguito all'interno del motore Valkey o Redis OSS prima che venga registrato come comando a esecuzione lenta. Il valore predefinito è 10.000 microsecondi (10 millisecondi). Il valore predefinito potrebbe essere troppo alto per alcuni carichi di lavoro.

    • Determina il valore più appropriato per il tuo carico di lavoro in base alle esigenze delle applicazioni e ai risultati dei test, tuttavia considera che un valore troppo basso può generare un volume eccessivo di dati.

  • [Consigliato] Lascia slowlog-max-len impostato sul valore predefinito.

    • Questo parametro determina il limite superiore per il numero di comandi a esecuzione lenta acquisiti nella memoria Valkey o Redis OSS in un dato momento. Un valore pari a 0 disabilita l'acquisizione. Più alto è il valore, più elementi verranno archiviati in memoria, riducendo la possibilità che informazioni importanti vengano espulse prima di essere esaminate. Il valore predefinito è 128.

    • Il valore predefinito è appropriato per la maggior parte dei carichi di lavoro. Se è necessario analizzare i dati in una finestra temporale estesa da valkey-cli tramite il comando SLOWLOG, è possibile aumentare questo valore. Ciò consente a più comandi di rimanere nella memoria Valkey o Redis OSS.

      Se si inviano dati SLOWLOG a CloudWatch Logs o Kinesis Data Firehose, i dati verranno mantenuti e potranno essere analizzati all'esterno del sistema, riducendo ElastiCache la necessità di archiviare un gran numero di comandi a esecuzione lenta nella memoria Valkey o Redis OSS.

  • [Risorse]:

PE8: In che modo l'Auto Scaling aiuta ad aumentare le prestazioni del ElastiCache cluster?

Introduzione a livello di domanda: implementando la funzionalità di scalabilità automatica Valkey o Redis OSS, ElastiCache i componenti possono adattarsi nel tempo per aumentare o diminuire automaticamente gli shard o le repliche desiderati. Questa operazione può essere eseguita implementando il monitoraggio degli obiettivi o la policy di dimensionamento pianificata.

Vantaggio a livello di domanda: la comprensione e la pianificazione dei picchi del carico di lavoro possono garantire prestazioni di caching migliorate e continuità aziendale. ElastiCache Auto Scaling monitora continuamente l'utilizzo della CPU/memoria per assicurarsi che il cluster funzioni ai livelli di prestazioni desiderati.

  • [Obbligatorio] Quando si avvia un cluster per Valkey o Redis OSS: ElastiCache

    1. Assicurati che la modalità cluster sia abilitata

    2. Assicurati che l'istanza faccia parte della famiglia dei tipi e delle dimensioni che supportano il dimensionamento automatico

    3. Assicurati che il cluster non sia in esecuzione in datastore globali, Outpost o zone locali

    [Risorse]:

  • [Best practice] Determina se il tuo carico di lavoro è pesante in lettura o in scrittura quando definisci la policy di dimensionamento. Per le prestazioni ottimali, utilizza una sola metrica di monitoraggio. Ti consigliamo di evitare l'uso di più policy per una dimensione perché le policy di dimensionamento automatico si dimensionano quando l'obiettivo viene raggiunto, ma si ridimensionano solo quando tutte le policy di monitoraggio degli obiettivi sono pronte per farlo.

    [Risorse]:

  • [Best practice] Il monitoraggio delle prestazioni nel tempo può aiutarti a rilevare i cambiamenti del carico di lavoro che rimarrebbero inosservati se monitorati solo in un determinato momento. È possibile analizzare le CloudWatch metriche corrispondenti per l'utilizzo del cluster in un periodo di quattro settimane per determinare la soglia del valore target. Se non sei ancora certo del valore da scegliere, ti consigliamo di iniziare con il valore predefinito minimo supportato della metrica.

    [Risorse]:

  • [Consigliato] Consigliamo di testare l'applicazione con i carichi di lavoro minimi e massimi previsti, per identificare il numero esatto di partizioni/repliche necessarie al cluster per sviluppare le policy di dimensionamento e contenere i problemi di disponibilità.

    [Risorse]: