Domande frequenti su Amazon ElastiCache

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.

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.

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.

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:

• Conformità con ElastiCache
• Pagina sulla conformità di AWS allo standard PCI

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:

• Conformità con ElastiCache
• Conformità con AWS FedRAMP

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

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.

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

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.

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

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.

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.

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.

ElastiCache non richiede librerie client specifiche e funziona con le librerie client Memcached esistenti senza ricompilazione o ricollegamento delle applicazioni (Memcached 1.4.5 e versioni successive). Gli esempi includono libMemCached (C) e le librerie basate su di essa (ad esempio, PHP, Perl, Python), SpyMemCached (Java) e fauna (Ruby).

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.

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.

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.

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

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.

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.

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.

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.

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.