Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Procedure di risoluzione dei problemi e procedure consigliate comuni con ElastiCache
I seguenti argomenti forniscono consigli per la risoluzione di errori e problemi che potrebbero verificarsi durante l'utilizzo. ElastiCache Se trovi un problema che non è elencato qui, puoi utilizzare il pulsante di feedback in questa pagina per segnalarlo.
Per ulteriori consigli sulla risoluzione dei problemi e risposte alle domande di supporto più comuni, visita il AWS Knowledge Center
Argomenti
Problemi di connessione
Se non riesci a connetterti alla ElastiCache cache, prendi in considerazione una delle seguenti opzioni:
UsoTLS: se si verifica un blocco della connessione durante il tentativo di connessione all' ElastiCache endpoint, è possibile che non sia TLS in uso nel client. Se utilizzi ElastiCache Serverless, la crittografia in transito è sempre abilitata. Assicurati che il client utilizzi TLS per connettersi alla cache. Scopri di più sulla connessione a una cache TLS abilitata.
VPC: ElastiCache le cache sono accessibili solo dall'interno di unVPC. Assicurati che l'EC2istanza da cui accedi alla cache e la ElastiCache cache siano create nella stessaVPC. In alternativa, devi abilitare il VPCpeering tra il VPC luogo in cui risiede l'EC2istanza e il VPC luogo in cui stai creando la cache.
Gruppi di sicurezza: ElastiCache utilizza i gruppi di sicurezza per controllare l'accesso alla cache. Considera i seguenti aspetti:
Assicurati che il gruppo di sicurezza utilizzato dalla ElastiCache cache consenta l'accesso in entrata dalla tua EC2 istanza. Vedi qui per scoprire come configurare correttamente le regole in entrata nel tuo gruppo di sicurezza.
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 Valkey o Redis. OSS Scopri di più su come configurare l'accesso alle porte qui.
Se la connessione continua a essere difficile, consulta Problemi di connessione persistenti gli altri passaggi.
Errori del client Valkey o Redis OSS
ElastiCache Serverless è accessibile solo tramite client che supportano il protocollo in modalità cluster Valkey o RedisOSS. È possibile accedere ai cluster progettati autonomamente dai client in entrambe le modalità, a seconda della configurazione del cluster.
Se riscontri errori nel tuo client, considera quanto segue:
Modalità cluster: se si verificano CROSSLOT errori o errori con il SELECT
comando, è possibile che si stia tentando di accedere a una cache abilitata alla modalità cluster con un OSS client Valkey o Redis che non supporta il protocollo Cluster. ElastiCache Serverless supporta solo client che supportano il protocollo cluster Valkey o Redis. OSS Se desideri utilizzare Valkey o Redis OSS in «Cluster Mode Disabled» (CMD), devi progettare il tuo cluster. CROSSLOTerrori: 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.
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 OSS client Valkey o Redis per scalare le letture e ottenere una latenza inferiore. Se abilitata, ElastiCache Serverless tenta di indirizzare le richieste di lettura ai 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 nella AZs stessa cache: potresti osservare una maggiore latenza lato client se l'applicazione non è distribuita nella AZs stessa cache. Quando crei una cache serverless, puoi fornire le sottoreti da cui l'applicazione accederà alla cache e ElastiCache Serverless crea endpoint in tali sottoreti. VPC Assicurati che l'applicazione sia distribuita nella stessa. AZs 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 TLS connessione abilitata che utilizza il protocollo. TCP 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 Valkey o Redis esistenti. OSS
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 Valkey o Redis, inclusi gli script Lua o OSS i comandi su strutture di dati di grandi dimensioni, possono essere eseguiti a lungo. Per identificare questi comandi, pubblica metriche a livello di comando. ElastiCache Con ElastiCache Serverless puoi usare le metriche.
BasedECPUsRichieste 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: ElastiCache con Valkey e RedisOSS, una distribuzione non uniforme di chiavi o richieste per slot può comportare un hot slot che può comportare una latenza elevata. ElastiCache Serverless supporta fino a 30.000 al ECPUs secondo (90.000 al ECPUs 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 throttling in Serverless ElastiCache
Nelle architetture orientate ai servizi e nei sistemi distribuiti, la limitazione della velocità con cui le API chiamate vengono elaborate dai vari componenti del servizio si chiama throttling. 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 Valkey o Redis dispone di nuovi tentativi integrati per le richieste limitate. OSS 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 metrica ElastiCache 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: ElastiCache con Valkey o RedisOSS, 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 30.000 ECPUs /secondo, in un carico di lavoro che esegue semplici comandi/. SET GET
Leggi dalla replica: se l'applicazione lo consente, prendi in considerazione l'utilizzo della funzione «Leggi dalla replica». La maggior parte dei OSS client Valkey o Redis 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 unità al ECPUs secondo su un singolo slot, per carichi di lavoro con semplici comandi/. SET GET
Argomenti correlati
