Beheben von Latenzproblemen in Amazon DynamoDB

Wenn Ihr Workload eine hohe Latenz aufweist, können Sie die CloudWatch SuccessfulRequestLatency Metrik analysieren und die durchschnittliche Latenz überprüfen, um festzustellen, ob sie mit DynamoDB zusammenhängt. Gewisse Schwankungen im gemeldeten Wert zu SuccessfulRequestLatency sind normal und gelegentliche Spitzen (insbesondere in der Maximum-Statistik) sollten Sie nicht beunruhigen. Wenn die Average-Statistik jedoch einen anhaltenden starken Anstieg zeigt, sollten Sie das AWS-Servicestatus-Dashboard und Ihr Persönliches Servicestatus-Dashboard überprüfen, um mehr zu erfahren. 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 weisen unterschiedliche Latenzzeiten auf) oder die Größe der Abfrage (10 Elemente gegenüber 100 Elementen).

Falls erforderlich können Sie einen Support-Fall beim AWS Support öffnen und weiterhin alle verfügbaren Fallback-Optionen für Ihre Anwendung (z. B. Leerung einer Region, wenn Sie über eine Architektur mit mehreren Regionen verfügen) gemäß Ihren Runbooks bewerten. Sie sollten Anforderungs-IDs für langsame Anforderungen zur Bereitstellung dieser IDs für protokollierenAWS Support, wenn Sie einen Support-Fall öffnen.

Die Metrik SuccessfulRequestLatency misst nur die interne Latenz von DynamoDB – clientseitige Aktivitäten und Netzwerklaufzeiten sind darin nicht enthalten. Wenn Sie mehr über die allgemeine Latenz für Aufrufe von Ihrem Client an den Service DynamoDB erfahren möchten, können Sie die Protokollierung von Latenzmetriken im 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:

• Anfrage-Timeout und Wiederholungsverhalten anpassen: Der Pfad von Ihrem Client zu DynamoDB durchläuft viele Komponenten, von denen jede auf Redundanz ausgelegt ist. Denken Sie an den Umfang der Netzwerkresilienz, die Timeouts für TCP-Pakete und die verteilte Architektur von DynamoDB selbst. Das SDK-Standardverhalten ist darauf ausgelegt, für die meisten Anwendungen das richtige Gleichgewicht zu finden. Wenn die bestmögliche Latenz für Sie die höchste Priorität hat, sollten Sie erwägen, die Standardeinstellungen für das Anfrage-Timeout und die Wiederholungsversuche für das SDK anzupassen, um die vom Client gemessene typische Latenz für eine erfolgreiche Anfrage genau einzuhalten. Eine Anfrage, die deutlich mehr Zeit als üblich in Anspruch nimmt, wird mit geringerer Wahrscheinlichkeit erfolgreich abgeschlossen. Wenn Sie schnell scheitern und eine neue Anfrage ausführen, wird diese wahrscheinlich einen anderen Pfad nehmen und schnell erfolgreich sein. Denken Sie daran, dass zu strenge Einstellungen auch Nachteile mit sich bringen können. Eine hilfreiche Erörterung zu diesem Thema finden Sie unter Optimieren der HTTP-Anfrageeinstellungen des AWS SDK für Java für latenzempfindliche Amazon-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. Wenn Sie globale Tabellen verwenden, können Sie die AWS-Regionen angeben, in denen die Tabellen verfügbar sein sollen. Das Lesen von Daten aus einem lokalen Replikat einer globalen Tabelle kann die Latenz für Ihre Benutzer erheblich reduzieren. Ziehen Sie es außerdem in Erwägung, einen DynamoDB-Gateway-Endpunkt zu verwenden, um Ihren Client-Datenverkehr innerhalb Ihrer VPC zu halten.

• Caching verwenden: Wenn Ihr Datenverkehr leseintensiv ist, sollten Sie die Verwendung eines Caching-Service wie beispielsweise In-Memory-Beschleunigung mit DynamoDB Accelerator (DAX) in Betracht ziehen. DAX ist ein vollständig verwalteter In-Memory-Cache mit Hochverfügbarkeit für DynamoDB, der eine bis zu 10-fache Leistungssteigerung von Millisekunden zu Mikrosekunden bietet, selbst bei Millionen von Anfragen pro Sekunde.

• Verbindungen wiederverwenden: DynamoDB-Anfragen werden über eine authentifizierte Sitzung gestellt, die standardmäßig HTTPS verwendet. Das Initiieren der Verbindung nimmt Zeit in Anspruch, sodass die Latenz der ersten Anfrage höher als üblich ist. Anfragen über eine bereits initialisierte Verbindung stellen die gleichbleibend niedrige Latenz von DynamoDB bereit. Aus diesem Grund möchten Sie möglicherweise alle 30 Sekunden eine „Keep-Alive“-GetItem-Anfrage senden, wenn keine anderen Anfragen gestellt werden, um die Latenz beim Aufbau einer neuen Verbindung zu vermeiden.

• 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. Letztendlich konsistente Lesevorgänge sind kostengünstiger und es besteht eine geringere Wahrscheinlichkeit, dass die Latenz vorübergehend ansteigt. Weitere Informationen finden Sie unter Lesekonsistenz.