Beheben von Latenzproblemen in Amazon DynamoDB - Amazon-DynamoDB

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beheben von Latenzproblemen in Amazon DynamoDB

Wenn Ihr Workload eine hohe Latenz zu haben scheint, können Sie die CloudWatch SuccessfulRequestLatency Metrik analysieren und anhand von Perzentilmetriken (p50) die durchschnittliche Latenz und die mittlere Latenz überprüfen, um festzustellen, ob sie mit DynamoDB zusammenhängt. Eine gewisse Variabilität der gemeldeten Werte SuccessfulRequestLatency ist normal, und gelegentliche Spitzenwerte (insbesondere in der Maximum Statistik und bei hohen Perzentilen) sollten keinen Anlass zur Sorge geben. Wenn die Average Statistik oder p50 (Median) jedoch einen starken Anstieg zeigt und anhält, sollten Sie im AWS Service Health Dashboard und in Ihrem Personal Health Dashboard nach weiteren Informationen suchen. Zu den möglichen Ursachen gehören die Größe des Elements in Ihrer Tabelle (ein Element mit 1 KB und ein Element mit 400 KB variieren in der Latenz) oder die Größe der Abfrage (10 Elemente gegenüber 100 Elementen).

Die Perzentilmetriken (p99, p90 usw.) können Ihnen helfen, Ihre Latenzverteilung besser zu verstehen. Zum Beispiel:

  • p50 (Median) zeigt die typische Latenz für Ihren Workload.

  • p90 zeigt, dass 90 Prozent der Anfragen schneller sind als dieser Wert.

  • p99 hilft dabei, die Latenz im schlimmsten Fall zu identifizieren, von der 1 Prozent der Anfragen betroffen sind.

Hohe p99-Werte bei normalen p50-Werten können auf sporadische Probleme hinweisen, die einen kleinen Teil der Anfragen betreffen, wohingegen konstant erhöhte p50-Werte auf Leistungseinbußen hindeuten können.

Anmerkung

Um benutzerdefinierte Perzentilwerte (z. B. p99,9) zu analysieren, können Sie das gewünschte Perzentil (z. B. p99,9) manuell in das Feld Metrikstatistik eingeben. CloudWatch Auf diese Weise können Sie Latenzverteilungen auswerten, die über die in der Dropdownliste aufgeführten Standardperzentile hinausgehen.

Eine gewisse Variation der Latenzmetriken, insbesondere bei höheren Perzentilen, ist zu erwarten und kann als Folge von DynamoDB-gesteuerten Hintergrundoperationen gesehen werden, die dazu beitragen, die hohe Verfügbarkeit und Beständigkeit Ihrer in DynamoDB-Tabellen gespeicherten Daten aufrechtzuerhalten, oder auf vorübergehende Infrastrukturprobleme.

Falls erforderlich, sollten Sie erwägen AWS -Support, einen Support-Fall mit Ihnen zu eröffnen, und prüfen Sie weiterhin alle verfügbaren Ausweichmöglichkeiten für Ihre Anwendung (z. B. die Evakuierung einer Region, wenn Sie über eine Architektur mit mehreren Regionen verfügen) gemäß Ihren Runbooks. Sie sollten Anfragen IDs für langsame Anfragen protokollieren, damit Sie diese AWS -Support bei der Eröffnung eines Support-Falls IDs bereitstellen können.

Die SuccessfulRequestLatency Metrik misst nur die Latenz, die innerhalb des DynamoDB-Dienstes liegt — clientseitige Aktivitäten und Netzwerkausfallzeiten sind nicht enthalten. Um mehr über die Gesamtlatenz bei Aufrufen von Ihrem Client an den DynamoDB-Dienst zu erfahren, können Sie die Protokollierung von Latenzmetriken in Ihrem AWS SDK aktivieren.

Anmerkung

Für die meisten Singleton-Operationen (Operationen, die sich auf ein einzelnes Element beziehen, indem der Wert des Primärschlüssels vollständig angegeben wird) stellt DynamoDB Average SuccessfulRequestLatency im einstelligen Millisekundenbereich bereit. Dieser Wert beinhaltet nicht den Transport-Overhead für den Aufrufer-Code, der auf den DynamoDB-Endpunkt zugreift. Bei Datenoperationen mit mehreren Elementen hängt die Latenz von Faktoren wie der Größe der Ergebnismenge, der Komplexität der zurückgegebenen Datenstrukturen und allen angewendeten Bedingungs- und Filterausdrücken ab. Bei wiederholten Operationen mit mehreren Elementen für denselben Datensatz mit denselben Parametern stellt DynamoDB Average SuccessfulRequestLatency mit hoher Konsistenz bereit.

Ziehen Sie eine oder mehrere der folgenden Strategien in Erwägung, um die Latenz zu reduzieren:

  • Verbindungen wiederverwenden: DynamoDB-Anfragen werden standardmäßig über eine authentifizierte Sitzung über HTTPS gestellt. Das Initiieren der Verbindung erfordert mehrere Roundtrips und nimmt Zeit in Anspruch, sodass die Latenz der ersten Anfrage höher ist als bei nachfolgenden Anfragen, bei denen die Verbindung wiederverwendet wird. Anfragen über eine bereits initialisierte Verbindung stellen die gleichbleibend niedrige Latenz von DynamoDB bereit. Um den Latenzaufwand beim Aufbau neuer Verbindungen zu vermeiden, sollten Sie einen „Keep-Alive“ -Mechanismus implementieren, indem Sie alle 30 Sekunden eine GetItem Anfrage senden, sofern keine weiteren Anfragen gestellt werden.

  • Letztendlich konsistente Lesevorgänge verwenden: Wenn Ihre Anwendung keine strikt konsistenten Lesevorgänge erfordert, sollten Sie die Verwendung der standardmäßigen letztendlich konsistenten Lesevorgänge in Betracht ziehen. Schließlich sind konsistente Lesevorgänge kostengünstiger und können aus mehreren Availability Zones stammen. Dadurch kann eine Availability Zone ausgewählt werden, die sich am Standort des Anfragenden befindet, wodurch die Latenz verringert wird. Weitere Informationen finden Sie unter DynamoDB-Lesekonsistenz.

  • Implementieren Sie die Absicherung von Anfragen: Für Anforderungen mit sehr niedriger p99-Latenz sollten Sie die Implementierung von Anforderungsabsicherungen in Betracht ziehen. Beim Request Hedging gilt: Wenn die erste Anfrage nicht schnell genug beantwortet wird, senden Sie eine zweite gleichwertige Anfrage und lassen Sie sie rasen, die erste Antwort gewinnt. Dadurch wird die Latenz am Ende verbessert, allerdings auf Kosten einiger zusätzlicher Anfragen. Sie können entscheiden, wie lange Sie warten möchten, bevor Sie die zweite Anfrage senden. Hedging ist für Lesevorgänge einfacher. Verwenden Sie bei Schreibvorgängen eine zeitstempelbasierte Reihenfolge, um sicherzustellen, dass abgesicherte Anfragen so behandelt werden, als wären sie zum Zeitpunkt des ersten Versuchs aufgetreten, wodurch Aktualisierungen verhindert werden. out-of-order Dieser Ansatz wurde in Timestamp Writes for Write Hedging in Amazon DynamoDB erörtert.

  • Passen Sie das Anforderungs-Timeout und das Wiederholungsverhalten an: Der Pfad von Ihrem Client zu DynamoDB durchquert viele Komponenten, von denen jede auf Redundanz ausgelegt ist. Beachten Sie die folgenden Aspekte:

    • Ausfallsicherheit des Netzwerks

    • Timeouts für TCP-Pakete

    • Die verteilte Architektur von DynamoDB

    Das Standardverhalten des SDK ist für die meisten Anwendungen optimiert. Sie können jedoch eine Fail-Fast-Strategie implementieren und die Timeout-Einstellungen anpassen. Anfragen, die deutlich länger als normal dauern, sind weniger wahrscheinlich, dass sie letztendlich erfolgreich sind. Wenn Sie schnell scheitern und es erneut versuchen, können Sie schnell einen anderen Weg beschreiten. Dies ähnelt der Absicherung von Anfragen, beendet jedoch die erste Anfrage, anstatt ihr den Fortgang zu ermöglichen.

    Vermeiden Sie es, zu niedrige Timeout-Werte festzulegen. Zu niedrige Timeouts können zu kundenbedingten Verfügbarkeitsproblemen führen. Beispielsweise könnte ein Socket-Timeout von 50 Millisekunden bei Netzwerklatenzspitzen zu Verbindungsfehlern führen, z. B. wenn die Bandbreitenlimits von EC2 Amazon-Instances für Single-Flow-Verkehr erreicht werden. Wägen Sie die Vorteile niedrigerer Timeouts sorgfältig gegen potenzielle Risiken für die Anwendungsverfügbarkeit ab und ziehen Sie eine Absicherung kurzen Timeouts vor.

    Eine hilfreiche Diskussion zu diesem Thema finden Sie unter Tuning der AWS Java SDK-HTTP-Anforderungseinstellungen für latenzbewusste Amazon DynamoDB DynamoDB-Anwendungen.

  • Die Distanz zwischen dem Client und dem DynamoDB-Endpunkt verringern: Wenn Ihre Benutzer global verteilt sind, sollten Sie die Verwendung von Globale Tabellen: multiregionale Replikation für DynamoDB in Erwägung ziehen. Mit globalen Tabellen können Sie Ihre Tabelle in bestimmte AWS Regionen replizieren, in denen die Tabelle verfügbar sein soll. Sie können eine Kopie der Daten näher am Endbenutzer platzieren, um die Netzwerklatenz bei Lese- und Schreibvorgängen zu reduzieren. Weitere Informationen zur effektiven Verwendung globaler DynamoDB-Tabellen finden Sie unter Verwenden globaler Tabellen von Amazon DynamoDB in Prescriptive Guidance. AWS

  • Verwenden Sie Caching: Wenn Ihr Traffic viel gelesen wird, sollten Sie einen der folgenden Caching-Dienste in Betracht ziehen: