Pilastro dell'affidabilità delle ElastiCache lenti Amazon Well-Architected - Amazon ElastiCache

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'affidabilità delle ElastiCache lenti Amazon Well-Architected

Il pilastro dell'affidabilità si concentra sui carichi di lavoro che svolgono le funzioni previste e su come recuperare rapidamente in caso di mancato soddisfacimento delle richieste. Gli argomenti chiave includono la progettazione di sistemi distribuiti, la pianificazione del ripristino e l'adattamento ai requisiti in evoluzione.

REL1: In che modo supportate le implementazioni di architetture ad alta disponibilità (HA)?

Introduzione a livello di domanda: comprendere l'architettura ad alta disponibilità di Amazon ti ElastiCache consentirà di operare in uno stato resiliente durante gli eventi di disponibilità.

Vantaggio a livello di domanda: l'architettura dei ElastiCache cluster in modo che siano resilienti ai guasti garantisce una maggiore disponibilità per le distribuzioni. ElastiCache

  • [Obbligatorio] Determina il livello di affidabilità richiesto per il tuo cluster. ElastiCache Carichi di lavoro diversi hanno standard di resilienza diversi, da quelli totalmente effimeri a quelli mission critical. Definisci le esigenze per ogni tipo di ambiente in cui gestisci, ad esempio, sviluppo, test e produzione.

    Motore di memorizzazione nella cache: ElastiCache (Memcached) vs ElastiCache (Redis) OSS

    1. ElastiCache (Memcached) non fornisce alcun meccanismo di replica e viene utilizzato principalmente per carichi di lavoro temporanei.

    2. ElastiCache (Redis) offre le funzionalità HA descritte di seguito OSS

  • [Ideale] Per carichi di lavoro che richiedono HA, usa ElastiCache (RedisOSS) in modalità cluster con un minimo di due repliche per shard, anche per carichi di lavoro con requisiti di throughput ridotti che richiedono solo uno shard.

    1. Con la modalità cluster abilitata, multi-AZ viene impostato automaticamente.

      Multi-AZ riduce al minimo i tempi di inattività eseguendo failover automatici dal nodo primario alle repliche, in caso di manutenzione pianificata o non pianificata, mitigando i guasti delle zone di disponibilità.

    2. Per i carichi di lavoro suddivisi, un minimo di tre shard offre un ripristino più rapido durante gli eventi di failover, poiché il Valkey o il Redis OSS Cluster Protocol richiedono la disponibilità della maggior parte dei nodi primari per raggiungere il quorum.

    3. Configura due o più repliche per la disponibilità.

      La presenza di due repliche offre una migliore scalabilità di lettura e anche la disponibilità di lettura in scenari in cui una replica è in fase di manutenzione.

    4. Usa i tipi di nodi basati su Graviton2 (nodi predefiniti nella maggior parte delle regioni).

      ElastiCache (RedisOSS) ha aggiunto prestazioni ottimizzate su questi nodi. Di conseguenza, si ottengono migliori prestazioni di replica e sincronizzazione, con conseguente maggiore disponibilità complessiva.

    5. Monitoraggio e dimensioni corrette per far fronte ai picchi di traffico previsti: in caso di carico intenso, il motore ElastiCache (RedisOSS) potrebbe non rispondere, con ripercussioni sulla disponibilità. BytesUsedForCachee DatabaseMemoryUsagePercentage sono buoni indicatori dell'utilizzo della memoria, mentre ReplicationLag sono un indicatore dello stato della replica in base alla velocità di scrittura. Puoi utilizzare queste metriche per attivare il dimensionamento dei cluster.

    6. Garantite la resilienza lato client eseguendo test con il failover API prima di un evento di failover di produzione.

    [Risorse]:

REL2: In che modo state raggiungendo i Recovery Point Objectives (RPOs)? ElastiCache

Introduzione a livello di domanda: Comprendi il carico di lavoro RPO per prendere decisioni informate sulle strategie di ElastiCache backup e ripristino.

Vantaggio a livello di domanda: disporre di una RPO strategia in atto può migliorare la continuità aziendale in caso di scenari di disaster recovery. La progettazione delle politiche di backup e ripristino può aiutarti a raggiungere gli obiettivi dei punti di ripristino (RPO) per i tuoi dati. ElastiCache ElastiCache (RedisOSS) offre funzionalità di snapshot archiviate in Amazon S3, insieme a una politica di conservazione configurabile. Questi snapshot vengono acquisiti durante la finestra di backup definita e gestiti automaticamente dal servizio. Se il carico di lavoro richiede una maggiore granularità del backup, hai la possibilità di creare fino a 20 backup manuali al giorno. I backup creati manualmente non hanno una policy di conservazione del servizio e possono essere conservati a tempo indeterminato.

  • [Obbligatorio] Comprendi e documenta le RPO tue implementazioni. ElastiCache

    • Tieni presente che Memcached non offre processi di backup.

    • Esamina le funzionalità delle funzionalità di ElastiCache Backup e ripristino.

  • [Best practice] Predisponi di una procedura di comunicazione per il backup del cluster.

    • Avvia i backup manuali in base alle necessità.

    • Esamina le policy di conservazione per i backup automatici.

    • Tieni presente che i backup manuali vengono conservati a tempo indeterminato.

    • Pianifica i backup automatici nei periodi di basso utilizzo.

    • Esegui operazioni di backup su repliche di lettura per ridurre al minimo l'impatto sulle prestazioni del cluster.

  • [Buono] Sfrutta la funzionalità di backup pianificato ElastiCache per eseguire regolarmente il backup dei dati durante una finestra definita.

    • Esegui periodicamente il test del ripristino dei tuoi backup.

  • [Risorse]:

REL3: In che modo supportate i requisiti di disaster recovery (DR)?

Introduzione a livello di domanda: il disaster recovery è un aspetto importante di qualsiasi pianificazione del carico di lavoro. ElastiCache (RedisOSS) offre diverse opzioni per implementare il disaster recovery in base ai requisiti di resilienza del carico di lavoro. Con Amazon ElastiCache Global Datastore, puoi scrivere sul tuo cluster ElastiCache (RedisOSS) in una regione e avere i dati disponibili per essere letti da altri due cluster di replica interregionali, abilitando così letture a bassa latenza e disaster recovery tra le regioni.

Vantaggio della domanda: la comprensione e la pianificazione di una varietà di scenari di emergenza possono garantire la continuità aziendale. Le strategie di ripristino di emergenza devono essere bilanciate rispetto ai costi, all'impatto sulle prestazioni e alla potenziale perdita di dati.

  • [Obbligatorio] Sviluppa e documenta strategie di DR per tutti i componenti in base ai requisiti del carico di lavoro. ElastiCache ElastiCache è unico in quanto alcuni casi d'uso sono completamente effimeri e non richiedono alcuna strategia di DR, mentre altri si collocano all'estremità opposta e richiedono una strategia di DR estremamente solida. Tutte le opzioni devono essere valutate rispetto all'ottimizzazione dei costi: una maggiore resilienza richiede una maggiore quantità di infrastruttura.

    Comprendi le opzioni di ripristino di emergenza disponibili a livello regionale e multiregionale.

    • Le implementazioni multi-AZ sono consigliate per evitare errori di zone di disponibilità. Assicurati di eseguire l'implementazione con Cluster-Mode abilitata nelle architetture Multi-AZ, con un minimo di 3 disponibili. AZs

    • Global Datastore è consigliato per proteggersi dagli errori a livello di regione.

  • [Best practice] Abilita Global Datastore per i carichi di lavoro che richiedono resilienza a livello di regione.

    • Prepara un piano di failover nella regione secondaria in caso di degrado di quella primaria.

    • Esegui il test del processo di failover multiregione prima di eseguire un failover in produzione.

    • Monitora la metrica ReplicationLag per comprendere il potenziale impatto della perdita di dati durante gli eventi di failover.

  • [Risorse]:

REL4: Come si pianificano efficacemente i failover?

Introduzione a livello di domanda: abilitare Multi-AZ con failover automatici è una best practice. ElastiCache In alcuni casi, ElastiCache (RedisOSS) sostituisce i nodi primari nell'ambito delle operazioni di servizio. Ad esempio nel caso di eventi di manutenzione programmata e nel caso poco probabile di un errore in un nodo o una zona di disponibilità. Il successo dei failover dipende sia dalla configurazione della libreria client sia dalla configurazione della ElastiCache libreria client.

Vantaggio a livello di domanda: seguire le migliori pratiche per i ElastiCache failover in combinazione con la libreria client specifica ElastiCache (RedisOSS) consente di ridurre al minimo i potenziali tempi di inattività durante gli eventi di failover.

  • [Obbligatorio] Per la modalità cluster disabilitata, utilizza i timeout in modo che i client rilevino se è necessario disconnettersi dal vecchio nodo primario e riconnettersi al nuovo nodo primario, utilizzando l'indirizzo IP dell'endpoint primario aggiornato. Per la modalità cluster abilitata, la libreria client è responsabile del rilevamento delle modifiche nella topologia del cluster sottostante. Ciò viene spesso ottenuto mediante le impostazioni di configurazione nella libreria client ElastiCache (RedisOSS), che consentono anche di configurare la frequenza e il metodo di aggiornamento. Ogni libreria client offre le proprie impostazioni e maggiori dettagli sono disponibili nella documentazione corrispondente.

    [Risorse]:

  • [Obbligatorio] Il successo dei failover dipende da un ambiente di replica integro tra il nodo primario e quello di replica. Esamina e comprendi la natura asincrona della replica Valkey e Redis, nonché le CloudWatch metriche disponibili per segnalare il ritardo di OSS replica tra i nodi primari e di replica. Per i casi d'uso che richiedono una maggiore sicurezza dei dati, sfrutta il WAIT comando per forzare le repliche a confermare le scritture prima di rispondere ai client connessi.

    [Risorse]:

  • [Migliore] Convalida regolarmente la reattività dell'applicazione durante il failover utilizzando il Test Failover. ElastiCache API

    [Risorse]:

REL5: I vostri ElastiCache componenti sono progettati per essere scalabili?

Introduzione a livello di domanda: comprendendo le capacità di scalabilità e le topologie di implementazione disponibili, ElastiCache i componenti possono adattarsi nel tempo per soddisfare i mutevoli requisiti del carico di lavoro. ElastiCacheoffre una scalabilità a 4 vie: entrata/uscita (orizzontale) e su/giù (verticale).

Vantaggi a livello di domanda: seguire le migliori pratiche per le ElastiCache implementazioni offre la massima flessibilità di scalabilità, oltre a soddisfare il principio Well Architected di scalabilità orizzontale per ridurre al minimo l'impatto dei guasti.

  • [Obbligatorio] Comprendi la differenza tra le topologie modalità cluster abilitata e modalità cluster disabilitata. In quasi tutti i casi è consigliabile eseguire l'implementazione con la modalità cluster abilitata in quanto consente una maggiore scalabilità nel tempo. I componenti in modalità cluster disabilitata sono limitati nella capacità di dimensionarsi orizzontalmente per aggiungere repliche di lettura.

  • [Obbligatorio] Determina quando e come dimensionare.

    • Per ulteriori informazioniREADIOPS: aggiungi repliche

    • Per ulteriori informazioniWRITEOPS: aggiungi frammenti (scalabilità orizzontale)

    • Per ulteriori I/O di rete: utilizza istanze ottimizzate per la rete (dimensionamento verticale)

  • [Ideale] Implementa i ElastiCache componenti con la modalità Cluster abilitata, con una preferenza verso un numero maggiore di nodi più piccoli anziché un numero inferiore di nodi più grandi. In tal modo limiti efficacemente il raggio di applicazione dell'errore di un nodo.

  • [Best practice] Includi le repliche nei cluster per una maggiore reattività durante gli eventi di dimensionamento

  • [Buono] Se la modalità cluster è disattivata, sfrutta le repliche di lettura per aumentare la capacità di lettura complessiva. ElastiCache supporta fino a 5 repliche di lettura in modalità cluster disattivata, oltre al ridimensionamento verticale.

  • [Risorse]: