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 il tuo carico di lavoro sembra avere una latenza elevata, puoi analizzare la CloudWatch SuccessfulRequestLatency metrica e controllare la latenza media e la latenza mediana tramite metriche percentili (p50) per vedere se è correlata a DynamoDB. Una certa variabilità nei dati riportati SuccessfulRequestLatency è normale e i picchi occasionali (in particolare nelle statistiche e nei percentili elevati) non dovrebbero essere motivo di preoccupazione. Maximum Tuttavia, se la Average statistica o il p50 (mediana) mostra un forte aumento e persiste, dovresti controllare il AWS Service Health Dashboard e il tuo Personal Health Dashboard per ulteriori informazioni. Alcune possibili cause includono la dimensione dell'elemento nella tabella (un elemento da 1 KB e un elemento da 400 KB variano in termini di latenza) o la dimensione della query (10 elementi contro 100 elementi).

Le metriche percentili (p99, p90, ecc.) possono aiutarti a comprendere meglio la distribuzione della latenza. Per 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), puoi inserire manualmente il percentile desiderato (ad esempio, p99.9) nel campo delle statistiche 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 viste come risultato di operazioni in background basate su DynamoDB che aiutano a mantenere un'elevata disponibilità e durabilità dei dati archiviati nelle tabelle DynamoDB o di problemi transitori dell'infrastruttura.

Se necessario, valuta la possibilità di aprire una richiesta di supporto con Supporto AWS e continua a valutare tutte le opzioni di riserva disponibili per la tua applicazione (come l'evacuazione di una regione se disponi di un'architettura multiregionale) in base ai runbook. È necessario registrare le richieste lente IDs per inviarle IDs a Supporto AWS quando si apre una richiesta di supporto.

La SuccessfulRequestLatency metrica misura solo la latenza interna al servizio DynamoDB: le attività lato client e i tempi di viaggio sulla rete non sono inclusi. Per saperne di più sulla latenza complessiva per le chiamate dal client al servizio DynamoDB, puoi abilitare la registrazione delle metriche 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:

  • Riutilizza le connessioni: per impostazione predefinita, le richieste DynamoDB vengono effettuate tramite una sessione autenticata su HTTPS. L'avvio della connessione richiede più round trip e richiede tempo, quindi la latenza della prima richiesta è maggiore 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 di latenza dovuto alla creazione di nuove connessioni, potresti voler implementare un meccanismo «keep-alive» inviando una GetItem richiesta ogni 30 secondi se 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. Alla fine, le letture consistenti hanno un costo inferiore e possono provenire da più zone di disponibilità, permettendo la selezione di una zona di disponibilità collocata congiuntamente al richiedente che riduce la latenza. Per ulteriori informazioni, consulta Coerenza di lettura di DynamoDB.

  • Implementa la copertura delle richieste: per requisiti di latenza p99 molto bassi, prendi in considerazione l'implementazione della copertura delle richieste. Con la copertura delle richieste, se la richiesta iniziale non riceve una risposta abbastanza rapidamente, inviate una seconda richiesta equivalente e lasciatela correre, la prima risposta vince. Ciò migliora la latenza di coda al costo di alcune richieste aggiuntive. Puoi decidere quanto tempo aspettare prima di inviare la seconda richiesta. L'hedging è più facile da leggere. Per le scritture, utilizzate l'ordinamento basato sul timestamp per garantire che le richieste coperte vengano trattate come se si verificassero al momento del primo tentativo, impedendo gli aggiornamenti. out-of-order Questo approccio è stato discusso in Timestamp write for write hedging in Amazon DynamoDB.

  • Modifica il timeout delle richieste e il comportamento dei nuovi tentativi: il percorso dal client a DynamoDB attraversa molti componenti, ciascuno progettato pensando alla ridondanza. Considerate i seguenti aspetti:

    • Resilienza della rete

    • Timeout dei pacchetti TCP

    • L'architettura distribuita di DynamoDB

    I comportamenti SDK predefiniti sono ottimizzati per la maggior parte delle applicazioni. Tuttavia, puoi implementare una strategia fail-fast e regolare le impostazioni di timeout. Le richieste che richiedono molto più tempo del normale hanno meno probabilità di successo alla fine. Se fallisci rapidamente e riprovi, potresti avere successo rapidamente attraverso un percorso diverso. È simile alla copertura delle richieste, ma termina la prima richiesta invece di consentirla di procedere.

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

    Per una discussione utile su questo argomento, consulta Ottimizzazione delle impostazioni di richiesta HTTP dell'SDK AWS Java per le applicazioni Amazon DynamoDB che riconoscono la latenza.

  • 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 in più regioni con DynamoDB. Con le tabelle globali, puoi replicare la tabella in AWS regioni specifiche in cui desideri 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 Usare le tabelle globali di Amazon DynamoDB in Prescriptive Guidance. AWS

  • Usa la memorizzazione nella cache: se il tuo traffico di lettura è intenso, prendi in considerazione l'utilizzo di uno di questi servizi di caching: