Come posso risolvere i problemi di latenza elevata sui cluster DynamoDB Accelerator (DAX)?

Risoluzione

Esistono vari motivi per cui potresti riscontrare una latenza nelle tue richieste. Per risolvere i problemi di latenza fai riferimento a ciascuno dei potenziali problemi riportati di seguito.

Il cluster o il nodo presenta un carico elevato

La latenza è spesso causata da un cluster o da un nodo che si trova a gestire un carico elevato sul cluster DAX. Questa latenza può essere ulteriormente compromessa se il client è configurato su un URL a nodo singolo anziché sull'URL del cluster. In questo caso, se il nodo presenta problemi durante un carico elevato, le richieste del client subiscono latenza o limitazione (della larghezza di banda della rete).

Per risolvere la latenza e la limitazione (della larghezza di banda della rete) causate da un carico elevato su singoli cluster o nodi, utilizza la scalabilità orizzontale o la scalabilità verticale.

Configurazione errata nel client DAX

Se riduci il parametro WithMinIdleConnectionSize, è probabile che la latenza nel cluster DAX aumenti. Questo parametro imposta il numero minimo di connessioni inattive con il cluster DAX. Per ogni richiesta, il client utilizzerà una connessione inattiva disponibile. Se una connessione non è disponibile, il client ne stabilisce una nuova. Ad esempio, se il parametro è impostato su 20, esistono almeno 20 connessioni inattive con il cluster DAX.

Il client mantiene un pool di connessioni. Quando un'applicazione effettua una chiamata API a DynamoDB o DAX, il client ottiene una connessione in lease dal pool di connessioni. Quindi, il client effettua la chiamata API e restituisce la connessione al pool. Tuttavia, il pool di connessioni ha un limite massimo. Se effettui un numero elevato di chiamate API a DAX contemporaneamente, è possibile che queste superino il limite del pool di connessioni. In questo caso, alcune richieste devono attendere il completamento di altre richieste prima di ottenere lease dal pool di connessioni. Ciò comporta l'accodamento delle richieste a livello di pool di connessioni. Di conseguenza, l'applicazione registra un aumento della latenza di andata e ritorno.

Pertanto, per ridurre i picchi di traffico ricorrenti nell'applicazione, regola i parametri setMinIdleConnectionSize, getMinIdleConnectionSize e withMinIdleConnectionSize. Questi parametri svolgono un ruolo importante nella latenza di un cluster DAX. Configurali per le tue chiamate API in modo che DAX utilizzi un numero appropriato di connessioni inattive senza la necessità di ristabilire nuove connessioni.

Elementi mancanti nella cache

Se in una richiesta di lettura manca un elemento, DAX invia la richiesta a DynamoDB. DynamoDB elabora le richieste utilizzando letture a consistenza finale e quindi restituisce gli elementi a DAX. DAX li archivia nella cache degli elementi e quindi li restituisce all'applicazione. La latenza nella tabella DynamoDB sottostante può causare latenza nella richiesta.

Gli errori di cache si verificano generalmente per due motivi:

1.    Elevata consistenza di lettura: le letture ad elevata consistenza per lo stesso elemento non vengono memorizzate nella cache da DAX. Ciò comporta un errore della cache perché le voci ignorano DAX e vengono recuperate direttamente dalla tabella DynamoDB. Per risolvere questo problema puoi utilizzare le lettura a consistenza finale, ma tieni presente che DynamoDB deve prima leggere i dati affinché questi vengano memorizzati nella cache.

2.    Policy di espulsione in DAX: i dati interrogati che sono già stati rimossi dalla cache generano un errore. DAX utilizza tre valori diversi per determinare le espulsioni della cache:

• I cluster DAX utilizzano un algoritmo LRU (Least Recently Used) per assegnare una priorità agli elementi. Gli elementi con la priorità più bassa vengono espulsi quando la cache è piena.
• DAX utilizza un valore TTL (Time-to-Live) per il periodo di tempo in cui gli elementi sono disponibili nella cache. Dopo che il valore TTL di un elemento è stato superato, l'elemento viene espulso.
  Nota: se utilizzi il valore TTL predefinito di cinque minuti, controlla se stai interrogando i dati dopo il periodi di tempo TTL.
• DAX utilizza la funzionalità write-through per espellere i valori più vecchi man mano che ne vengono scritti di nuovi. Questo consente di mantenere la cache degli elementi DAX coerente con il datastore sottostante utilizzando una sola chiamata API.

Per estendere il valore TTL dei tuoi elementi, consulta Configurazione delle impostazioni TTL.
Nota: non è possibile modificare un gruppo di parametri mentre è in uso in un'istanza DAX in esecuzione.

Gli errori di cache possono verificarsi anche quando le patch di manutenzione vengono applicate a un cluster DAX. Per ridurre questi tempi di inattività, utilizza cluster a più nodi.

Finestre di manutenzione

Durante le finestre di manutenzione settimanali potrebbero verificarsi casi di latenza, soprattutto in caso di aggiornamenti software, patch o modifiche di sistema ai nodi del cluster. Nella maggior parte dei casi, le richieste vengono gestite correttamente da altri nodi disponibili che non sono sottoposti a manutenzione. Un cluster con un numero elevato di richieste durante interventi di manutenzione intensivi può riscontrare errori.

Per ridurre le possibilità di latenza o guasti, configura la finestra di manutenzione evitando gli orari di punta. In questo modo consentirai al cluster di eseguire l'aggiornamento durante un periodo di minore carico delle richieste.

Latenza nella tabella DynamoDB

Con le operazioni di scrittura, i dati vengono prima scritti nella tabella DynamoDB e poi nel cluster DAX. L'operazione ha esito positivo solo se i dati vengono scritti correttamente sia nella tabella che in DAX. La latenza nella tabella DynamoDB sottostante può causare latenza nella richiesta. Per ridurre questa latenza, consulta How can I troubleshoot high latency on an Amazon DynamoDB table? (Come posso risolvere i problemi di latenza elevata in una tabella Amazon DynamoDB?)

Per configurare ulteriormente DynamoDB in base ai requisiti di latenza della tua applicazione, consulta la pagina Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications (Ottimizzazione delle impostazioni delle richieste HTTP di AWS Java SDK per le applicazioni Amazon DynamoDB sensibili alla latenza).

Periodo di timeout della richiesta

Il parametro setIdleConnectionTimeout determina il periodo di timeout per le connessioni inattive, mentre setConnectTimeout determina il periodo di timeout per le connessioni con il cluster DAX. Questi due parametri gestiscono i timeout dei pool di connessioni, i quali possono influire sulla latenza del cluster.

Configura il timeout della richiesta per le connessioni con il cluster DAX regolando il parametro setRequestTimeout. Per ulteriori informazioni, consulta setRequestTimeout nella documentazione DAX.

Inoltre, è consigliabile utilizzare nuovi tentativi di backoff esponenziale, che riducono gli errori di richiesta e anche i costi operativi.

Nota: DAX non supporta la latenza del cluster nei parametri CloudWatch.

---