Procedure e best practice comuni per la risoluzione dei problemi

Problemi di connessione

Se non riesci a connetterti alla ElastiCache cache, prendi in considerazione una delle seguenti opzioni:

1. Utilizzo di TLS: se si verifica un blocco della connessione durante il tentativo di connessione all' ElastiCache endpoint, è possibile che non si stia utilizzando TLS nel client. Se utilizzi ElastiCache Serverless, la crittografia in transito è sempre abilitata. Assicurati che il tuo client utilizzi TLS per connettersi alla cache. Scopri di più sulla connessione a una cache abilitata per TLS qui.

2. VPC: le ElastiCache cache sono accessibili solo dall'interno di un VPC. Assicurati che l'istanza EC2 da cui accedi alla cache e la ElastiCache cache siano create nello stesso VPC. In alternativa, devi abilitare il peering VPC tra il VPC in cui risiede l'istanza EC2 e il VPC in cui stai creando la cache.

3. Gruppi di sicurezza: ElastiCache utilizza i gruppi di sicurezza per controllare l'accesso alla cache. Considera i seguenti aspetti:

   1. Assicurati che il gruppo di sicurezza utilizzato dalla ElastiCache cache consenta l'accesso in entrata dalla tua istanza EC2. Leggi qui per scoprire come configurare correttamente le regole in entrata nel tuo gruppo di sicurezza.

   2. Assicurati che il gruppo di sicurezza utilizzato dalla ElastiCache cache consenta l'accesso alle porte della cache (6379 e 6380 per le versioni serverless e 6379 per impostazione predefinita per quelle progettate autonomamente). ElastiCache utilizza queste porte per accettare i comandi Redis OSS. Scopri di più su come configurare l'accesso alle porte qui.

Errori del client Redis OSS

ElastiCache Serverless è accessibile solo tramite client Redis OSS che supportano il protocollo in modalità cluster Redis OSS. È possibile accedere ai cluster progettati autonomamente dai client Redis OSS in entrambe le modalità, a seconda della configurazione del cluster.

Se riscontri errori Redis OSS nel tuo client, considera quanto segue:

1. Modalità cluster: se si verificano errori CROSSLOT o errori con il comando SELECT Redis OSS, è possibile che si stia tentando di accedere a una cache Cluster Mode Enabled con un client Redis OSS che non supporta il protocollo Redis OSS Cluster. ElastiCache Serverless supporta solo i client Redis OSS che supportano il protocollo cluster Redis OSS. Se desideri utilizzare Redis OSS in «Cluster Mode Disabled» (CMD), devi progettare il tuo cluster.

2. Errori CROSSLOT: se si verifica l'ERR CROSSLOT Keys in request don't hash to the same sloterrore, è possibile che si stia tentando di accedere a chiavi che non appartengono allo stesso slot in una cache in modalità Cluster. Come promemoria, ElastiCache Serverless funziona sempre in modalità Cluster. Le operazioni a più chiavi, le transazioni o gli script Lua che coinvolgono più chiavi sono consentite solo se tutte le chiavi coinvolte si trovano nello stesso slot di hash.

Per ulteriori best practice sulla configurazione dei client Redis OSS, consulta questo post sul blog.

Risoluzione dei problemi di latenza elevata in Serverless ElastiCache

Se il tuo carico di lavoro sembra presentare un'elevata latenza, puoi analizzare le SuccessfulWriteRequestLatency metriche CloudWatch SuccessfulReadRequestLatency e per verificare se la latenza è correlata a Serverless. ElastiCache Queste metriche misurano la latenza interna a ElastiCache Serverless: la latenza lato client e i tempi di viaggio di rete tra il client e l'endpoint Serverless non sono inclusi. ElastiCache

Risoluzione dei problemi di latenza lato client

Se notate una latenza elevata sul lato client ma nessun aumento corrispondente CloudWatch SuccessfulReadRequestLatency e SuccessfulWriteRequestLatency metriche che misurano la latenza lato server, considerate quanto segue:

• Assicurati che il gruppo di sicurezza consenta l'accesso alle porte 6379 e 6380: ElastiCache Serverless utilizza la porta 6379 per l'endpoint primario e la porta 6380 per l'endpoint del lettore. Alcuni client stabiliscono la connettività a entrambe le porte per ogni nuova connessione, anche se l'applicazione non utilizza la funzionalità Read from Replica. Se il gruppo di sicurezza non consente l'accesso in entrata a entrambe le porte, la creazione della connessione può richiedere più tempo. Scopri di più su come configurare l'accesso alle porte qui.

Risoluzione dei problemi di latenza lato server

Alcune variabilità e i picchi occasionali non dovrebbero essere motivo di preoccupazione. Tuttavia, se la Average statistica mostra un forte aumento e persiste, dovresti controllare la Personal Health Dashboard AWS Health Dashboard e la tua Personal Health Dashboard per ulteriori informazioni. Se necessario, valuta la possibilità di aprire una richiesta di supporto con. AWS Support

Prendi in considerazione le seguenti best practice e strategie per ridurre la latenza:

• Abilita Read from Replica: se la tua applicazione lo consente, ti consigliamo di abilitare la funzionalità «Read from Replica» nel tuo client Redis OSS per scalare le letture e ottenere una latenza inferiore. Se abilitata, ElastiCache Serverless tenta di indirizzare le richieste di lettura verso i nodi di cache di replica che si trovano nella stessa zona di disponibilità (AZ) del client, evitando così la latenza di rete Cross-AZ. Tieni presente che l'attivazione della funzionalità Read from Replica nel client significa che l'applicazione accetta l'eventuale coerenza dei dati. L'applicazione potrebbe ricevere dati più vecchi per qualche tempo se si tenta di leggere dopo aver scritto su una chiave.

• Assicurati che l'applicazione sia distribuita nelle stesse AZ della cache: potresti osservare una latenza lato client più elevata se l'applicazione non è distribuita negli stessi AZ della cache. Quando si crea una cache serverless, è possibile fornire le sottoreti da cui l'applicazione accederà alla cache e ElastiCache Serverless crea endpoint VPC in tali sottoreti. Assicurati che l'applicazione sia distribuita nelle stesse AZ. In caso contrario, l'applicazione potrebbe subire un hop Cross-AZ quando accede alla cache, con conseguente maggiore latenza lato client.

• Riutilizza le connessioni: le richieste ElastiCache serverless vengono effettuate tramite una connessione TCP abilitata per TLS utilizzando il protocollo RESP. L'avvio della connessione (inclusa l'autenticazione della connessione, se configurata) richiede tempo, quindi la latenza della prima richiesta è superiore a quella tipica. Le richieste su una connessione già inizializzata offrono ElastiCache una latenza costantemente bassa. Per questo motivo, dovresti prendere in considerazione l'utilizzo del pool di connessioni o il riutilizzo delle connessioni Redis OSS esistenti.

• Velocità di scalabilità: ElastiCache Serverless si ridimensiona automaticamente all'aumentare della frequenza delle richieste. Un aumento improvviso e significativo della frequenza di richieste, superiore alla velocità di scalabilità di ElastiCache Serverless, può comportare una latenza elevata per qualche tempo. ElastiCache In genere, Serverless può aumentare rapidamente la frequenza di richieste supportata, impiegando fino a 10-12 minuti per raddoppiare la frequenza delle richieste.

• Ispeziona i comandi a esecuzione prolungata: alcuni comandi Redis OSS, inclusi gli script Lua o i comandi su strutture di dati di grandi dimensioni, possono essere eseguiti a lungo. Per identificare questi comandi, ElastiCache pubblica metriche a livello di comando. Con ElastiCache Serverless puoi usare le metriche. BasedECPUs

• Richieste limitate: quando le richieste vengono limitate in ElastiCache Serverless, è possibile che si verifichi un aumento della latenza lato client nell'applicazione. Quando le richieste vengono limitate in ElastiCache Serverless, dovresti notare un aumento della metrica Serverless. ThrottledRequests ElastiCache Consulta la sezione seguente per la risoluzione dei problemi relativi alle richieste limitate.

• Distribuzione uniforme di chiavi e richieste: in ElastiCache (Redis OSS), una distribuzione non uniforme di chiavi o richieste per slot può causare un hot slot con conseguente latenza elevata. ElastiCache Serverless supporta fino a 30.000 ECPU al secondo (90.000 ECPU al secondo quando si utilizza Read from Replica) su un singolo slot, in un carico di lavoro che esegue semplici comandi SET/GET. Ti consigliamo di valutare la distribuzione delle chiavi e delle richieste tra gli slot e di garantire una distribuzione uniforme se la frequenza delle richieste supera questo limite.

Risoluzione dei problemi di limitazione in Serverless ElastiCache

Nelle architetture orientate ai servizi e nei sistemi distribuiti, la limitazione della velocità con cui le chiamate API vengono elaborate dai vari componenti del servizio si chiama limitazione (della larghezza di banda della rete). Ciò attenua i picchi, controlla le discrepanze nella velocità di trasmissione dei componenti e consente ripristini più prevedibili in caso di eventi operativi imprevisti. ElastiCache Serverless è progettato per questi tipi di architetture e la maggior parte dei client Redis OSS dispone di nuovi tentativi integrati per le richieste limitate. Un certo grado di limitazione (della larghezza di banda della rete) non è necessariamente un problema per l'applicazione, ma una limitazione (della larghezza di banda della rete) persistente di una parte sensibile alla latenza del flusso di lavoro dei dati può influire negativamente sull'esperienza dell'utente e ridurre l'efficienza complessiva del sistema.

Quando le richieste vengono limitate in Serverless, dovresti notare un aumento della ElastiCache metrica Serverless. ThrottledRequests ElastiCache Se notate un numero elevato di richieste limitate, considerate quanto segue:

• Velocità di scalabilità: ElastiCache Serverless si ridimensiona automaticamente man mano che si acquisiscono più dati o si aumenta la frequenza delle richieste. Se l'applicazione si adatta più velocemente della scalabilità Serverless, le richieste potrebbero essere limitate mentre ElastiCache Serverless si ridimensiona per adattarsi al carico di lavoro. ElastiCache ElastiCache In genere, la modalità serverless consente di aumentare rapidamente le dimensioni di storage, impiegando fino a 10-12 minuti per raddoppiare le dimensioni di archiviazione nella cache.

• Distribuzione uniforme di chiavi e richieste: in ElastiCache (Redis OSS), una distribuzione non uniforme delle chiavi o delle richieste per slot può causare un hot slot. Un hot slot può comportare una limitazione delle richieste se la frequenza delle richieste verso un singolo slot supera le 30.000 ECPU al secondo, in un carico di lavoro che esegue semplici comandi SET/GET.

• Leggi dalla replica: se l'applicazione lo consente, valuta la possibilità di utilizzare la funzione «Leggi dalla replica». La maggior parte dei client Redis OSS può essere configurata per «scalare le letture» per indirizzare le letture ai nodi di replica. Questa funzionalità consente di scalare il traffico di lettura. Inoltre, ElastiCache Serverless indirizza automaticamente la lettura dalle richieste di replica ai nodi nella stessa zona di disponibilità dell'applicazione, con conseguente riduzione della latenza. Quando Read from Replica è abilitato, è possibile ottenere fino a 90.000 ECPU al secondo su un singolo slot, per carichi di lavoro con semplici comandi SET/GET.

Argomenti correlati

• Ulteriori passaggi per la risoluzione dei problemi

• ElastiCache migliori pratiche e strategie di caching