Domande frequenti su Amazon ElastiCache

Domande generali

Amazon ElastiCache è un servizio web che semplifica l'implementazione e l'esecuzione di cache conformi al protocollo di Valkey, Memcached o Redis OSS nel cloud. ElastiCache migliora le prestazioni delle applicazioni consentendoti di recuperare informazioni da un sistema in memoria veloce e gestito anziché affidarti a sistemi basati su disco più lenti. Il servizio semplifica e alleggerisce la gestione, il monitoraggio e il funzionamento degli ambienti in memoria, consentendo alle risorse di engineering di concentrarsi sullo sviluppo di applicazioni. L'uso di ElastiCache permette non solo di migliorare i tempi di caricamento e di risposta alle operazioni e alle query degli utenti, ma riduce anche il costo associato al dimensionamento delle applicazioni Web.

ElastiCache automatizza le attività amministrative più comuni necessarie al funzionamento di un ambiente distribuito basato su coppie chiave-valore in memoria. Con ElastiCache, l'aggiunta all'architettura applicativa di un livello di dati nella cache o in memoria è una questione di pochi minuti e pochi clic nella Console di gestione AWS. ElastiCache è progettato per mantenere automaticamente l'alta disponibilità e fornisce un Service Level Agreement (SLA) con disponibilità del 99,99%. ElastiCache è conforme ai protocolli di Valeky, Memcached e Redis OSS, perciò il codice, le applicazioni e gli strumenti più comunemente utilizzati negli ambienti Valkey, Memcached e Redis OSS esistenti sono completamente compatibili con il servizio. Non sono richiesti investimenti iniziali e paghi solo per le risorse utilizzate.

Il caching in memoria fornito da ElastiCache può essere utilizzato per migliorare in modo significativo le prestazioni in termini di latenza e di throughput su carichi di lavoro applicativi particolarmente intensivi in termini di lettura (ad esempio per social network, giochi, condivisione di file multimediali e portali di assistenza) oppure in termini di elaborazione (ad esempio motori di raccomandazione). Il caching in memoria migliora le prestazioni delle applicazioni perché memorizza informazioni critiche in una memoria che ha una latenza molto bassa all'accesso. Le informazioni memorizzate nella cache possono essere query di database particolarmente onerose in termini di I/O oppure i risultati di un calcolo che utilizza il processore in modo intensivo.

ElastiCache gestisce il lavoro richiesto per impostare un ambiente dati in memoria distribuito, dal provisioning delle risorse richieste all'installazione del software. Quando si utilizza Amazon ElastiCache Serverless, non è necessario configurare e gestire alcuna infrastruttura. Quando si progetta il proprio cluster ElastiCache, il servizio automatizza le attività amministrative più comuni come l'applicazione di patch software e il rilevamento e il ripristino degli errori. ElastiCache fornisce parametri di monitoraggio dettagliati associati alle tue risorse, consentendoti di diagnosticare e reagire rapidamente ai problemi. Ad esempio, è possibile impostare delle soglie e ricevere allarmi se uno dei nodi è sovraccarico di richieste.

ElastiCache offre Valkey, Memcached e Redis OSS completamente gestiti per le applicazioni più esigenti che richiedono tempi di risposta inferiori al millisecondo.

Se non hai ancora effettuato la registrazione a ElastiCache, puoi selezionare “Inizia” nella pagina di ElastiCache e completare la procedura di registrazione. Per accedere al servizio è necessario un account AWS; se non ne possiedi uno, ti verrà chiesto di crearlo all'inizio della procedura di registrazione ad ElastiCache. Dopo la registrazione a ElastiCache, consulta la documentazione di ElastiCache, che comprende le guide introduttive ad Amazon ElastiCache.

Una volta acquisita familiarità con ElastiCache, puoi creare una cache in pochi minuti utilizzando la console o le API ElastiCache.

Creare una cache è semplice: è possibile farlo utilizzando la Console, le API di ElastiCache o gli strumenti a riga di comando. Quando si utilizza ElastiCache Serverless, puoi creare una cache utilizzando le impostazioni predefinite consigliate e iniziare a utilizzarla in meno di un minuto.

Serverless

ElastiCache serverless è un'opzione serverless che consente di iniziare a utilizzare una cache in meno di un minuto senza dover effettuare il provisioning dell'infrastruttura o pianificare la capacità. ElastiCache serverless elimina la necessità di una pianificazione della capacità dispendiosa in termini di tempo monitorando continuamente l'elaborazione, la memoria e l'utilizzo della rete della cache, in modo da poter scalare istantaneamente per soddisfare la domanda senza tempi di inattività o riduzione delle prestazioni. ElastiCache serverless replica automaticamente i dati su più zone di disponibilità (AZ) e fornisce ai clienti un accordo sul livello di servizio (SLA) con disponibilità del 99,99% per ogni cache. Con ElastiCache serverless, paghi solo per i dati archiviati e le risorse di calcolo utilizzate dall'applicazione. Per iniziare, crea una cache ElastiCache serverless in pochi passaggi specificando il nome della cache tramite la Console, il Software Development Kit (SDK) di ElastiCache o l'interfaccia della linea di comando AWS (AWS CLI).

Puoi spostare un carico di lavoro ElastiCache esistente modificando l'endpoint di Valkey, Redis OSS o Memcached con il nuovo endpoint di cache ElastiCache serverless nella tua applicazione. Puoi migrare i dati ElastiCache esistenti su ElastiCache serverless specificando la posizione di Amazon Simple Storage Service (Amazon S3) di un file di backup. Consulta la nostra documentazione di ElastiCache serverless per saperne di più sulla migrazione dei carichi di lavoro.

ElastiCache serverless supporta Valkey 7.2, Memcached versione 1.6.21 e Redis OSS versione 7.0 e successive.

ElastiCache serverless monitora continuamente la memoria, l'elaborazione e l'utilizzo della rete della cache per un dimensionamento istantaneo. ElastiCache serverless è dimensionabile senza tempi di inattività o riduzione delle prestazioni dell'applicazione, consentendo alla cache di aumentare e avviando il dimensionamento orizzontale in parallelo per soddisfare i requisiti dell'applicazione in tempo utile. Consulta la nostra documentazione di ElastiCache serverless per saperne di più sulla scalabilità.

ElastiCache Serverless archivia automaticamente i dati in modo ridondante in più zone di disponibilità e fornisce un Accordo sul livello di servizio (SLA) con disponibilità del 99,99% per tutti i carichi di lavoro.

Con ElastiCache serverless, paghi solo per i dati archiviati e per l'elaborazione utilizzata dalla tua applicazione. Per saperne di più, visita la pagina dei prezzi di ElastiCache.

Nodi riservati

I nodi riservati o le istanze riservate (RI) possono comportare un notevole risparmio rispetto all'utilizzo on demand se ci si impegna ad utilizzarli per un periodo di uno o tre anni. Con i nodi riservati, è possibile effettuare un singolo pagamento anticipato per creare una prenotazione di uno o tre anni al fine di eseguire il nodo in una determinata regione, ottenendo notevoli sconti sulla tariffa oraria corrente. Esistono tre opzioni di pagamento per i nodi riservati (Pagamento anticipato intero costo, Nessun anticipo e Pagamento anticipato parziale), che consentono di bilanciare l'importo pagato in anticipo con il prezzo effettivo pagato su base oraria.

I nodi riservati offrono uno sconto applicabile all'utilizzo di ElastiCache on demand. ElastiCache serverless non è compatibile con i nodi riservati.

È possibile acquistare fino a 300 nodi riservati. Se desideri eseguire più di 300 nodi, compila il modulo di richiesta nodi di ElastiCache.

Acquista una prenotazione di nodo che abbia in comune la classe e la Regione con il nodo che desideri prenotare correntemente in esecuzione. Se l'acquisto della prenotazione viene completato correttamente, ElastiCache applicherà automaticamente il nuovo costo orario di utilizzo al nodo attuale.

Le variazioni dei prezzi associate a un nodo riservato si attivano alla ricezione della richiesta e mentre viene elaborata l'autorizzazione al pagamento. È possibile seguire lo stato della prenotazione nella pagina dedicata all'attività dell'account AWS oppure utilizzando l'API DescribeReservedCacheNodes. Se il pagamento in un'unica soluzione non viene autorizzato a partire dal periodo di fatturazione successivo, la tariffa scontata non sarà applicata.

Allo scadere del periodo di prenotazione, al nodo riservato tornerà ad essere applicata la tariffa oraria on demand corrispondente alla classe del nodo e alla Regione.

Le API ElastiCache per creare, modificare ed eliminare i nodi non fanno distinzione tra nodi on demand e nodi riservati, quindi puoi utilizzarli entrambi senza problemi. Nel calcolo della fattura, il nostro sistema applica automaticamente le tariffe della tua prenotazione, quindi tutti i nodi idonei saranno fatturati alla tariffa oraria minore per quel nodo di cache riservato.

Ogni nodo riservato è associato a una regione specifica, che rimane fissa per tutta la durata della prenotazione e non può essere modificata. Ogni prenotazione può però essere utilizzata in una qualsiasi delle zone di disponibilità della regione associata.

No, non è possibile annullare la prenotazione del nodo; l'eventuale pagamento in un'unica soluzione non è rimborsabile. Durante il periodo del nodo riservato continuerai a pagare per tutte le ore, indipendentemente dall'utilizzo.

Quando acquisti un nodo riservato con l'opzione Pagamento anticipato intero costo, paghi l'intero nodo riservato con un solo pagamento anticipato. Puoi scegliere di non pagare alcun costo anticipato con l'opzione Nessun pagamento anticipato. L'intero valore del nodo riservato Nessun pagamento anticipato viene distribuito su ogni ora del periodo e pagherai per ogni ora del periodo a prescindere dall'utilizzo. L'opzione Pagamento anticipato parziale è un ibrido tra le altre due opzioni. Dovrai effettuare un piccolo pagamento anticipato e ti sarà addebitata una bassa tariffa oraria per ogni ora della durata del termine, indipendentemente dall'utilizzo.

Sì, i nodi riservati di ElastiCache offrono una flessibilità dimensionale all'interno di una famiglia di istanze (o di una famiglia di nodi) e di una Regione AWS. Ciò significa che la tariffa scontata esistente per i nodi riservati verrà applicata automaticamente all'utilizzo di tutte le dimensioni della stessa famiglia di nodi.

Sicurezza

ElastiCache consente di configurare la crittografia dei dati inattivi utilizzando Sistema AWS di gestione delle chiavi (AWS KMS), la crittografia dei dati in transito tramite Transport Layer Security (TLS), l'autenticazione tramite AWS Identity and Access Management (IAM) e il controllo degli accessi alla rete con i gruppi di sicurezza Amazon Elastic Compute Cloud (Amazon EC2).

Quando non si utilizza Amazon Virtual Private Cloud (Amazon VPC), ElastiCache consente di controllare l'accesso alle cache tramite gruppi di sicurezza di rete. Un gruppo di sicurezza si comporta come un firewall, controllando l'accesso di rete al nodo. Per impostazione predefinita, l'accesso di rete alle tue cache è disabilitato. Se desideri che le tue applicazioni abbiano accesso alla cache, devi abilitare esplicitamente l'accesso dagli host in gruppi di sicurezza Amazon EC2 specifici.

Puoi controllare l'accesso alle tue risorse ElastiCache anche utilizzando l'autenticazione IAM. Per ulteriori informazioni, consulta la documentazione relativa all'autenticazione con IAM.

Conformità

ElastiCache supporta programmi di conformità quali SOC 1, SOC 2, SOC 3, ISO, MTCS, C5, PCI DSS, HIPAA e FedRAMP. Consulta la pagina Servizi AWS coperti dal programma di conformità per un elenco aggiornato dei programmi di conformità supportati.

Sì, il programma di conformità PCI di AWS include ElastiCache come servizio conforme allo standard PCI. Per ulteriori informazioni, consulta le seguenti risorse:

Per un elenco completo dei programmi in cui è incluso ElastiCache, consulta la pagina Servizi AWS coperti dal programma di conformità.

Sì, ElastiCache è un servizio idoneo alla normativa HIPAA ed è coperto da AWS Business Associate Addendum (BAA). Ciò significa che è possibile utilizzare ElastiCache per elaborare, immagazzinare e organizzare le informazioni sanitarie protette (PHI) e promuovere le applicazioni sanitarie.

No, non sono previsti costi aggiuntivi per l'utilizzo delle caratteristiche di conformità.

Se hai stipulato un Business Associate Agreement (BAA) con AWS, puoi utilizzare ElastiCache per creare applicazioni che archiviano ed elaborano le informazioni sanitarie in base alla normativa HIPAA. In caso contrario, oppure se hai domande sull'utilizzo di AWS con le tue applicazioni, contattaci

Il programma di conformità AWS FedRAMP include ElastiCache come servizio autorizzato da FedRAMP. I clienti del governo degli Stati Uniti e i loro partner possono ora utilizzare l'ultima versione di ElastiCache per elaborare e archiviare i sistemi FedRAMP, i dati e i carichi di lavoro mission critical ad alto impatto nelle regioni AWS GovCloud (Stati Uniti-Est) e AWS GovCloud (Stati Uniti-Ovest) e con un impatto moderato nelle regioni Stati Uniti orientali (Ohio), Stati Uniti orientali (Virginia settentrionale), Stati Uniti occidentali (California settentrionale) e Stati Uniti occidentali (Oregon).

Per ulteriori informazioni, consulta le seguenti risorse:

Per un elenco completo dei programmi in cui è incluso ElastiCache, consulta la pagina Servizi AWS coperti dal programma di conformità.

Domande frequenti su Valkey

Funzionalità di Valkey

Valkey è un'evoluzione open source di Redis OSS guidata da Linux Foundation, creata da collaboratori e manutentori di Redis OSS di lunga data. Supporta una varietà di casi d'uso, come la memorizzazione nella cache, classifiche e archivi di sessioni. Valkey è sostenuto da oltre 40 aziende e ha visto una rapida adozione dalla sua creazione nel marzo 2024.

Con ElastiCache per Valkey puoi beneficiare di un'esperienza completamente gestita basata su tecnologia open source, sfruttando al contempo la sicurezza, l'eccellenza operativa, lo SLA di disponibilità del 99,99% e l'affidabilità fornite da AWS. Puoi ottimizzare ulteriormente i costi su ElastiCache serverless per Valkey con un prezzo ridotto del 33% e una archiviazione di dati minima di 100 MB, il 90% in meno rispetto a ElastiCache Redis OSS. Con ElastiCache per Valkey, progettato autonomamente e basato su nodi, puoi beneficiare di un costo per nodo inferiore fino al 20%.

Puoi aggiornare una cache ElastiCache per Redis OSS esistente verso ElastiCache per Valkey senza tempi di inattività, in pochi clic. Puoi iniziare a utilizzare la console di gestione AWS, il Software Development Kit (SDK) o l'interfaccia a riga di comando (CLI). Per ulteriori informazioni, vai alla pagina delle funzionalità di ElastiCache, consulta il blog introduttivo e la guida utente di ElastiCache.

Sì. Con ElastiCache puoi creare una replica di lettura in un'altra zona di disponibilità di AWS. Quando si utilizza ElastiCache serverless, i dati vengono automaticamente archiviati in modo ridondante su più zone di disponibilità per un'elevata disponibilità. Quando si progetta la propria cache ElastiCache, in caso di errore di un nodo, provvederemo a fornire un nuovo nodo. Negli scenari in cui si verifica un errore del nodo principale, ElastiCache converte automaticamente una replica di lettura esistente in ruolo primario. Per maggiori dettagli su come gestire gli errori dei nodi, visita Informazioni sulla replica.

È possibile eseguire rapidamente l'aggiornamento a una versione più recente del motore utilizzando le API ElastiCache e specificando la versione del motore preferita. Nella console ElastiCache, puoi selezionare una cache e selezionare Modifica. Il processo di aggiornamento del motore è progettato per conservare i dati esistenti. Per maggiori dettagli, consulta Strategie e best practice per la memorizzazione nella cache.

No. Il downgrade a una versione precedente del motore non è supportato.

Sì. Puoi creare repliche in più Regioni utilizzando la funzionalità Datastore globale di ElastiCache. Con Datastore globale puoi eseguire repliche rapide, affidabili, sicure e completamente gestite in più regioni. Consente di scrivere sul cluster ElastiCache in una regione e disporre dei dati per la lettura di altri due cluster di replica in più regioni. Questa funzionalità ti permette così di beneficiare di letture a bassa latenza e di operazioni di ripristino di emergenza in più regioni.

Prestazioni

ElastiCache offre thread di I/O potenziati che migliorano significativamente il throughput e la latenza su larga scala tramite il multiplexing, l'offload a livello di presentazione e altro ancora. I thread I/O potenziati migliorano le prestazioni sfruttando diversi core per elaborare i dati di I/O e adattarli in maniera dinamica al carico di lavoro. ElastiCache migliora il throughput dei cluster abilitati a TLS alleggerendo le operazioni di crittografia sugli stessi thread di I/O potenziati. ElastiCache versione 7.2 per Valkey ha introdotto il multiplexing I/O avanzato, che combina molte richieste dei client in un unico canale e migliora l'efficienza del thread.

Nella versione 7.2 di ElastiCache per Valkey e successive, abbiamo esteso la funzionalità dei thread di I/O avanzati per gestire anche la logica del livello di presentazione. I thread I/O avanzati non solo leggono l'input del client, ma lo analizzano anche in un formato di comando binario, che viene poi inoltrato al thread principale per l'esecuzione, al fine di ottenere miglioramenti delle prestazioni. Con ElastiCache versione 7.2 per Valkey, è possibile ottenere fino al 100% in più di throughput e una latenza P99 inferiore del 50% rispetto alla versione precedente. Su r7g.4xlarge o più grandi, è possibile ottenere oltre 1 milione di richieste al secondo (RPS) per nodo.

ElastiCache fornisce due diversi set di metriche per misurare l'utilizzo della CPU della cache in base alla scelta di implementazione della cache. Quando si utilizza ElastiCache serverless, è possibile monitorare l'utilizzo della CPU con il parametro ElastiCache Processing Units (ECPU). Il numero di ECPU utilizzate dalle richieste dipende dal tempo impiegato dalla vCPU e dalla quantità di dati trasferiti. Ogni lettura e scrittura, come i comandi Valkey GET e SET o i comandi get e set di Memcached, richiede 1 ECPU per ogni kilobyte (KB) di dati trasferiti. Alcuni comandi che operano su strutture di dati in memoria possono richiedere più tempo vCPU rispetto a un comando GET o SET. ElastiCache calcola il numero di ECPU consumate in base al tempo di vCPU impiegato dal comando rispetto a una linea di base del tempo di vCPU impiegato da un comando SET o GET. Se il comando richiede più tempo vCPU e trasferisce più dati rispetto alla linea di base di 1 ECPU, ElastiCache calcola le ECPU richieste in base alla maggiore delle due dimensioni.

Quando si progetta il proprio cluster, è possibile monitorare i parametri EngineCPUUtilization e CPUUtilization. Il parametro CPUUtilization misura l'utilizzo della CPU per l'istanza (nodo), mentre il parametro EngineCPUUtilization misura l'utilizzo a livello del processo del motore. È necessario il parametro EngineCPUUtilization in aggiunta a CPUUtilization poiché il processo principale del motore è a thread singolo e utilizza solo una CPU dei core multipli disponibili su un'istanza. Perciò il parametro CPUUtilization non fornisce una visibilità precisa sui tassi di utilizzo della CPU a livello del processo. Ti suggeriamo di utilizzare entrambi i parametri, EngineCPUUtilization e CPUUtilization, insieme, per ottenere una comprensione dettagliata dell'utilizzo della CPU per i tuoi cluster.

Entrambi i set di parametri sono disponibili in tutte le regioni AWS e puoi accedervi utilizzando Amazon CloudWatch o nella console. Inoltre, consigliamo di consultare la documentazione per saperne di più sui parametri utili per il monitoraggio delle prestazioni.

Replica di lettura

Le repliche di lettura hanno due scopi:

  • Gestione dei guasti
  • Dimensionamento della lettura

Quando si esegue un nodo di cache con una replica di lettura, il nodo "primario" effettua le scritture e le letture. La replica serve esclusivamente al traffico di lettura ed è disponibile anche come warm standby nel caso in cui il primario venga danneggiato.

Con ElastiCache serverless, le repliche di lettura vengono gestite automaticamente dal servizio. Quando si progetta la propria cache, esistono diversi scenari in cui potrebbe essere opportuno distribuire una o più repliche di lettura per un determinato nodo primario. Alcuni casi d'uso possono essere, per esempio:

  • Scalabilità oltre la capacità di elaborazione o I/O di un singolo nodo primario per carichi di lavoro ad alta intensità di lettura: questo traffico di lettura in eccesso può essere indirizzato a una o più repliche di lettura.
  • Utilizzo del traffico in lettura quando il nodo primario non è disponibile: se il nodo primario non è in grado di ricevere richieste di I/O, (ad esempio, durante un backup o una fase di manutenzione programmata), si può reindirizzare il traffico in lettura alle repliche di lettura. In questo caso d'uso, è necessario ricordare che i dati sulla replica di lettura potrebbero essere obsoleti, poiché l'istanza principale non è disponibile. Inoltre la replica di lettura può essere utilizzata a caldo per riavviare un'istanza principale non riuscita.

Scenari di protezione dei dati: nell'improbabile eventualità di un errore del nodo primario o che la zona di disponibilità in cui risiede il nodo primario non sia disponibile, si può convertire una replica di lettura in nodo primario in una zona di disponibilità diversa.

Puoi collegarti a una replica di lettura proprio come ti collegheresti a un nodo di cache primario. Se usi più di una replica di lettura, sarà l'applicazione a determinare la distribuzione del traffico in lettura fra queste repliche. Ulteriori informazioni:

  • I cluster di Valkey o Redis OSS (modalità cluster disattivata) utilizzano gli endpoint dei singoli nodi per le operazioni di lettura. (Nell'API/CLI questi sono denominati endpoint di lettura.)
  • I cluster di Valkey o Redis OSS (in modalità cluster abilitata) utilizzano l'endpoint nella configurazione del cluster per tutte le operazioni. Puoi comunque leggere dai singoli endpoint dei nodi. (Nell'API e nella CLI questi sono indicati come endpoint di lettura.)

ElastiCache consente di creare fino a cinque (5) repliche di lettura per un determinato nodo di cache primario.

In caso di failover su più zone di disponibilità, le repliche di lettura associate e disponibili riprendono automaticamente la replica al completamento del failover (dopo, quindi, il recupero degli aggiornamenti dalla nuova replica di lettura).

Gli aggiornamenti a un nodo di cache primario vengono replicati automaticamente alle repliche di lettura associate. Quando viene usata la tecnologia di replica asincrona di Valkey o Redis OSS, tuttavia, una replica di lettura può risultare in ritardo rispetto al nodo di cache principale per una serie di motivi. In genere questo accade nelle seguenti situazioni:

  • Il volume di scrittura di I/O al nodo di cache principale supera il tasso al quale le modifiche sono applicate alla replica di lettura.
  • Partizioni di rete o latenze tra il nodo di cache principale e la replica di lettura.

Le repliche di lettura ereditano i punti di forza e le limitazioni delle repliche di Valkey o Redis OSS. Se utilizzi repliche di lettura, devi tenere conto del potenziale ritardo o "incoerenza" tra una replica di lettura e il suo nodo di cache primario. ElastiCache emette un parametro per aiutarti a rilevare questa incoerenza.

Le repliche di lettura vengono fatturate come nodi di cache standard e prevedono le stesse tariffe. Analogamente ai nodi di cache standard, la tariffa basata sulle “ore-nodo di cache” per le repliche di lettura è determinata dalla classe del nodo di cache della replica di lettura; consulta la pagina dei prezzi di ElastiCache per informazioni aggiornate. I trasferimenti di dati generati durante la replica dei dati tra il nodo di cache e la replica di lettura non vengono fatturati. La fatturazione di una replica di lettura inizia subito dopo la sua creazione (dal momento in cui il suo stato è "attivo"). La fatturazione della replica di lettura proseguirà secondo le tariffe orarie standard per i nodi di cache di ElastiCache finché non viene inviato il comando di eliminazione.

Il failover avviato è supportato da ElastiCache in modo da poter riprendere le operazioni di cache al più presto. Durante l'esecuzione di un failover, ElastiCache cambia il record DNS per il nodo di cache in modo che punti alla replica di lettura, che diventa a sua volta il nuovo nodo principale. Ti consigliamo di seguire le migliori prassi e di implementare i tentativi di connessione al nodo di cache a livello di applicazione. In genere, dall'inizio alla fine, i passaggi da uno a cinque vengono completati entro sei minuti.

Questi sono gli eventi di failover automatico, elencati in ordine di ricorrenza:

  1. Messaggio del gruppo di replica: API Test Failover chiamata per il gruppo di nodi <node-group-id>
  2. Messaggio del cluster di cache: failover dal nodo primario <primary-node-id> al nodo di replica <node-id> completato
  3. Messaggio del gruppo di replica: failover dal nodo primario <primary-node-id> al nodo di replica <node-id> completato
  4. Messaggio del cluster di cache: recupero dei nodi di cache <node-id>
  5. Messaggio del cluster di cache: ripristino dei nodi di cache <node-id> terminato

No. Puoi effettuare il provisioning della replica di lettura solo nella stessa zona di disponibilità o in un'altra zona di disponibilità della stessa regione del nodo di cache primario. Tuttavia, puoi utilizzare Datastore globale per lavorare con una replica veloce, affidabile, sicura e completamente gestita in più regioni AWS. Utilizzando questa funzionalità, puoi creare cluster di repliche di lettura in più regioni per ElastiCache per abilitare letture e ripristino di emergenza a bassa latenza in più regioni AWS.

Sì. Si possono aggiungere e rimuovere le repliche tra una o più partizioni in un ambiente cluster. Sì, il cluster rimarrà online ed elaborerà gli I/O in ingresso durante l'operazione.

Multi-AZ

Multi-AZ è una funzionalità che consente di eseguire una configurazione a disponibilità più elevata quando si progetta la propria cache ElastiCache. Tutte le cache ElastiCache serverless vengono eseguite automaticamente in una configurazione Multi-AZ. Un gruppo di replica ElastiCache consiste in un nodo principale e fino a cinque repliche di lettura. Se la funzione Multi-AZ è abilitata, è necessaria almeno una replica per nodo principale. Durante determinati interventi di manutenzione pianificati oppure nell'eventualità di un errore del nodo ElastiCache o della zona di disponibilità, ElastiCache rileva automaticamente l'errore del nodo principale, seleziona una replica di lettura e la converte nel nuovo nodo principale. Inoltre ElastiCache converte le modifiche DNS della replica di lettura convertita, in modo che, se l'applicazione scrive sull'endpoint del nodo principale, nessun cambiamento di endpoint sarà necessario.

I vantaggi principali di eseguire ElastiCache in modalità Multi-AZ sono l'aumentata disponibilità e l'amministrazione ridotta. Quando si esegue ElastiCache in una configurazione Multi-AZ, le cache sono idonee per lo SLA di disponibilità del 99,99%. In caso di errore del nodo principale di ElastiCache, l'impatto sulla capacità di lettura e scrittura sul nodo principale è limitato al periodo durante il quale viene effettuato il failover automatico. Quando Multi-AZ è attivo, il failover del nodo ElastiCache è automatico e non richiede nessuna gestione.

Puoi utilizzare Multi-AZ se usi ElastiCache e hai un gruppo di replica che consiste in un nodo principale e una o più repliche di lettura. In caso di errore del nodo principale, ElastiCache rileva automaticamente l'errore, seleziona una delle repliche di lettura disponibili e la converte in nodo principale. ElastiCache converte le modifiche DNS della replica di lettura convertita, in modo che l'applicazione continui a scrivere sull'endpoint principale. ElastiCache creerà un nuovo nodo per sostituire la replica di lettura convertita nella stessa zona di disponibilità del nodo principale con errore. In caso di errore del nodo principale dovuto a un'interruzione nella zona di disponibilità, la nuova replica verrà lanciata non appena la zona di disponibilità sarà ripristinata.

Sì. Collocare il nodo principale e le repliche nella stessa zona di disponibilità non garantisce la resistenza del gruppo di repliche di ElastiCache a interruzioni nella zona di disponibilità.

Un failover di ElastiCache su una replica di lettura può avvenire in uno dei casi seguenti:

  • Perdita di disponibilità nella zona di disponibilità del nodo principale
  • Perdita di connettività di rete nell'istanza principale
  • Errore dell'unità di elaborazione nell'istanza principale

Se esiste più di una replica di lettura, viene convertita la replica di lettura che presenta il ritardo di replica asincrona minore rispetto al nodo primario.

Sì, ElastiCache crea un evento per informarti che è stato effettuato un failover automatico. Puoi usare l'API DescribeEvents per raccogliere informazioni sugli eventi relativi al tuo nodo ElastiCache o selezionare la sezione "Eventi" sulla console di gestione ElastiCache.

Le zone di disponibilità sono state progettate in modo da connettersi tra loro in rete con una latenza minima all'interno della stessa regione. Potrebbe essere opportuno progettare la propria applicazione e organizzare le altre risorse AWS in modo che offrano ridondanza su più zone di disponibilità, consentendo una maggiore resilienza dell'applicazione in caso di errore in una zona di disponibilità.

Per ulteriori informazioni su Multi-AZ, consultare la documentazione ElastiCache.

Backup e ripristino

La funzionalità di backup e ripristino è una funzionalità che consente di creare snapshot delle cache di ElastiCache. ElastiCache memorizza gli snapshot, permettendo agli utenti di utilizzarli per ripristinare le cache. Attualmente è supportato con ElastiCache per Valkey, ElastiCache per Redis OSS e serverless.

Creare snapshot può risultare utile in caso di perdite di dati causate da errori di un nodo, oppure nell'improbabile eventualità di un guasto all'hardware. Un altro caso d'uso comune degli snapshot è la creazione di backup e l'archiviazione. Gli snapshot vengono memorizzati in Amazon S3.

È possibile esportare snapshot di ElastiCache in un bucket S3 autorizzato nella stessa regione della cache.

Sì. Devi copiare lo snapshot in un qualsiasi bucket S3 autorizzato nella stessa Regione, quindi concedere i privilegi di accesso tra più account all'altro account.

ElastiCache offre spazio di archiviazione gratuito per uno snapshot per ogni cluster ElastiCache attivo. Lo spazio di archiviazione aggiuntivo verrà addebitato sulla base dello spazio utilizzato dagli snapshot con 0,085 USD/GB al mese (stesso prezzo per tutte le regioni). Per gli snapshot non sarà addebitato alcun costo per il trasferimento di dati.

Quando si elimina una cache ElastiCache, gli snapshot manuali vengono mantenuti. Hai anche la possibilità di creare uno snapshot finale prima di eliminare la cache. Gli snapshot di cache automatici non vengono conservati.

Miglioramenti al motore

Il motore di ElastiCache è completamente compatibile con Valkey e Redis OSS, ma racchiude anche alcuni miglioramenti che ne potenziano prestazioni, affidabilità e stabilità. Ad esempio:

  • Possibilità di utilizzare più memoria: è possibile allocare maggiori volumi di memoria all'applicazione senza rischiare picchi di swapping durante sincronizzazioni e snapshot.
  • Sincronizzazione migliorata: la sincronizzazione è più affidabile, in particolare con carichi di lavoro onerosi e durante il ripristino in seguito a interruzioni di rete. Inoltre, le sincronizzazioni sono più rapide, perché sia il nodo principale sia le repliche non avvengono più su disco.
  • Failover più lineari: in caso di failover, la partizione viene ripristinata più rapidamente, perché le repliche non devono più scaricare i dati per completare una risincronizzazione completa col nodo principale.
  • Offload TLS e multiplexing IO: ElastiCache è progettato per utilizzare meglio le risorse della CPU disponibili gestendo determinati processi relativi alla rete su thread dedicati.

Il motore migliorato è completamente compatibile con Valkey o Redis OSS, perciò potrai sfruttarne l'affidabilità e la stabilità senza apportare alcuna modifica al codice della tua applicazione.

Non sono previsti costi aggiuntivi per l'utilizzo del motore migliorato.

Crittografia

Crittografia in transito, crittografia a riposo, Valkey AUTH e Role-Based Access Control (RBAC) sono funzionalità che puoi selezionare quando crei la cache di ElastiCache. Abilitando la crittografia in transito puoi scegliere di utilizzare AUTH o RBAC, per una maggiore sicurezza e il controllo degli accessi.

La crittografia a riposo offre meccanismi di protezione dall'accesso non autorizzato ai dati. Se abilitato, crittografa i seguenti aspetti:

  • Disco durante le operazioni di sincronizzazione, backup e swapping
  • Backup archiviati in Amazon S3

ElastiCache offre la crittografia a riposo predefinita (gestita dai servizi) oltre alla possibilità di utilizzare le tue chiavi AWS KMS simmetriche gestite dal cliente in AWS KMS. Consulta Crittografia a riposo per saperne di più.

La funzionalità di crittografia in transito facilita la crittografia delle comunicazioni tra client ed ElastiCache, nonché tra i server (repliche primarie e di lettura). Scopri di più sulla crittografia in transito di ElastiCache.

No. ElastiCache gestisce scadenza e rinnovo delle certificazioni dietro le quinte. Non sono necessarie azioni da parte dell'utente per la manutenzione continuativa dei certificati.

No, non verrà addebitato alcun costo aggiuntivo per l'utilizzo della crittografia.

Global Datastore

Il datastore globale è una funzionalità di ElastiCache che offre repliche rapide, affidabili, sicure e interamente gestite in più Regioni. Con il datastore globale, è possibile scrivere nella cache in una regione e disporre dei dati per la lettura in altri due cluster di replica in più regioni. Questa funzionalità ti permette così di beneficiare di letture a bassa latenza e di operazioni di ripristino di emergenza in più regioni.

Progettata per applicazioni in tempo reale, la funzionalità datastore globale in genere replica i dati in più regioni, in meno di un secondo, incrementando la reattività dell'applicazione, grazie alla fornitura di letture geolocalizzate più vicine agli utenti finali. Nell'improbabile eventualità di un calo delle prestazioni a livello regionale, è possibile promuovere uno dei cluster di replica integri in più regioni a cluster primario con funzionalità di lettura e scrittura complete. Una volta avviata, sarà necessario meno di un minuto per il completamento della promozione. Ciò consente alle applicazioni di conservare la loro disponibilità.

Le repliche si possono effettuare al massimo in due regioni secondarie nell'ambito del datastore globale per Redis. Le cache situate nelle regioni secondarie possono essere utilizzati per gestire letture locali a bassa latenza e per il ripristino di emergenza, nell'improbabile eventualità di un calo delle prestazioni a livello regionale.

Il datastore globale è supportato su ElastiCache versione 7.2 per Valkey ed ElastiCache versione 5.0.6 e successive per Redis OSS.

È possibile configurare un datastore globale utilizzando un cluster esistente o creando un nuovo cluster da utilizzare come cluster principale. Puoi creare un datastore globale con pochi passaggi nella console di gestione ElastiCache o scaricando l'SDK AWS o l'interfaccia a riga di comando AWS più recenti. Il datastore globale è supportato in AWS CloudFormation.

No, ElastiCache non promuove automaticamente un cluster secondario in caso di riduzione delle prestazioni del cluster (Regione) principale. Puoi avviare manualmente il failover promuovendo un cluster secondario in modo che diventi quello primario. Il failover e la promozione del cluster secondario in genere vengono completati in meno di un minuto.

ElastiCache non addebita alcun costo per l'utilizzo del datastore globale. Paghi solo le cache primarie e secondarie nel datastore globale e il traffico per il trasferimento di dati tra regioni.

ElastiCache non fornisce un contratto sul livello di servizio per RPO e RTO. Il parametro RPO varia in base al ritardo della replica tra Regioni e dipende dalla latenza di rete tra Regioni e dalla congestione del traffico di rete tra Regioni. L'RPO del datastore globale in genere è inferiore a un secondo, quindi i dati scritti nella regione principale sono disponibili nelle regioni secondarie entro un secondo. L'RTO of Global Datastore è in genere inferiore a un minuto. Dopo l'avvio del failover su un cluster secondario, ElastiCache in genere lo promuove per le funzionalità di lettura e scrittura in meno di un minuto.

Domande frequenti su Memcached

Funzionalità di Memcached

È possibile memorizzare nella cache una varietà di oggetti utilizzando ElastiCache per Memcached. Questi oggetti includono il contenuto di datastore persistenti, come Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB o database autogestiti ospitati su Amazon EC2, pagine Web generate dinamicamente (con Nginx, ad esempio), dati di sessione transitori che potrebbero non richiedere un backup persistente. Può anche essere utilizzato per l'implementazione di contatori ad alta frequenza che consentano di distribuire controlli di ammissione in applicazioni Web con volumi elevati.

Sì. ElastiCache è il front-end ideale per datastore come DynamoDB e Amazon RDS, poiché fornisce accesso ai dati di secondo livello con prestazioni elevate per applicazioni con frequenza di richieste molto elevata e/o requisiti di bassa latenza.

ElastiCache è conforme al protocollo con Memcached. Perciò è possibile utilizzare le operazioni standard Memcached come get, set, incr e decr esattamente nello stesso modo in cui li si utilizza nelle implementazioni esistenti di Memcached. ElastiCache supporta i protocolli di testo e binari. Inoltre supporta la maggior parte dei risultati statistici standard, che possono essere visualizzati anche come grafi tramite CloudWatch. Insomma, puoi passare ad ElastiCache senza ricompilare o ricollegare le tue applicazioni: le librerie che utilizzi continueranno a funzionare. Per configurare i server cache ai quali accede un'applicazione, aggiorna il file di configurazione relativo a Memcached dell'applicazione perché includa gli endpoint dei server assegnati (i nodi). Puoi utilizzare l'opzione Copia endpoint di nodi nella console o l'API DescribeCacheClusters per ottenere un elenco degli endpoint. Come per ogni procedura di migrazione, consigliamo di effettuare un test approfondito della nuova distribuzione di ElastiCache prima di completare la migrazione dalla soluzione attuale.

Puoi accedere ai cluster ElastiCache in un Amazon VPC dalla rete Amazon EC2 o dal tuo data center. Per maggiori dettagli, consulta Modelli di accesso di Amazon VPC. ElastiCache impiega le voci DNS per consentire alle applicazioni client di individuare i server (nodi). I nomi DNS dei nodi rimangono costanti, mentre l'indirizzo IP può cambiare nel tempo, per esempio quando vengono sostituiti dopo un errore su un'installazione al di fuori di VPC. Prosegui nella lettura di queste domande frequenti per ulteriori informazioni su come affrontare errori nei nodi.

Configurazione e scalabilità

Non esiste una risposta esatta a questa domanda; con ElastiCache, tuttavia, non è necessario calcolare con la massima precisione il numero di nodi necessari, poiché è possibile aggiungerli o rimuoverli in un secondo momento con la massima semplicità. Puoi anche utilizzare ElastiCache serverless per semplificare l'esecuzione di una cache Memcached ad alta disponibilità. Per scegliere la configurazione iniziale, si devono prendere in considerazione due aspetti correlati:

  • La memoria totale necessaria alla cache per raggiungere l'hit rate della cache previsto
  • Il numero di nodi necessari per consentire all'applicazione prestazioni accettabili senza sovraccaricare il back-end di database in caso di errori dei nodi.

La quantità di memoria necessaria dipende dalle dimensioni del dataset e dagli schemi di accesso all'applicazione. Per migliorare la tolleranza ai guasti, quando hai un'idea approssimativa della memoria totale necessaria, dividi questo valore per un numero di nodi sufficiente perché l'applicazione possa continuare a funzionare anche nel caso in cui uno o due nodi dovessero arrestarsi. Ad esempio, se la memoria richiesta corrisponde a 13 GB, è opportuno utilizzare due nodi cache.m4.large invece di un nodo cache.m4.xlarge. È importante che i sistemi correlati, ad esempio i database, non si sovraccarichino nel caso in cui l'hit rate della cache si riducesse temporaneamente durante il ripristino di uno o più nodi. Per ulteriori informazioni, consulta la Guida per l'utente di ElastiCache.

Sì. Quando si crea un cluster o si aggiungono nodi a un cluster esistente, si possono scegliere le zone di disponibilità per i nuovi nodi. Si può specificare il numero di nodi richiesto in ogni zona di disponibilità o selezionare Distribuisci i nodi nelle zone. Se il cluster si trova in un Amazon VPC, i nodi possono essere solo collocati in zone di disponibilità che fanno parte del gruppo di sottoreti di cache selezionato. Per ulteriori informazioni, consulta la documentazione del VPC di ElastiCache.

È possibile eseguire un massimo di 300 nodi per Regione. Se occorre un numero maggiore di nodi, compila il modulo di richiesta di aumento dei limiti per ElastiCache.

Il servizio rileva l'errore del nodo ed effettua le seguenti operazioni automatiche:

  • ElastiCache ripristina il nodo con l'acquisizione di nuove risorse e reindirizza il nome DNS esistente del nodo verso le nuove risorse. Per le installazioni Amazon VPC, ElastiCache assicura che sia il nome DNS sia l'indirizzo IP del nodo non varino quando i nodi vengono ripristinati in caso di guasto. Per le installazioni al di fuori di Amazon VPC, ElastiCache assicura che il nome DNS dei nodi rimanga costante; tuttavia l'indirizzo IP del nodo può variare.
  • Se un argomento SNS viene associato al cluster, quando il nuovo nodo viene configurato ed è pronto per l'utilizzo ElastiCache invia una notifica SNS per avvisare che il ripristino del nodo è stato completato. In questo modo è possibile configurare le applicazioni in modo che forzino la librerie client di Memcached a ricollegarsi con i nodi ripristinati. Si tratta di un'operazione importante, poiché alcune librerie di Memcached interrompono l'utilizzo di un server (nodo) a tempo indeterminato in caso di errori di comunicazione o timeout.

È possibile aggiungere nodi supplementari al cluster di Memcached esistente tramite l'opzione "Aggiungi nodo" nella scheda "Nodi" per il cluster di cache nella console oppure richiamando l'API ModifyCacheCluster.

Compatibilità

ElastiCache è la soluzione ideale come front-end per i servizi AWS, ad esempio Amazon RDS e Amazon DynamoDB, poiché offre una latenza estremamente bassa per applicazioni che richiedono prestazioni elevate e alleggerisce il volume delle richieste mentre i servizi offrono elevata durabilità dei dati. Il servizio può essere utilizzato per migliorare le prestazioni delle applicazioni in combinazione con Amazon EC2 ed Amazon EMR.

Le librerie client di Memcached sono disponibili per molti, se non tutti i linguaggi di programmazione più utilizzati. In caso di problemi con client specifici di Memcached durante l'utilizzo di ElastiCache, contattaci sul forum della community di ElastiCache.

Individuazione automatica

L'individuazione automatica è una funzionalità che fa risparmiare tempo e sforzi agli sviluppatori e riduce la complessità delle loro applicazioni. La funzionalità di individuazione automatica consente il rilevamento automatico di nodi di cache sui client quando vengono aggiunti o eliminati nodi da un cluster ElastiCache. Per gestire le modifiche di appartenenza al cluster, gli sviluppatori dovevano aggiornare manualmente l'elenco degli endpoint di nodi di cache. A seconda dell'architettura dell'applicazione del client, di solito è necessaria un'inizializzazione del client, ottenuta arrestando l'applicazione e poi riavviandola, che risulta in un periodo di inattività. Grazie all’individuazione automatica, ElastiCache elimina questa complessità. Con l'individuazione automatica, oltre alla conformità in senso inverso al protocollo Memcached, ElastiCache fornisce ai client le informazioni sull'appartenenza al cache cluster. Un client idoneo a elaborare le informazioni supplementari si riconfigura da solo,senza alcuna inizializzazione, per utilizzare i nodi più correnti di un cluster ElastiCache.

Un cluster ElastiCache può essere creato con i nodi che possono essere indirizzabili tramite endpoint denominati. Con l'individuazione automatica, al cluster ElastiCache viene conferito un endpoint di configurazione unico che è un record DNS valido per tutta la durata del cluster. Il record DNS contiene i nomi DNS dei nodi che appartengono al cluster. ElastiCache si assicura che l'endpoint di configurazione punti sempre almeno a uno di questi nodi di "destinazione". Una query al nodo di destinazione restituisce gli endpoint per tutti gli altri nodi del cluster in questione. Dopodiché ci si può collegare ai nodi di cluster come prima e utilizzare i comandi del protocollo di Memcached come get, set, incr e decr. Per maggiori dettagli, consulta la documentazione. Per utilizzare l'individuazione automatica è necessario un client idoneo. I client di individuazione automatica per .Net, Java e PHP possono essere scaricati dalla console di ElastiCache. Al momento dell'inizializzazione, il client determina automaticamente i membri attuali del cluster ElastiCache utilizzando l'endpoint di configurazione. Quando si effettuano modifiche al cluster di cache aggiungendo o eliminando nodi oppure se un nodo viene sostituito in seguito a un errore, il client di individuazione automatica determina le modifiche e non è necessario inizializzare manualmente i client.

Per cominciare, scarica il client del cluster ElastiCache facendo clic sul collegamento "Scarica il client del cluster ElastiCache sulla console ElastiCache. Prima di scaricare bisogna possedere un account ElastiCache; se non ne hai già uno, puoi registrarti sulla pagina dei dettagli di ElastiCache. Dopo aver scaricato il client, si può cominciare a impostare e attivare il cluster ElastiCache tramite la console di ElastiCache. Maggiori dettagli sono disponibili nella documentazione.

Sì, è possibile smettere di utilizzare l'individuazione automatica in qualunque momento. L'individuazione automatica può essere disattivata specificando il modo operativo durante l'inizializzazione del client del cluster ElastiCache. Inoltre, poiché ElastiCache continua a supportare Memcached, si può continuare a utilizzare qualunque client conforme al protocollo Memcached come prima.

Per approfittare dell'individuazione automatica, è necessario utilizzare un client idoneo all'individuazione automatica per collegarsi a un cluster ElastiCache. ElastiCache attualmente supporta client in grado di eseguire l’individuazione automatica per .Net, Java e PHP. Questi possono essere scaricati dalla console ElastiCache. I nostri clienti possono creare client per qualunque altro linguaggio sulla base dei client Memcached più utilizzati disponibili.

È possibile prendere qualunque libreria di client Memcached e aggiungere il supporto per l'individuazione automatica. Se vuoi aggiungere o modificare un client per abilitare l'individuazione automatica, consulta la documentazione del set di comandi di individuazione automatica.

Sì, ElastiCache è ancora conforme al protocollo Memcached e non richiede modifiche dei client. Tuttavia, per sfruttare la funzione di individuazione automatica, abbiamo migliorato le funzionalità del client Memcached. Se scegli di non utilizzare il client del cluster ElastiCache, puoi continuare a utilizzare i tuoi client o modificare la tua libreria di client perché riconosca il set di comandi di individuazione automatica.
 

Sì, lo stesso cluster ElastiCache può essere collegato contemporaneamente a un client idoneo all'individuazione automatica e al client Memcached tradizionale. ElastiCache resta conforme al 100% a Memcached.

Sì, è possibile smettere di utilizzare l'individuazione automatica in qualunque momento. L'individuazione automatica può essere disattivata specificando il modo operativo durante l'inizializzazione del client del cluster ElastiCache. Inoltre, poiché ElastiCache continua a supportare Memcached, si può continuare a utilizzare qualunque client conforme al protocollo Memcached come prima.

Gestione della versione del motore

ElastiCache consente di controllare se e quando il software conforme al protocollo di Memcached di un cluster viene aggiornato a una nuova versione supportata da ElastiCache. Questa soluzione consente di mantenere la compatibilità con versioni specifiche di Memcached, testare nuove versioni sull'applicazione prima di distribuirle in produzione ed eseguire aggiornamenti della versione secondo i propri tempi e le proprie esigenze. Poiché gli aggiornamenti della versione presentano rischi relativi alla compatibilità, non saranno eseguiti automaticamente e dovranno essere applicati manualmente. Questo approccio all'applicazione di patch software consente un controllo completo degli aggiornamenti della versione, delegando al contempo le operazioni di applicazione di patch a ElastiCache. Per ulteriori informazioni sulla gestione della versione, consulta le domande frequenti di seguito. In alternativa, puoi consultare la Guida per l'utente di ElastiCache. Mentre la funzionalità di gestione della versione del motore conferisce il controllo completo sulle modalità di applicazione delle patch, il cluster potrà essere aggiornato automaticamente con le patch più recenti se vengono individuate vulnerabilità alla sicurezza nel sistema o nel software di cache.

Quando viene creato un nuovo cluster, è possibile specificare qualunque versione supportata (principale e/o secondaria). Se desideri avviare un aggiornamento a una versione supportata del motore, seleziona l'opzione "Modifica" del relativo cluster. Specifica quindi la versione alla quale vuoi eseguire l'aggiornamento nel campo "Versione del motore del cache". L'aggiornamento verrà applicato immediatamente, se l'opzione "Applicazione immediata" è attiva, oppure durante la successiva finestra di manutenzione del cluster.

Sì. Per farlo, crea un cluster con la nuova versione del motore. Configura quindi l'applicazione di sviluppo o di staging in modo che reindirizzi a questo cluster, così potrai procedere con il testing e decidere se aggiornare o meno il cluster originale.

Nel prossimo futuro progettiamo di supportare versioni supplementari, primarie e secondarie, di Memcached per ElastiCache. Il numero delle nuove versioni supportate in un anno varia in base alla frequenza e al contenuto delle versioni di Memcached e ai risultati di un esame approfondito della versione da parte del nostro team di tecnici.

Per aggiornare un cluster Memcached esistente è necessario utilizzare il processo “Modifica”. Quando si esegue l'aggiornamento da una versione precedente alla versione 1.4.33 o successiva di Memcached, è importante verificare che i valori esistenti del parametro max_chunk_size soddisfino le condizioni necessarie per il parametro slab_chunk_max. Consulta i prerequisiti dell'aggiornamento.

Domande frequenti su Redis OSS

Funzionalità

ElastiCache è un servizio Web che semplifica la l'implementazione e l'esecuzione di cache conformi al protocollo Redis OSS nel cloud. Il servizio consente la gestione, il monitoraggio e il funzionamento dei nodi Redis OSS; la creazione, l'eliminazione e la modifica dei nodi possono essere effettuate tramite la console di ElastiCache, l'interfaccia a riga di comando (AWS CLI) o le API del servizio Web. ElastiCache supporta le configurazioni ad alta disponibilità, inclusa la modalità cluster Redis OSS abilitata e la modalità cluster disabilitata con failover automatico dal primario alla replica.

Sì, ElastiCache è progettato per essere conforme al protocollo Redis OSS. Il codice, le applicazioni, i driver e gli strumenti utilizzati attualmente con il datastore Redis OSS autonomo continueranno a funzionare con ElastiCache e senza bisogno di modificare il codice per migrare le implementazioni esistenti di Redis OSS su ElastiCache, salvo disposizione contraria.

Consulta la pagina dei prezzi per informazioni aggiornate.

Sì. Con ElastiCache puoi creare una replica di lettura in un'altra zona di disponibilità di AWS. Quando si utilizza ElastiCache serverless, i dati vengono automaticamente archiviati in modo ridondante su più zone di disponibilità per un'elevata disponibilità. Quando si progetta la propria cache ElastiCache, in caso di errore di un nodo, provvederemo a fornire un nuovo nodo. Negli scenari in cui si verifica un errore del nodo principale, ElastiCache converte automaticamente una replica di lettura esistente in ruolo primario. Per maggiori dettagli su come gestire gli errori dei nodi, consulta la pagina Understanding replication.

È possibile eseguire rapidamente l'aggiornamento a una versione più recente del motore utilizzando le API ElastiCache e specificando la versione del motore preferita. Nella console ElastiCache, puoi selezionare una cache e selezionare Modifica. Il processo di aggiornamento del motore è progettato per conservare i dati esistenti. Per maggiori dettagli, consulta la pagina Caching strategies and best practices.

No. Il downgrade a una versione precedente del motore non è supportato.

Sì. Puoi creare repliche in più regioni utilizzando la funzionalità Datastore globale di ElastiCache. Con Datastore globale puoi eseguire repliche rapide, affidabili, sicure e completamente gestite in più regioni. Consente di scrivere sul cluster ElastiCache in una regione e disporre dei dati per la lettura di altri due cluster di replica in più regioni. Questa funzionalità ti permette così di beneficiare di letture a bassa latenza e di operazioni di ripristino di emergenza in più regioni.

Prestazioni

ElastiCache offre thread di I/O potenziati che migliorano significativamente il throughput e la latenza su larga scala tramite il multiplexing, l'offload a livello di presentazione e altro ancora. I thread I/O potenziati migliorano le prestazioni sfruttando diversi core per elaborare i dati di I/O e adattarli in maniera dinamica al carico di lavoro. ElastiCache migliora il throughput dei cluster abilitati a TLS alleggerendo le operazioni di crittografia sugli stessi thread di I/O potenziati. ElastiCache (Redis OSS) versione 7.0 ha introdotto il multiplexing I/O avanzato, che combina molte richieste dei client in un unico canale e migliora l'efficienza del thread.

Nella versione 7.1 di ElastiCache e successive per Redis OSS , abbiamo esteso la funzionalità dei thread di I/O avanzati per gestire anche la logica del livello di presentazione. I thread I/O avanzati non solo leggono l'input del client, ma lo analizzano anche in un formato di comando binario, che viene poi inoltrato al thread principale per l'esecuzione, al fine di ottenere miglioramenti delle prestazioni. Con ElastiCache versione 7.1 per Redis OSS, è possibile ottenere fino al 100% in più di throughput e una latenza P99 inferiore del 50% rispetto alla versione precedente. Su r7g.4xlarge o più grandi, è possibile ottenere oltre 1 milione di richieste al secondo (RPS) per nodo.

ElastiCache fornisce due diversi set di metriche per misurare l'utilizzo della CPU della cache in base alla scelta di implementazione della cache. Quando si utilizza ElastiCache serverless, è possibile monitorare l'utilizzo della CPU con il parametro ElastiCache Processing Units (ECPU). Il numero di ECPU utilizzate dalle richieste dipende dal tempo impiegato dalla vCPU e dalla quantità di dati trasferiti. Ogni lettura e scrittura, come i comandi Redis OSS GET e SET o i comandi get e set di Memcached, richiede 1 ECPU per ogni kilobyte (KB) di dati trasferiti. Alcuni comandi Redis OSS che operano su strutture di dati in memoria possono richiedere più tempo vCPU rispetto a un comando GET o SET. ElastiCache calcola il numero di ECPU consumate in base al tempo di vCPU impiegato dal comando rispetto a una linea di base del tempo di vCPU impiegato da un comando SET o GET. Se il comando richiede più tempo vCPU e trasferisce più dati rispetto alla linea di base di 1 ECPU, ElastiCache calcola le ECPU richieste in base alla maggiore delle due dimensioni.

Quando si progetta il proprio cluster, è possibile monitorare i parametri EngineCPUUtilization e CPUUtilization. Il parametro CPUUtilization misura l'utilizzo della CPU per l'istanza (nodo), mentre il parametro EngineCPUUtilization misura l'utilizzo a livello del processo del motore. È necessario il parametro EngineCPUUtilization in aggiunta a CPUUtilization perché il processo principale di Redis OSS è a thread singolo e utilizza solo una CPU dei core multipli disponibili su un'istanza. Perciò il parametro CPUUtilization non fornisce una visibilità precisa sui tassi di utilizzo della CPU a livello del processo di motore. Ti suggeriamo di utilizzare entrambi i parametri, EngineCPUUtilization e CPUUtilization, insieme, per ottenere una comprensione dettagliata dell'utilizzo della CPU per i tuoi cluster Redis OSS.

Entrambi i set di parametri sono disponibili in tutte le regioni AWS e puoi accedervi utilizzando Amazon CloudWatch o la console. Inoltre, consigliamo di consultare la documentazione per saperne di più sui parametri utili per il monitoraggio delle prestazioni.

Replica di lettura

Le repliche di lettura in Redis OSS hanno due scopi:

  • Gestione dei guasti
  • Dimensionamento della lettura

Quando si esegue un nodo di cache con una replica di lettura, il nodo "primario" effettua le scritture e le letture. La replica serve esclusivamente al traffico di lettura ed è disponibile anche come warm standby nel caso in cui il primario venga danneggiato.

Con ElastiCache serverless, le repliche di lettura vengono gestite automaticamente dal servizio. Quando si progetta la propria cache, esistono diversi scenari in cui potrebbe essere opportuno distribuire una o più repliche di lettura per un determinato nodo primario. Alcuni casi d'uso possono essere, per esempio:

  • Scalabilità oltre la capacità di elaborazione o I/O di un singolo nodo primario per carichi di lavoro ad alta intensità di lettura: questo traffico di lettura in eccesso può essere indirizzato a una o più repliche di lettura.
  • Utilizzo del traffico in lettura quando il nodo primario non è disponibile: se il nodo primario non è in grado di ricevere richieste di I/O, (ad esempio, durante un backup o una fase di manutenzione programmata), si può reindirizzare il traffico in lettura alle repliche di lettura. In questo caso d'uso, è necessario ricordare che i dati sulla replica di lettura potrebbero essere obsoleti, poiché l'istanza principale non è disponibile. Inoltre la replica di lettura può essere utilizzata a caldo per riavviare un'istanza principale non riuscita.
  • Scenari di protezione dei dati: nell'improbabile eventualità di un errore del nodo primario o che la zona di disponibilità in cui risiede il nodo primario non sia disponibile, si può convertire una replica di lettura in nodo primario in una zona di disponibilità diversa. 

