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

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] Per i carichi di lavoro ElastiCache (RedisOSS), rinomina i 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 (RedisOSS) che eseguono il motore 6.x 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 oppure CLI associando i gruppi di utenti a un cluster (Redis). ElastiCache OSS In Redis OSS 6, quando RBAC è abilitato, possiamo usare «- @dangerous" e non consentirà comandi costosi comeKEYS, MONITORSORT, ecc. per quell'utente.

    • Per la versione 5.x del motore, rinomina i comandi utilizzando il rename-commands parametro nel gruppo di parametri del cluster ElastiCache (RedisOSS).

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

    • Per i carichi di lavoro ElastiCache (RedisOSS), scopri di più sulle tue query analizzando lo Slow Log. Ad esempio, puoi utilizzare il seguente comando redis-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 (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.

    • Per i carichi di lavoro ElastiCache (RedisOSS), 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 (RedisOSS) 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 la modalità cluster ElastiCache (RedisOSS) abilitata per migliorare la scalabilità.

    • ElastiCache I cluster (RedisOSS) (modalità cluster abilitata) supportano operazioni di scalabilità online (out/in e up/down) per aiutare a distribuire i dati in modo dinamico tra gli 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 nel cluster (Redis) (abilitato in modalità cluster). ElastiCache OSS 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 OSS dati Redis multidimensionali come elenchi, stream, set, ecc. Queste strutture di dati sono archiviate in singole OSS chiavi Redis, 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. Per i carichi di lavoro ElastiCache (RedisOSS), puoi rilevare i tasti di scelta rapida utilizzando redis-cli --hotkeys se è in atto una politica di LFU massima memoria.

    • 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 (il OSS nodo Redis stesso non fornirà questa funzionalità) e mantenga un elenco di nomi di chiavi da cui leggere, oltre al nome della chiave originale.

    • EElastiCache(RedisOSS) la versione 6 supporta la memorizzazione nella cache lato client assistita da 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 CPU utilizzo 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 ElastiCache (RedisOSS) e non includono la rete e il tempo di INFO I/O. Questo è solo il tempo impiegato da ElastiCache (Redis) per elaborare le operazioni. OSS

    [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 (RedisOSS) e ElastiCache (Memcached) 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 (RedisOSS) 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 del cluster maxmemory-policy on the ElastiCache (RedisOSS).

    • La politica predefinita volatile-lru libera memoria eliminando le chiavi con un tempo di scadenza (valore) impostato. TTL Le politiche utilizzate meno frequentemente (LFU) e quelle utilizzate meno di recente (LRU) rimuovono le chiavi in base all'utilizzo.

    • Per i carichi di lavoro Memcached, esiste una LRU politica predefinita che controlla gli sfratti su ciascun 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.

    • Per i carichi di lavoro ElastiCache (RedisOSS), 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 i carichi di lavoro ElastiCache (RedisOSS) 6.x, 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 ElastiCache (RedisOSS) 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 ElastiCache (RedisOSS) 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]:

  • I comandi [Best] ElastiCache (RedisOSS) 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 (RedisOSS), un grande volume di operazioni ad alta complessità temporale si tradurrà in prestazioni inferiori e potenziali timeout operativi.

    [Risorse]:

  • [Ideale] Utilizzalo APIs per ottenere GUI visibilità 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 (RedisOSS) 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.

  • [Obbligatorio] Amazon ElastiCache (RedisOSS) utilizza la versione 6.0 o successiva del motore, gruppo di parametri correttamente configurato e SLOWLOG registrazione abilitata sul cluster.

    • I parametri richiesti sono disponibili solo quando la compatibilità della versione del motore è impostata sulla versione Redis OSS 6.0 o successiva.

    • SLOWLOGla registrazione si verifica quando il tempo di esecuzione di un comando sul server impiega più tempo di un 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.

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

    • Determina se il nostro JSON TEXT formato semplice si adatta meglio alle tue esigenze.

    • Fornisci IAM le autorizzazioni 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 OSS motore Redis 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 OSS memoria Redis 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 redis-cli tramite il comando, valuta la SLOWLOG possibilità di aumentare questo valore. Ciò consente a più comandi di rimanere nella memoria Redis. OSS

      Se stai inviando i SLOWLOG dati 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 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 ridimensionamento OSS automatico di Redis, 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 (RedisOSS) Auto Scaling monitora continuamente l'utilizzo di /Memory per assicurarsi che CPU il cluster funzioni ai livelli di prestazioni desiderati.

  • [Obbligatorio] Quando si avvia un cluster per (Redis): ElastiCache OSS

    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]: