Pilastro dell'eccellenza operativa di Amazon ElastiCache Well-Architected Lens - 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'eccellenza operativa di Amazon ElastiCache Well-Architected Lens

Il pilastro dell'eccellenza operativa si concentra sull'esecuzione e sul monitoraggio dei sistemi per fornire valore aziendale e migliorare continuamente processi e procedure. Gli argomenti chiave includono l'automazione delle modifiche, la risposta agli eventi e la definizione degli standard per gestire le operazioni quotidiane.

OE 1: Come comprendi e rispondi agli avvisi e agli eventi generati dal tuo cluster? ElastiCache

Introduzione a livello di domanda: quando gestisci ElastiCache i cluster, puoi facoltativamente ricevere notifiche e avvisi quando si verificano eventi specifici. ElastiCache, per impostazione predefinita, registra gli eventi relativi alle risorse, come il failover, la sostituzione dei nodi, le operazioni di scalabilità, la manutenzione programmata e altro ancora. Ogni evento include la data e l'ora, il nome e il tipo di origine e una descrizione.

Vantaggio della domanda: la capacità di comprendere e gestire i motivi alla base degli eventi che generano gli avvisi del cluster consente di operare in modo più efficace e di rispondere agli eventi in modo appropriato.

  • [Obbligatorio] Controlla gli eventi generati da ElastiCache sulla ElastiCache console (dopo aver selezionato la tua regione) o utilizzando il comando Amazon Command Line Interface (AWS CLI) describe-events e il. ElastiCache API Configura ElastiCache l'invio di notifiche per importanti eventi del cluster utilizzando Amazon Simple Notification Service (AmazonSNS). L'utilizzo di Amazon SNS con i tuoi cluster ti consente di intraprendere azioni programmatiche sugli eventi. ElastiCache

    • Esistono due grandi categorie di eventi: eventi attuali e programmati. L'elenco degli eventi correnti include: creazione ed eliminazione delle risorse, operazioni di scalabilità, failover, riavvio del nodo, istantanea creata, modifica dei parametri del cluster, rinnovo del certificato CA, eventi di errore (errore di provisioning del cluster - VPC o ENI -, errori di scalabilità - - ed errori di snapshot). ENI L'elenco degli eventi pianificati include: nodo programmato per la sostituzione durante la finestra di manutenzione e sostituzione del nodo riprogrammata.

    • Sebbene non sia necessario reagire immediatamente ad alcuni di questi eventi, è fondamentale esaminare tutti gli eventi di errore:

      • ElastiCache:AddCacheNodeFailed

      • ElastiCache:CacheClusterProvisioningFailed

      • ElastiCache:CacheClusterScalingFailed

      • ElastiCache:CacheNodesRebooted

      • ElastiCacheOSS: (solo Redis) SnapshotFailed

    • [Risorse]:

  • [Ideale] Per automatizzare le risposte agli eventi, sfrutta le funzionalità di AWS prodotti e servizi come SNS Lambda Functions. Segui le best practice apportando modifiche piccole, frequenti e reversibili, come codice per migliorare le tue operazioni nel tempo. È necessario utilizzare i CloudWatch parametri di Amazon per monitorare i cluster.

    [Risorse]: Monitor ElastiCache (RedisOSS) (modalità cluster disabilitata) legge gli endpoint di replica utilizzando AWS Lambda, Amazon Route 53 e Amazon SNS per un caso d'uso che utilizza Lambda e. SNS

OE 2: Quando e come ridimensionate i cluster esistenti? ElastiCache

Introduzione a livello di domanda: il corretto dimensionamento del ElastiCache cluster è un atto di bilanciamento che deve essere valutato ogni volta che vengono apportate modifiche ai tipi di carico di lavoro sottostanti. Il tuo obiettivo è operare con l'ambiente delle dimensioni giuste per il tuo carico di lavoro.

Vantaggio della domanda: l'eccessivo utilizzo delle risorse può comportare una latenza elevata e una riduzione complessiva delle prestazioni. Il sottoutilizzo, invece, può comportare un sovradimensionamento delle risorse a fronte di un'ottimizzazione dei costi non ottimale. Dimensionando correttamente gli ambienti, è possibile trovare un equilibrio tra efficienza delle prestazioni e ottimizzazione dei costi. Per rimediare all'utilizzo eccessivo o insufficiente delle risorse, è possibile scalare in due dimensioni. ElastiCache È possibile dimensionare verticalmente aumentando o diminuendo la capacità del nodo. Puoi anche dimensionare orizzontalmente aggiungendo e rimuovendo nodi.

OE 3: Come si gestiscono le ElastiCache risorse e la manutenzione del cluster up-to-date?

Introduzione a livello di domanda: quando si opera su larga scala, è essenziale essere in grado di individuare e identificare tutte le risorse. ElastiCache Quando si implementano nuove funzionalità applicative, è necessario creare una simmetria tra le versioni del cluster in tutti i tipi di ElastiCache ambiente: sviluppo, test e produzione. Gli attributi delle risorse consentono di separare gli ambienti per diversi obiettivi operativi, ad esempio quando si implementano nuove funzionalità e si abilitano nuovi meccanismi di sicurezza.

Vantaggio della domanda: la separazione degli ambienti di sviluppo, test e produzione è una best practice operativa. È inoltre consigliabile che ai cluster e ai nodi in tutti gli ambienti vengano applicate le patch software più recenti utilizzando i processi appresi e documentati. Lo sfruttamento delle ElastiCache funzionalità native consente al team di progettazione di concentrarsi sul raggiungimento degli obiettivi aziendali e non sulla ElastiCache manutenzione.

  • [Ottimale] Esegui l'ultima versione del motore disponibile e applica gli aggiornamenti self-service non appena sono disponibili. ElastiCache aggiorna automaticamente l'infrastruttura sottostante durante la finestra di manutenzione specificata del cluster. Tuttavia, i nodi in esecuzione nei cluster vengono aggiornati tramite aggiornamenti self-service. Questi aggiornamenti possono essere di due tipi: patch di sicurezza o aggiornamenti software secondari. Assicurati di comprendere la differenza tra i tipi di patch e quando vengono applicate.

    [Risorse]:

  • [Ottimale] Organizza ElastiCache le tue risorse utilizzando i tag. Usa i tag sui gruppi di replica e non sui singoli nodi. È possibile configurare i tag in modo che vengano visualizzati quando si eseguono query sulle risorse e utilizzare i tag per eseguire ricerche e applicare filtri. È consigliabile utilizzare i gruppi di risorse per creare e gestire facilmente le raccolte di risorse che condividono set di tag comuni.

    [Risorse]:

OE 4: Come gestite le connessioni dei clienti ai vostri ElastiCache cluster?

Introduzione a livello di domanda: quando si opera su larga scala, è necessario comprendere in che modo i clienti si connettono al ElastiCache cluster per gestire gli aspetti operativi dell'applicazione (come i tempi di risposta).