Puoi collegarti a una replica di lettura proprio come ti collegheresti a un nodo di cache primario. Se usi più di una replica di lettura, sarà l'applicazione a determinare la distribuzione del traffico in lettura fra queste repliche. Ulteriori informazioni:

  • I cluster Redis OSS (modalità cluster disattivata) utilizzano gli endpoint dei singoli nodi per le operazioni di lettura. (Nell'API/CLI questi sono denominati endpoint di lettura.)
  • I cluster Redis OSS (in modalità cluster abilitata) utilizzano l'endpoint nella configurazione del cluster per tutte le operazioni. Puoi comunque leggere dai singoli endpoint dei nodi. (Nell'API e nella CLI questi sono indicati come endpoint di lettura.)

ElastiCache consente di creare fino a cinque (5) repliche di lettura per un determinato nodo di cache primario.

In caso di failover su più zone di disponibilità, le repliche di lettura associate e disponibili riprendono automaticamente la replica al completamento del failover (dopo, quindi, il recupero degli aggiornamenti dalla nuova replica di lettura).

Gli aggiornamenti a un nodo di cache primario vengono replicati automaticamente alle repliche di lettura associate. Quando viene usata la tecnologia di replica asincrona di Redis OSS, tuttavia, una replica di lettura può risultare in ritardo rispetto al nodo di cache principale per una serie di motivi. In genere questo accade nelle seguenti situazioni:

  • Il volume di scrittura di I/O al nodo di cache principale supera il tasso al quale le modifiche sono applicate alla replica di lettura.
  • Partizioni di rete o latenze tra il nodo di cache principale e la replica di lettura.

Le repliche di lettura ereditano i punti di forza e le limitazioni delle repliche di Redis OSS. Se utilizzi repliche di lettura, devi tenere conto del potenziale ritardo o "incoerenza" tra una replica di lettura e il suo nodo di cache primario. ElastiCache emette un parametro per aiutarti a rilevare questa incoerenza.

Le repliche di lettura vengono fatturate come nodi di cache standard e prevedono le stesse tariffe. Analogamente ai nodi di cache standard, la tariffa basata sulle “ore-nodo di cache” per le repliche di lettura è determinata dalla classe del nodo di cache della replica di lettura; consulta la pagina dei prezzi di ElastiCache per informazioni aggiornate. I trasferimenti di dati generati durante la replica dei dati tra il nodo di cache e la replica di lettura non vengono fatturati. La fatturazione di una replica di lettura inizia subito dopo la sua creazione (dal momento in cui il suo stato è "attivo"). La fatturazione della replica di lettura proseguirà secondo le tariffe orarie standard per i nodi di cache di ElastiCache finché non viene inviato il comando di eliminazione.

Il failover avviato è supportato da ElastiCache in modo da poter riprendere le operazioni di cache al più presto. Durante l'esecuzione di un failover, ElastiCache cambia il record DNS per il nodo di cache in modo che punti alla replica di lettura, che diventa a sua volta il nuovo nodo principale. Ti consigliamo di seguire le migliori prassi e di implementare i tentativi di connessione al nodo di cache a livello di applicazione. In genere, dall'inizio alla fine, i passaggi da uno a cinque vengono completati entro sei minuti.

Questi sono gli eventi di failover automatico, elencati in ordine di ricorrenza:

  1. Messaggio del gruppo di replica: API Test Failover chiamata per il gruppo di nodi <node-group-id>
  2. Messaggio del cluster di cache: failover dal nodo primario <primary-node-id> al nodo di replica <node-id> completato
  3. Messaggio del gruppo di replica: failover dal nodo primario <primary-node-id> al nodo di replica <node-id> completato
  4. Messaggio del cluster di cache: recupero dei nodi di cache <node-id>
  5. Messaggio del cluster di cache: ripristino dei nodi di cache <id-nodo> terminato

No. Puoi effettuare il provisioning della replica di lettura solo nella stessa zona di disponibilità o in un'altra zona di disponibilità della stessa regione del nodo di cache primario. Tuttavia, puoi utilizzare Datastore globale per lavorare con una replica veloce, affidabile, sicura e completamente gestita in più regioni AWS. Utilizzando questa funzionalità, puoi creare cluster di repliche di lettura in più regioni per ElastiCache per abilitare letture e ripristino di emergenza a bassa latenza in più regioni AWS.

Sì. Per ottenere maggiore visibilità sulla posizione del nodo primario, utilizza la console o l'API DescribeCacheClusters.

Sì. Si possono aggiungere e rimuovere le repliche tra una o più partizioni in un ambiente cluster. Sì, il cluster rimarrà online ed elaborerà gli I/O in ingresso durante l'operazione.

Multi-AZ

Multi-AZ è una funzionalità che consente di eseguire una configurazione a disponibilità più elevata quando si progetta la propria cache ElastiCache. Tutte le cache ElastiCache serverless vengono eseguite automaticamente in una configurazione Multi-AZ. Un gruppo di replica ElastiCache consiste in un nodo principale e fino a cinque repliche di lettura. Se la funzione Multi-AZ è abilitata, è necessaria almeno una replica per nodo principale. Durante determinati interventi di manutenzione pianificati oppure nell'eventualità di un errore del nodo ElastiCache o della zona di disponibilità, ElastiCache rileva automaticamente l'errore del nodo principale, seleziona una replica di lettura e la converte nel nuovo nodo principale. Inoltre ElastiCache converte le modifiche DNS della replica di lettura convertita, in modo che, se l'applicazione scrive sull'endpoint del nodo principale, nessun cambiamento di endpoint sarà necessario.

I vantaggi principali di eseguire ElastiCache in modalità Multi-AZ sono l'aumentata disponibilità e l'amministrazione ridotta. Quando si esegue ElastiCache in una configurazione Multi-AZ, le cache sono idonee per lo SLA di disponibilità del 99,99%. In caso di errore del nodo principale di ElastiCache, l'impatto sulla capacità di lettura e scrittura sul nodo principale è limitato al periodo durante il quale viene effettuato il failover automatico. Quando Multi-AZ è attivo, il failover del nodo ElastiCache è automatico e non richiede nessuna gestione. 

Puoi utilizzare Multi-AZ se usi ElastiCache e hai un gruppo di replica che consiste in un nodo principale e una o più repliche di lettura. In caso di errore del nodo principale, ElastiCache rileva automaticamente l'errore, seleziona una delle repliche di lettura disponibili e la converte in nodo principale. ElastiCache converte le modifiche DNS della replica di lettura convertita, in modo che l'applicazione continui a scrivere sull'endpoint principale. ElastiCache creerà un nuovo nodo per sostituire la replica di lettura convertita nella stessa zona di disponibilità del nodo principale con errore. In caso di errore del nodo principale dovuto a un'interruzione nella zona di disponibilità, la nuova replica verrà lanciata non appena la zona di disponibilità sarà ripristinata.

Sì. Collocare il nodo principale e le repliche nella stessa zona di disponibilità non garantisce la resistenza del gruppo di repliche di ElastiCache a interruzioni nella zona di disponibilità. Inoltre, la presenza di repliche nella stessa zona di disponibilità della principale non sarà consentita se Multi-AZ è attivato.

Un failover di ElastiCache su una replica di lettura può avvenire in uno dei casi seguenti:

  • Perdita di disponibilità nella zona di disponibilità del nodo principale
  • Perdita di connettività di rete nell'istanza principale
  • Errore dell'unità di elaborazione nell'istanza principale

Se esiste più di una replica di lettura, viene convertita la replica di lettura che presenta il ritardo di replica asincrona minore rispetto al nodo primario.

Sì, ElastiCache crea un evento per informarti che è stato effettuato un failover automatico. Puoi usare l'API DescribeEvents per raccogliere informazioni sugli eventi relativi al tuo nodo ElastiCache o selezionare la sezione “Eventi” della console di gestione ElastiCache.

Le zone di disponibilità sono state progettate in modo da connettersi tra loro in rete con una latenza minima all'interno della stessa regione. Potrebbe essere opportuno progettare la propria applicazione e organizzare le altre risorse AWS in modo che offrano ridondanza su più zone di disponibilità, consentendo una maggiore resilienza dell'applicazione in caso di errore in una zona di disponibilità.

Per ulteriori informazioni su Multi-AZ, consulta la documentazionedi ElastiCache.

Backup e ripristino

La funzionalità di backup e ripristino è una funzionalità che consente di creare snapshot delle cache di ElastiCache. ElastiCache memorizza gli snapshot, permettendo agli utenti di utilizzarli per ripristinare le cache. Attualmente è supportato con ElastiCache per Valkey, ElastiCache per Redis OSS e serverless. 

Creare snapshot può risultare utile in caso di perdite di dati causate da errori di un nodo, oppure nell'improbabile eventualità di un guasto all'hardware. Un altro caso d'uso comune degli snapshot è la creazione di backup e l'archiviazione. Gli snapshot vengono memorizzati in Amazon S3.

Quando si avvia il backup, ElastiCache esegue lo snapshot di una cache specifica che potrà essere utilizzato in un secondo momento per il ripristino o l'archiviazione. Si può avviare il backup ogni volta che si desidera o impostare un backup ricorrente giornaliero con un periodo di memorizzazione di 35 giorni. Quando si seleziona uno snapshot da ripristinare, verrà creata una nuova cache ElastiCache e vi saranno inseriti i dati dello snapshot. Le istantanee ElastiCache sono compatibili con il formato file RDB di Redis OSS.

Puoi utilizzare la funzionalità di backup e ripristino tramite la console, le API ElastiCache e l'interfaccia a riga di comando di AWS. Puoi disattivare e riattivare questa funzionalità a piacimento.

La funzionalità di backup e ripristino crea degli snapshot basati sulla cache. Gli utenti possono specificare la cache di ElastiCache di cui eseguire il backup tramite la console, l'interfaccia a riga di comando AWS o l'API ElastiCache. Consigliamo agli utenti di abilitare il backup su una delle repliche di lettura della cache, riducendo al minimo qualsiasi potenziale impatto sul nodo principale. Quando si utilizza ElastiCache serverless, i backup vengono eseguiti automaticamente sulle repliche di lettura.

È possibile esportare snapshot di ElastiCache in un bucket S3 autorizzato nella stessa regione della cache.

Sì. Devi copiare lo snapshot in un qualsiasi bucket S3 autorizzato nella stessa Regione, quindi concedere i privilegi di accesso tra più account all'altro account.

ElastiCache offre spazio di archiviazione gratuito per uno snapshot per ogni cluster ElastiCache attivo. Lo spazio di archiviazione aggiuntivo verrà addebitato sulla base dello spazio utilizzato dagli snapshot con 0,085 USD/GB al mese (stesso prezzo per tutte le regioni). Per gli snapshot non sarà addebitato alcun costo per il trasferimento di dati.

Quando si elimina una cache ElastiCache, gli snapshot manuali vengono mantenuti. Hai anche la possibilità di creare uno snapshot finale prima di eliminare la cache. Gli snapshot di cache automatici non vengono conservati.

Miglioramenti al motore

Il motore in ElastiCache è completamente compatibile con Redis OSS, ma racchiude anche alcuni miglioramenti che ne potenziano prestazioni, affidabilità e stabilità. Ad esempio:

  • Possibilità di utilizzare più memoria: è possibile allocare maggiori volumi di memoria all'applicazione senza rischiare picchi di swapping durante sincronizzazioni e snapshot.
  • Sincronizzazione migliorata: la sincronizzazione è più affidabile, in particolare con carichi di lavoro onerosi e durante il ripristino in seguito a interruzioni di rete. Inoltre, le sincronizzazioni sono più rapide, perché sia il nodo principale sia le repliche non avvengono più su disco.
  • Failover più lineari: in caso di failover, la partizione viene ripristinata più rapidamente, perché le repliche non devono più scaricare i dati per completare una risincronizzazione completa col nodo principale.
  • Offload TLS e multiplexing IO: ElastiCache è progettato per utilizzare meglio le risorse della CPU disponibili gestendo determinati processi relativi alla rete su thread dedicati.

No. Il motore migliorato è completamente compatibile con Redis OSS, perciò potrai sfruttarne l'affidabilità e la stabilità senza apportare alcuna modifica al codice della tua applicazione.

Non sono previsti costi aggiuntivi per l'utilizzo del motore migliorato.

Crittografia

La crittografia a riposo offre meccanismi di protezione dall'accesso non autorizzato ai dati. Se abilitato, crittografa i seguenti aspetti:

  • Disco durante le operazioni di sincronizzazione, backup e swapping
  • Backup archiviati in Amazon S3

ElastiCache offre la crittografia a riposo predefinita (gestita dal servizio) oltre alla possibilità di utilizzare le proprie chiavi AWS KMS simmetriche gestite dal cliente in AWS KMS. Consulta la pagina Crittografia a riposo per saperne di più.

La funzionalità di crittografia in transito facilita la crittografia delle comunicazioni tra client ed ElastiCache, nonché tra i server (repliche primarie e di lettura). Scopri di più sulla crittografia in transito di ElastiCache.

Crittografia in transito, crittografia a riposo, Redis OSS AUTH e Role-Based Access Control (RBAC) sono funzionalità che puoi selezionare quando crei la cache di ElastiCache. Abilitando la crittografia in transito puoi scegliere di utilizzare Redis OSS AUTH o RBAC, per una maggiore sicurezza e il controllo degli accessi.

No. ElastiCache gestisce scadenza e rinnovo delle certificazioni dietro le quinte. Non sono necessarie azioni da parte dell'utente per la manutenzione continuativa dei certificati.

No, non verrà addebitato alcun costo aggiuntivo per l'utilizzo della crittografia.

Global Datastore

Il datastore globale è una funzionalità di ElastiCache che offre repliche rapide, affidabili, sicure e interamente gestite in più regioni. Con il datastore globale, è possibile scrivere nella cache in una regione e disporre dei dati per la lettura in altri due cluster di replica in più regioni. Questa funzionalità ti permette così di beneficiare di letture a bassa latenza e di operazioni di ripristino di emergenza in più regioni.

Progettata per applicazioni in tempo reale, la funzionalità datastore globale in genere replica i dati in più regioni, in meno di un secondo, incrementando la reattività dell'applicazione, grazie alla fornitura di letture geolocalizzate più vicine agli utenti finali. Nell'improbabile eventualità di un calo delle prestazioni a livello regionale, è possibile promuovere uno dei cluster di replica integri in più regioni a cluster primario con funzionalità di lettura e scrittura complete. Una volta avviata, sarà necessario meno di un minuto per il completamento della promozione. Ciò consente alle applicazioni di conservare la loro disponibilità.

Le repliche si possono effettuare al massimo in due regioni secondarie nell'ambito del datastore globale per Redis. Le cache situate nelle regioni secondarie possono essere utilizzati per gestire letture locali a bassa latenza e per il ripristino di emergenza, nell'improbabile eventualità di un calo delle prestazioni a livello regionale.

Il datastore globale è supportato su ElastiCache per Redis 5.0.6 e versioni successive.

No, ElastiCache non promuove automaticamente un cluster secondario in caso di riduzione delle prestazioni del cluster (Regione) principale. Puoi avviare manualmente il failover promuovendo un cluster secondario in modo che diventi quello primario. Il failover e la promozione del cluster secondario in genere vengono completati in meno di un minuto.

Il datastore globale utilizza la crittografia in transito per il traffico tra regioni per mantenere i dati al sicuro. Inoltre, puoi crittografare le cache principali e secondarie utilizzando la crittografia a riposo per garantire la protezione completa dei dati. Ogni cache primaria e secondaria può avere una chiave AWS KMS separata gestita dal cliente per la crittografia a riposo.

ElastiCache non fornisce un contratto sul livello di servizio per RPO e RTO. Il parametro RPO varia in base al ritardo della replica tra Regioni e dipende dalla latenza di rete tra Regioni e dalla congestione del traffico di rete tra Regioni. L'RPO del datastore globale in genere è inferiore a un secondo, quindi i dati scritti nella regione principale sono disponibili nelle regioni secondarie entro un secondo. L'RTO of Global Datastore è in genere inferiore a un minuto. Dopo l'avvio del failover su un cluster secondario, ElastiCache in genere lo promuove per le funzionalità di lettura e scrittura in meno di un minuto.

ElastiCache non fornisce un contratto sul livello di servizio per RPO e RTO. Il parametro RPO varia in base al ritardo della replica tra Regioni e dipende dalla latenza di rete tra Regioni e dalla congestione del traffico di rete tra Regioni. L'RPO del datastore globale in genere è inferiore a un secondo, quindi i dati scritti nella regione principale sono disponibili nelle regioni secondarie entro un secondo. L'RTO of Global Datastore è in genere inferiore a un minuto. Dopo l'avvio del failover su un cluster secondario, ElastiCache in genere lo promuove per le funzionalità di lettura e scrittura in meno di un minuto.

Suddivisione in livelli dei dati

Utilizzando gli SSD in ogni nodo del cluster oltre ad archiviare i dati in memoria, la suddivisione in livelli dei dati rappresenta un'ottima opzione in termini di prezzo/prestazioni. Per i carichi di lavoro che hanno regolarmente accesso fino al 20% del loro set di dati generale e per le applicazioni che possono sopportare ulteriore latenza quando accedono ai dati su SSD. I nodi R6gd ElastiCache con memoria e SSD hanno una capacità totale di archiviazione circa cinque volte superiore e possono aiutarti a risparmiare fino al 60% se eseguiti al massimo dell'utilizzo rispetto ai nodi R6g ElastiCache con sola memoria.

Il livello dei dati funziona spostando in modo automatico e trasparente gli elementi utilizzati meno recentemente dalla memoria agli SSD NVMe attaccati localmente quando viene utilizzata completamente la capacità di memoria. Quando si accede a un elemento appena spostato sull'SSD, ElastiCache lo sposta di nuovo in memoria in modo asincrono prima di servire la richiesta.

I livelli dei dati sono progettati per ottenere un impatto minimo sulle prestazioni dell'applicazione. Ipotizzando valori di stringa da 500 byte, ci si può aspettare una latenza aggiuntiva di 300 µs in media per le richieste ai dati memorizzati su SSD rispetto a quelli in memoria.

ElastiCache supporta i livelli dei dati per le versioni 6.2 o superiori di ElastiCache per Redis OSS.

ElastiCache supporta i livelli dei dati su cluster che utilizzano nodi R6gd.

Tutti i comandi di Valkey e Redis OSS e la maggior parte delle funzionalità di ElastiCache sono supportate quando si utilizzano i livelli dei dati. Consulta questo documento per un elenco delle funzionalità che non sono supportate nei cluster che utilizzano i livelli dei dati.

Non sono previsti costi aggiuntivi per l'utilizzo dei livelli dei dati oltre al costo orario del nodo. I nodi con i livelli dei dati sono disponibili con un costo on demand e come nodi riservati. Per informazioni sui costi, consulta la pagina dei prezzi di ElastiCache.