Risoluzione dei problemi di latenza in Amazon DynamoDB - Amazon DynamoDB

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

Risoluzione dei problemi di latenza in Amazon DynamoDB

Se la latenza del carico di lavoro è elevata, è possibile analizzare la metrica CloudWatch SuccessfulRequestLatency e controllare la latenza media e la latenza mediana attraverso le metriche percentili (p50) per controllare se è correlata a DynamoDB. Una certa variabilità nella metrica SuccessfulRequestLatency restituita è normale e i picchi occasionali (in particolare nelle statistiche Maximum e nei percentili elevati) non devono destare preoccupazione. Tuttavia, se le statistiche Average o il p50 (mediana) mostrano un forte aumento persistente, è opportuno controllare la Dashboard AWS Service Health e la Dashboard Personal Health per ulteriori informazioni. Alcune possibili cause includono la dimensione dell’elemento nella tabella (un elemento da 1 KB e un elemento da 400 KB avranno una latenza diversa) o la dimensione della query (10 elementi rispetto a 100 elementi).

Le metriche percentili (p99, p90, ecc.) possono aiutare a comprendere meglio la distribuzione della latenza. Ad esempio:

  • p50 (mediana) mostra la latenza tipica del carico di lavoro.

  • p90 mostra che il 90% delle richieste è più veloce di questo valore.

  • p99 aiuta a identificare la latenza peggiore che riguarda l’1% delle richieste.

Valori di p99 elevati con valori p50 normali potrebbero indicare problemi sporadici che interessano una piccola parte delle richieste, mentre valori p50 costantemente elevati potrebbero suggerire un peggioramento delle prestazioni.

Nota

Per analizzare valori percentili personalizzati (come p99,9), è possibile inserire manualmente il percentile desiderato (ad esempio, p99,9) nel campo delle statistiche delle metriche CloudWatch. Ciò consente di valutare le distribuzioni di latenza oltre i percentili predefiniti elencati nel menu a discesa.

Sono previste alcune variazioni nelle metriche di latenza, in particolare nei percentili più elevati, che possono essere considerate il risultato di operazioni in background basate su DynamoDB che aiutano a mantenere un’elevata disponibilità e durabilità dei dati archiviati nelle tabelle DynamoDB oppure il risultato di problemi transitori dell’infrastruttura.

Se necessario, considera la possibilità di aprire una richiesta di supporto con Supporto AWS e continua a valutare le opzioni di fallback disponibili per la tua applicazione (ad esempio l'evacuazione di una regione se disponi di un'architettura a più regioni) in base ai tuoi runbook. All’apertura di un caso di supporto è necessario registrare log degli ID delle richieste per le richieste lente e fornire questi ID al Supporto AWS.

La metrica SuccessfulRequestLatency misura solo la latenza interna al servizio DynamoDB; l’attività lato client e i tempi di accesso alla rete non sono inclusi. Per avere altri dettagli sulla latenza complessiva delle chiamate dal client al servizio DynamoDB, puoi abilitare la registrazione dei parametri di latenza nel tuo SDK AWS.

Nota

Per la maggior parte delle operazioni singleton (operazioni che si applicano a un singolo elemento specificando completamente il valore della chiave primaria), DynamoDB fornisce un valore di Average SuccessfulRequestLatency pari a pochissimi millisecondi. Questo valore non include il sovraccarico di trasporto per il codice chiamante che accede all'endpoint DynamoDB. Per le operazioni sui dati con più elementi, la latenza varia in base a fattori quali la dimensione del set di risultati, la complessità delle strutture di dati restituite e le eventuali espressioni di condizione e di filtro applicate. Per operazioni con più elementi ripetute sullo stesso set di dati con gli stessi parametri, DynamoDB fornisce un'elevata coerenza per Average SuccessfulRequestLatency.

Prendi in considerazione una o più delle seguenti strategie per ridurre la latenza:

  • Riutilizzo delle connessioni: le richieste DynamoDB vengono effettuate tramite una sessione autenticata che per impostazione predefinita è HTTPS. L’avvio della connessione richiede più round trip e richiede tempo, pertanto la latenza della prima richiesta è superiore al normale rispetto alle richieste successive che riutilizzano la connessione. Le richieste su una connessione già inizializzata forniscono una bassa latenza costante di DynamoDB. Per evitare il sovraccarico della latenza necessaria nello stabilire nuove connessioni, è possibile implementare un meccanismo “keep-alive” inviando una richiesta GetItem ogni 30 secondi quando non vengono effettuate altre richieste.

  • Usa letture a coerenza finale: se la tua applicazione non richiede un'elevata consistenza di lettura, puoi utilizzare le letture a coerenza finale. Le letture a coerenza finale hanno un costo inferiore e possono provenire da più zone di disponibilità, permettendo la selezione di una zona di disponibilità ubicata nella stessa posizione del richiedente, il che riduce la latenza. Per ulteriori informazioni, consulta Coerenza di lettura di DynamoDB.

  • Implementazione dell’hedging delle richieste: per requisiti di latenza p99 molto bassi, prendi in considerazione l’implementazione dell’hedging delle richieste. Con l’hedging delle richieste, se la richiesta iniziale non riceve una risposta abbastanza rapidamente, invia una seconda richiesta equivalente e considera valida la prima risposta ricevuta. Ciò migliora la latenza di coda al costo di alcune richieste aggiuntive. È possibile decidere quanto aspettare prima di inviare la seconda richiesta. L’hedging è più facile per le letture. Per quanto riguarda le scritture, utilizza l’ordinamento basato sul timestamp per garantire che le richieste con hedging vengano trattate come se si verificassero al momento del primo tentativo, evitando aggiornamenti fuori ordine. Questo approccio è stato discusso in Timestamp writes for write hedging in Amazon DynamoDB.

  • Regolazione del timeout delle richieste e del comportamento delle ripetizioni dei tentativi: il percorso dal client a DynamoDB attraversa molti componenti, ognuno dei quali è progettato sulla base della ridondanza. Prendi in considerazione i seguenti aspetti:

    • Resilienza della rete

    • Timeout dei pacchetti TCP

    • L’architettura distribuita di DynamoDB

    I comportamenti degli SDK predefiniti sono ottimizzati per la maggior parte delle applicazioni. Tuttavia, è possibile implementare una strategia per anticipare l’errore (fail-fast) e regolare le impostazioni di timeout. Le richieste che richiedono molto più tempo del normale hanno meno probabilità di esito finale positivo. Attraverso l’anticipo dell’errore (fail fast) e la ripetizione dei tentativi, è possibile ottenere rapidamente un esito positivo attraverso un percorso diverso. La procedura è simile all’hedging delle richieste, ma termina la prima richiesta invece di consentirle di procedere.

    Evita di impostare valori di timeout troppo bassi. Timeout troppo bassi possono causare problemi di disponibilità indotti dal client. Ad esempio, un timeout del socket di 50 millisecondi potrebbe causare errori di connessione durante i picchi di latenza di rete, ad esempio quando ci si avvicina ai limiti di larghezza di banda delle istanze Amazon EC2 per il traffico a flusso singolo. Valuta attentamente i vantaggi di timeout più bassi rispetto ai potenziali rischi per la disponibilità delle applicazioni e preferisci l’hedging rispetto ai timeout brevi.

    Per un’utile discussione su questo argomento, consulta Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications.

  • Riduci la distanza tra il client e l'endpoint DynamoDB: se hai utenti distribuiti a livello globale, prendi in considerazione l'utilizzo di Tabelle globali: replica multi-attiva e multi-Regione. Con le tabelle globali è possibile replicare la tabella su Regioni AWS specificate in cui si desidera che la tabella sia disponibile. È possibile posizionare una copia dei dati più vicino all’utente finale per ridurre la latenza di rete durante le operazioni di lettura e scrittura. Per ulteriori informazioni sull’uso efficace delle tabelle globali di DynamoDB, consulta Utilizzo delle tabelle globali di Amazon DynamoDB nel Prontuario AWS.

  • Utilizzo della caching: in presenza di traffico a lettura intensiva, prendi in considerazione l’adozione di uno dei seguenti servizi di caching:

    • DynamoDB Accelerator (DAX): un sistema di cache in memoria completamente gestito e a elevata disponibilità per DynamoDB che migliora fino a 10 volte le prestazioni anche in presenza di milioni di richieste al secondo, consentendo di ottenere risposte in microsecondi invece che in millisecondi. Per ulteriori informazioni su DAX, consulta Accelerazione in memoria con DynamoDB Accelerator (DAX):

    • Amazon ElastiCache: un servizio di caching in memoria completamente gestito che può essere integrato con DynamoDB per migliorare le prestazioni di lettura attraverso il modello cache-aside. Per ulteriori informazioni, consulta Integrating Amazon DynamoDB and Amazon ElastiCache by using read-through caching nel Prontuario AWS.