Vantaggio della domanda: la scelta del meccanismo di connessione più appropriato garantisce che l'applicazione non si disconnetta a causa di errori di connettività, come i timeout.

  • [Obbligatorio] Separa le operazioni di lettura da quelle di scrittura e connettiti ai nodi di replica per eseguire le operazioni di lettura. Tuttavia, tieni presente che quando separi le scritture dalle letture perderai la capacità di leggere una chiave subito dopo averla scritta a causa della natura asincrona della replica Redis. OSS Il WAIT comando può essere sfruttato per migliorare la sicurezza dei dati nel mondo reale e forzare le repliche a confermare le scritture prima di rispondere ai clienti, a un costo complessivo in termini di prestazioni. L'utilizzo dei nodi di replica per le operazioni di lettura può essere configurato nella libreria client ElastiCache (RedisOSS) utilizzando l'endpoint di ElastiCache lettura per la modalità cluster disattivata. Per abilitare la modalità cluster, utilizzate il comando ElastiCache (RedisOSS). READONLY Per molte delle librerie client ElastiCache (RedisOSS), ElastiCache (RedisOSS) READONLY è implementato di default o tramite un'impostazione di configurazione.

    [Risorse]:

  • [Obbligatorio] Usa il pool di connessioni. Stabilire una TCP connessione ha un costo in termini di CPU tempo sia sul lato client che sul lato server e il pooling consente di riutilizzare la connessione. TCP

    Per ridurre il sovraccarico della connessione, è necessario utilizzare il pool di connessioni. Con un pool di connessioni, l'applicazione può riutilizzare e rilasciare connessioni "secondo le necessità", senza il costo di stabilire la connessione. È possibile implementare il pool di connessioni tramite la libreria client ElastiCache (RedisOSS) (se supportata), con un Framework disponibile per l'ambiente applicativo, oppure crearlo da zero.

  • [Best practice] Assicurati che il timeout del socket del client sia impostato su almeno un secondo (rispetto al tipico valore predefinito "nessuno" in diversi client).

    • L'impostazione di un valore troppo basso può causare possibili timeout quando il carico del server è elevato. Se si imposta un valore troppo alto, l'applicazione può impiegare molto tempo per rilevare i problemi di connessione.

    • Controlla il volume delle nuove connessioni implementando il pool di connessioni nell'applicazione client. Ciò riduce la latenza e CPU l'utilizzo necessari per aprire e chiudere le connessioni ed eseguire una stretta di TLS mano se TLS è abilitata nel cluster.

    [Risorse]: Configura ElastiCache (Redis OSS) per una maggiore disponibilità

  • [Positivo] L'utilizzo delle pipeline (quando i casi d'uso lo consentono) può aumentare significativamente le prestazioni.

    • Con il pipelining riduci il Round-Trip Time (RTT) tra i client dell'applicazione e il cluster e le nuove richieste possono essere elaborate anche se il client non ha ancora letto le risposte precedenti.

    • Con le pipeline puoi inviare più comandi al server senza attendere le risposte e le conferme. L'aspetto negativo delle pipeline è che quando alla fine recuperi tutte le risposte in blocco, potrebbe essere restituito un errore che non è riscontrabile fino alla fine.

    • Implementa i metodi per riprovare le richieste quando viene restituito un errore che omette la richiesta non valida.

    [Risorse]: Redis pipelining

OE 5: Come si distribuiscono i ElastiCache componenti per un carico di lavoro?

Introduzione a livello di domanda: ElastiCache gli ambienti possono essere distribuiti manualmente tramite la AWS console o programmaticamente tramite toolkit, ecc. APIs CLI Le best practice dell'eccellenza operativa suggeriscono di automatizzare le implementazioni tramite il codice ogni volta che è possibile. Inoltre, ElastiCache i cluster possono essere isolati in base al carico di lavoro o combinati per ottimizzare i costi.

Vantaggio a livello di domanda: la scelta del meccanismo di implementazione più appropriato per i propri ElastiCache ambienti può migliorare Operation Excellence nel tempo. Ti consigliamo di eseguire operazioni sotto forma di codice ogni volta che è possibile per ridurre al minimo l'errore umano e aumentare la ripetibilità, la flessibilità e i tempi di risposta agli eventi.

Comprendendo i requisiti di isolamento del carico di lavoro, puoi scegliere di avere ElastiCache ambienti dedicati per carico di lavoro o combinare più carichi di lavoro in singoli cluster o combinazioni di essi. Comprendere i compromessi può aiutare a trovare un equilibrio tra eccellenza operativa e ottimizzazione dei costi.

  • [Obbligatorio] Comprendi le opzioni di implementazione disponibili e automatizza queste procedure quando possibile. ElastiCache Le possibili vie di automazione includono CloudFormationSDK, AWS CLI/e. APIs

    [Risorse]:

  • [Obbligatorio] Per tutti i carichi di lavoro, determina il livello di isolamento del cluster necessario.

    • [Best practice]: isolamento elevato, una mappatura 1:1 del carico di lavoro ai cluster. Consente un controllo granulare su accesso, dimensionamento, scalabilità e gestione delle ElastiCache risorse in base al carico di lavoro.

    • [Consigliato]: isolamento medio, M:1 isolato per scopo ma forse condiviso tra più carichi di lavoro (ad esempio un cluster dedicato alla memorizzazione nella cache dei carichi di lavoro e un altro dedicato alla messaggistica).

    • [Positivo]: isolamento basso, M:1 tutti gli scopi e completamente condiviso. Consigliato per carichi di lavoro in cui è accettabile l'accesso condiviso.

EO 6: come si pianificano e si contengono gli errori?

Introduzione a livello di domanda: l'eccellenza operativa include l'anticipazione dei guasti eseguendo regolarmente esercizi «pre-mortem» per identificare le potenziali fonti di guasto in modo che possano essere rimosse o mitigate. ElastiCache offre un failover API che consente di simulare eventi di guasto dei nodi a scopo di test.

Vantaggio della domanda: testando in anticipo gli scenari di errore, puoi scoprire in che modo influiscono sul tuo carico di lavoro. Ciò ti consente di testare in sicurezza le procedure di risposta e la loro efficacia, oltre a familiarizzare con l'esecuzione.

[Obbligatorio] Esegui regolarmente test di failover negli account di sviluppo/test. TestFailover

OE 7: Come si risolvono gli eventi del motore RedisOSS?

Introduzione a livello di domanda: l'eccellenza operativa richiede la capacità di esaminare le informazioni a livello di servizio e a livello di motore per analizzare lo stato e lo stato dei cluster. ElastiCache (RedisOSS) può emettere i log OSS del motore Redis sia su Amazon che su Amazon Kinesis Data CloudWatch Firehose.

Vantaggio a livello di domanda: l'abilitazione dei log OSS del motore Redis sui cluster ElastiCache (RedisOSS) fornisce informazioni sugli eventi che influiscono sullo stato e sulle prestazioni dei cluster. I log OSS del motore Redis forniscono dati direttamente dal motore Redis OSS che non sono disponibili tramite il meccanismo degli eventi. ElastiCache Attraverso un'attenta osservazione degli ElastiCache eventi (vedi precedente OE-1) e dei registri del OSS motore Redis, è possibile determinare l'ordine degli eventi durante la risoluzione dei problemi sia dal punto di vista del servizio che dal punto di vista del motore Redis. ElastiCache OSS

  • [Obbligatorio] Assicurati che la funzionalità di registrazione OSS del motore Redis sia abilitata, disponibile a partire da (Redis) 6.2 e versioni successive. ElastiCache OSS Questa operazione può essere eseguita durante la creazione del cluster o modificando il cluster dopo la creazione.

    • Determina se Amazon CloudWatch Logs o Amazon Kinesis Data Firehose è la destinazione appropriata per i log del motore Redis. OSS

    • Seleziona un log di destinazione appropriato all'interno di uno CloudWatch o di Kinesis Data Firehose per rendere permanenti i log. Se disponi di più cluster, considera un log di destinazione diverso per ogni cluster, in quanto ciò contribuisce a isolare i dati per la risoluzione dei problemi.

    [Risorse]:

  • [Migliore] Se utilizzi Amazon CloudWatch Logs, valuta la possibilità di sfruttare Amazon CloudWatch Logs Insights per interrogare il registro OSS del motore Redis per ottenere informazioni importanti.

    Ad esempio, crea una query sul gruppo CloudWatch Log che contiene i log del OSS motore Redis che restituiranno eventi contrassegnati da '', ad LogLevel esempio: WARNING

    fields @timestamp, LogLevel, Message | sort @timestamp desc | filter LogLevel = "WARNING"

    [Risorse]: analisi dei dati di registro con Logs Insights CloudWatch