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 aufweist, können Sie die CloudWatch-Metrik SuccessfulRequestLatency analysieren und die durchschnittliche und mittlere Latenz anhand von Perzentilmetriken (p50) überprüfen, um zu ermitteln, ob das Problem mit DynamoDB zusammenhängt. Gewisse Schwankungen im gemeldeten Wert zu SuccessfulRequestLatency sind normal und gelegentliche Spitzen (insbesondere in der Maximum-Statistik und bei hohen Perzentilwerten) sollten Sie nicht beunruhigen. Wenn die Average-Statistik oder p50 (Medianwert) 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).

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

  • p50 (Medianwert) gibt die typische Latenz für Ihren Workload an.

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

  • p99 hilft dabei, die Latenz im Schlimmstfall zu identifizieren, von der 1 % der Anforderungen betroffen sind.

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

Anmerkung

Um benutzerdefinierte Perzentilwerte (z. B. p99,9) zu analysieren, können Sie das gewünschte Perzentil (z. B. p99,9) manuell in das CloudWatch-Metrikstatistikfeld eingeben. So können Sie Latenzverteilungen auswerten, die über die in der Dropdown-Liste aufgeführten Standardperzentilwerte hinausgehen.

Es ist mit gewissen Schwankungen bei den Latenzmetriken zu rechnen, insbesondere bei höheren Perzentilwerten. Diese sind auf DynamoDB-gesteuerte Hintergrundvorgänge zurückzuführen, die zur Aufrechterhaltung einer hohen Verfügbarkeit und Beständigkeit Ihrer in DynamoDB-Tabellen gespeicherten Daten beitragen, oder auf vorübergehende Infrastrukturprobleme.

Falls erforderlich, können Sie einen Supportfall 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. Für langsame Anforderungen sollten Sie die Anforderungs-IDs protokollieren, damit Sie diese IDs AWS -Support bereitstellen können, wenn Sie einen Supportfall öffnen.

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

  • Verbindungen wiederverwenden: DynamoDB-Anforderungen werden über eine authentifizierte Sitzung gestellt, die standardmäßig HTTPS verwendet. Das Initiieren der Verbindung nimmt mehrere Roundtrips in Anspruch und dauert einige Zeit, sodass die Latenz der ersten Anforderung höher als bei nachfolgenden Anforderungen ist, die die Verbindung wiederverwenden. Anforderungen über eine bereits initialisierte Verbindung stellen die gleichbleibend niedrige Latenz von DynamoDB bereit. Um Latenz beim Aufbau neuer Verbindungen zu vermeiden, können Sie einen „Keep-Alive“-Mechanismus implementieren, indem Sie alle 30 Sekunden eine GetItem-Anforderung senden, wenn keine anderen Anforderungen 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. Letztendlich konsistente Lesevorgänge sind kostengünstiger und können aus mehreren Availability Zones stammen, sodass eine Availability Zone ausgewählt werden kann, die sich am Standort des Anforderers befindet, wodurch die Latenz verringert wird. Weitere Informationen finden Sie unter DynamoDB-Lesekonsistenz.

  • Request Hedging implementieren: Für Anforderungen mit sehr niedriger p99-Latenz sollten Sie die Implementierung von Request Hedging in Betracht ziehen. Beim Request Hedging gilt: Wenn die erste Anforderung nicht schnell genug beantwortet wird, wird eine zweite gleichwertige Anforderung gesendet – beide Anforderungen treten also gegeneinander an, wobei die mit der ersten Antwort gewinnt. Dadurch wird die Latenz verbessert, dies erfordert allerdings einige zusätzliche Anforderungen. Sie können entscheiden, wie lange Sie warten möchten, bevor die zweite Anforderung gesendet wird. Hedging ist für Lesevorgänge einfacher. Verwenden Sie für Schreibvorgänge eine zeitstempelbasierte Reihenfolge, um sicherzustellen, dass abgesicherte Anforderungen so behandelt werden, als ob sie zum Zeitpunkt des ersten Versuchs erfolgt wären, was Aktualisierungen in falscher Reihenfolge verhindert. Dieser Ansatz wurde in Timestamp writes for write hedging in Amazon DynamoDB erörtert.

  • Anfrage-Timeout und Wiederholungsverhalten anpassen: Der Pfad von Ihrem Client zu DynamoDB durchläuft viele Komponenten, von denen jede auf Redundanz ausgelegt ist. Berücksichtigen Sie die folgenden Aspekte:

    • Ausfallsicherheit des Netzwerks

    • TCP-Paket-Timeouts

    • 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. Anforderungen, die deutlich länger als normal dauern, haben eine geringere Wahrscheinlichkeit, letztendlich erfolgreich zu sein. Durch schnelles Scheitern („Fail Fast“) und erneutes Versuchen können Sie auf einem anderen Weg zügig zum Erfolg gelangen. Dies ähnelt dem Request Hedging, die erste Anforderung wird jedoch beendet, anstatt ihr Fortsetzen zu erlauben.

    Vermeiden Sie es, Timeout-Werte zu niedrig festzulegen. Zu niedrige Timeouts können zu kundenbedingten Verfügbarkeitsproblemen führen. So kann etwa ein Socket-Timeout von 50 Millisekunden bei Netzwerklatenzspitzen zu Verbindungsfehlern führen, zum Beispiel, wenn die Bandbreitenbeschränkungen von Amazon-EC2-Instances für Single-Flow-Datenverkehr 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 (Hedging) kurzen Timeouts vor.

    Eine hilfreiche Diskussion zu diesem Thema finden Sie unter Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications.

  • Die Distanz zwischen dem Client und dem DynamoDB-Endpunkt verringern: Wenn Ihre Benutzer global verteilt sind, sollten Sie die Verwendung von Globale Tabellen: multiaktive, regionsübergreifende Replikation in Erwägung ziehen. Wenn Sie globale Tabellen verwenden, können Sie Ihre Tabelle in bestimmte AWS-Regionen replizieren, in denen die Tabellen verfügbar sein sollen. Sie können eine Kopie der Daten näher am Endbenutzer platzieren, um die Netzwerklatenz beim Lesen und Schreiben zu reduzieren. Weitere Informationen zur effektiven Verwendung globaler DynamoDB-Tabellen finden Sie unter Verwenden der globalen Amazon-DynamoDB-Tabellen in AWS Prescriptive Guidance.

  • Caching verwenden: Wenn Ihr Datenverkehr leseintensiv ist, sollten Sie die Verwendung eines dieser Caching-Service in Betracht ziehen:

    • DynamoDB Accelerator (DAX): 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 Anforderungen pro Sekunde. Weitere Informationen zu DAX finden Sie unter In-Memory-Beschleunigung mit DynamoDB Accelerator (DAX):

    • Amazon ElastiCache: ein vollständig verwalteter In-Memory-Caching-Service, der in DynamoDB integriert werden kann, um die Leseleistung mithilfe des Cache-Aside-Musters zu verbessern. Weitere Informationen finden Sie unter Integrating Amazon DynamoDB and Amazon ElastiCache by using read-through caching in AWS Prescriptive Guidance.