Warum werden meine Kinesis Data Streams gedrosselt?

Kurzbeschreibung

Kinesis Data Streams drosselt, wenn Schreib- oder Lesevorgänge die Durchsatzgrenzen pro Shard überschreiten. Deome aggregierten CloudWatch-Metriken werden zwar möglicherweise innerhalb der Kontingente angezeigt, die Drosselung erfolgt jedoch weiterhin. Dies geschieht in der Regel aus den folgenden Gründen:

• Die erweiterte Überwachung auf Shard-Ebene ist deaktiviert. Das verbirgt Hot Shards.
• Versteckte Mikrospitzen innerhalb des 60-Sekunden-Aggregationsfensters von Amazon CloudWatch.
• CloudWatch-Metriken melden nur erfolgreiche Vorgänge. Dadurch wird das wahre Anforderungsvolumen maskiert.

Lösung

ProvisionedThroughputExceededException- oder LimitExceededException-Fehler beheben

Wenn du die GetRecords- oder PutRecords-, PutRecord-API verwendest, erzeugt dein Stream möglicherweise Drosselungsfehler vom Typ ProvisionedThroughputExceededException oder LimitExceededException.

Die Fehler können auch aus einem der folgenden Gründe auftreten: Schreibseitige Drosselung

Schreibseitige Drosselung verursacht den Fehler, wenn die folgenden Bedingungen zutreffen:

• Die Anzahl der pro Sekunde geschriebenen Datensätze übersteigt 1 000 Datensätze/Shard.
• Die Gesamtzahl der geschriebenen Daten übersteigt 1 MiB/Sekunde pro Shard.
• Der Gesamtdurchsatz in Byte überschreitet die Kinesis-Stream-Limits.
• Der Producer stellt zu viele schnelle Anfragen, um in den Stream zu schreiben. Ein Fehler wie Verlangsamen oder Rate überschritten weist in der Regel auf dieses Problem hin.

Leseseitige Drosselung

Dieser Fehler tritt auf, wenn ein einzelner Shard mehr als 5 GetRecords-Aufrufe pro Sekunde empfängt. Der Fehler kann auch auftreten, wenn mehrere Verbraucher ohne erweiterten Fan-Out um die Lesekapazität desselben Shards konkurrieren.

Gehe wie folgt vor, um diesen Fehler zu diagnostizieren:

• Überprüfe die Metrik WriteProvisionedThroughputExceeded für Schreibvorgänge oder die Metrik ReadProvisionedThroughputExceed für Lesevorgänge in CloudWatch. Ein Wert ungleich Null bestätigt die Drosselung.
• Nimm den Metrikwert IncomingBytes oder IncomingRecords von einem einminütigen Datenpunkt und dividiere ihn durch 60, um die durchschnittliche Rate pro Sekunde zu erhalten.
• Wenn die durchschnittliche Rate pro Sekunde das Kontingent nicht überschreitet, füge die ** IncomingRecords** zur WriteProvisionedThroughputExceeded-Anzahl hinzu. Wenn die Gesamtsumme das Kontingent pro Shard überschreitet, ist mit einer Drosselung zu rechnen.
• Aktiviere die Protokollierung auf der Seite des Daten-Producers, um die Gesamtzahl und Größe der übermittelten Datensätze zu erfassen.

Gehe wie folgt vor, um dieses Problem zu beheben:

• Erhöhe die Anzahl der Shards in deinem Stream.
• Wechsle für Auto Scaling in den On-Demand-Kapazitätsmodus.
• Aktiviere den erweiterten Fan-Out für eine leseseitige Drosselung bei mehreren Verbrauchern, um jedem Verbraucher einen dedizierten Durchsatz von 2 MiB/s pro Shard zu bieten.

Die erweiterte Überwachung auf Shard-Ebene ist deaktiviert

Wenn die erweiterte Überwachung deaktiviert ist, werden Metriken auf Stream-Ebene für alle Shards aggregiert. Dadurch können Hot Shards verborgen werden – Shards, die aufgrund einer ungleichmäßigen Verteilung der Partitionsschlüssel einen unverhältnismäßig hohen Datenverkehr verzeichnen.

Beispiel

Ein Stream mit 10 Shards verfügt über eine Gesamtschreibkapazität von 10 Mib/Sek. Wenn deine aggregierten IncomingBytes 5 MiB/Sek. anzeigen, scheint alles in Ordnung zu sein. Wenn jedoch 80 % dieses Datenverkehrs mit 4 MiB/Sek. auf einen einzigen Shard entfallen, kommt es bei diesem Shard zu einer Drosselung, obwohl die Metrik auf Stream-Ebene in Ordnung aussieht.

Die PutRecord****s oder PutRecord.Success-Metrik zeigt auch fehlgeschlagene Vorgänge an. Wenn die Erfolgsmetrik sinkt, überprüfe die Daten-Producer-Protokolle, um die Hauptursachen für die Fehler zu ermitteln. Wenn eine Drosselung auftritt, richte die Protokollierung auf der Seite des Daten-Producer ein, um die Gesamtzahl und Größe der übermittelten Datensätze zu ermitteln. Wenn die Gesamtzahl der Datensätze in den PutRecord- oder PutRecords-Aufrufen das Stream-Kontingent überschreitet, wird dein Kinesis-Stream gedrosselt.

Gehe wie folgt vor, um dieses Problem zu diagnostizieren:

• Führe den folgenden Befehl aus, um die erweiterte Überwachung auf Shard-Ebene zu aktivieren:

  aws kinesis enable-enhanced-monitoring \
    --stream-name <your-stream-name> \
    --shard-level-metrics ALL

  Hinweis: Ersetze your-stream-name durch deinen Stream-Namen
• Vergleiche die Durchschnitts- und Höchstwerte von IncomingBytes auf Shard-Ebene. Eine große Differenz zwischen diesen Werten deutet auf Hot Shards hin.
• Identifiziere, welche Shards deutlich mehr IncomingBytes oder IncomingRecords als andere haben.

Gehe wie folgt vor, um dieses Problem zu beheben:

• Verwende zufällige Partitionsschlüssel oder Partitionsschlüssel mit hoher Kardinalität, um Datensätze gleichmäßig auf die Shards zu verteilen.
• Wenn du aussagekräftige Partitionsschlüssel verwenden musst, solltest du erwägen, ein zufälliges Suffix hinzuzufügen, um die Verteilung zu verbessern.
• Überwache IncomingBytes und IncomingRecords auf Shard-Ebene. Wenn die Maximal- und Durchschnittswerte nahe beieinander liegen, ist die Verteilung gleichmäßig.
• Erwäge ein Resharding, um Hot Shards aufzuteilen. Strategien für das Resharding.

Versteckte Mikrospitzen in CloudWatch-Metriken

Kinesis-Data-Streams-Kontingente werden pro Sekunde durchgesetzt, CloudWatch aggregiert Metriken jedoch standardmäßig über Zeiträume von 60 Sekunden. Ein kurzer Anstieg, z. B. 3 000 Datensätze in einer Sekunde, kann zu einer Drosselung führen, obwohl der Ein-Minuten-Durchschnitt von 50 Datensätzen pro Sekunde innerhalb der Grenzwerte liegt.

Beispiel

Ein Shard empfängt 60 000 Datensätze in einer Minute. Wenn jedoch 5 000 dieser Datensätze in einer einzigen Sekunde eintrafen, wurde diese Sekunde gedrosselt. Die CloudWatch-Metrik gibt darüber keinen Aufschluss.

Um das Problem zu diagnostizieren, implementiere eine Protokollierung auf Anwendungsebene, um die Anzahl und Größe der an jeden Shard gesendeten Datensätze pro Sekunde zu erfassen. Überprüfe auch die WriteProvisionedThroughputExceeded-Metrik. Selbst ein kleiner Summenwert ungleich Null zeigt, dass Mikrospitzen aufgetreten sind.

Gehe wie folgt vor, um dieses Problem zu beheben:

• Implementiere exponentielles Backoff mit Jitter in deiner Producer-Wiederholungslogik.
• Verwende die Kinesis Producer Library (KPL), die eine integrierte Ratenbegrenzung und Datensatzaggregation bietet.
• Glätte den Datenverkehr, indem du Datensätze zwischenspeicherst und sie mit einer konstanten Rate sendest.
• Erhöhe die Anzahl der Shards, um Spielraum für Spitzenauslastungen zu schaffen.
• Begrenze die Anforderungsrate des Producers und die Anzahl der Datensätze, die pro Sekunde gesendet werden, damit diese der Kapazität des Streams entsprechen.

CloudWatch-Metriken melden nur erfolgreiche Vorgänge

CloudWatch-Kinesis-Metriken (IncomingRecords, incomingBytes) zählen nur Datensätze, die Kinesis Data Streams erfolgreich erfasst hat. Gedrosselte oder fehlgeschlagene Datensätze sind von diesen Metriken ausgeschlossen. Das bedeutet, dass das tatsächliche Datenverkehrsvolumen, das deinen Stream erreicht, höher ist als das, was CloudWatch anzeigt.

Wenn fehlgeschlagene Datensätze nicht in den Kinesis-Stream gelangen können, wird der Stream gedrosselt. Wenn im Producer ein Wiederholungsverhalten implementiert ist, unternimmt dieser erneute Versuche für fehlgeschlagene Datensätze. Der Vorgang könnte sich dann verzögern.

Um zu überprüfen, ob zu viele Datensätze an den Kinesis-Stream gesendet werden, addiere die Gesamtzahl der eingehenden Datensätze zur Anzahl der gedrosselten Datensätze.

Verwende die folgende Formel, um das Anforderungsvolumen zu berechnen:

True volume = IncomingRecords (Sum) + WriteProvisionedThroughputExceeded (Sum)

Wenn das tatsächliche Volumen die Kapazität deines Streams übersteigt, wird mit einer Drosselung gerechnet. Auch wenn nur IncomingRecords innerhalb der Grenzen erscheint.

Überprüfe die Producer-Protokolle auf die Anzahl der Wiederholungsversuche. Hohe Wiederholungsraten zeigen, dass fehlgeschlagene Datensätze erneut übermittelt werden, was die Auslastung weiter erhöht.

Gehe wie folgt vor, um das Problem zu beheben:

• Skaliere deinen Stream so, dass er das tatsächliche Anforderungsvolumen berücksichtigt, nicht nur das erfolgreiche Volumen. Füge Shards hinzu oder wechsle in den On-Demand-Modus.
• Implementiere Circuit-Breaker-Muster in deinem Producer, um Wiederholungs-Streams zu vermeiden.
• Nutze die in die KPL integrierte Ratenbegrenzung, um eine Überlastung des Streams zu verhindern.

Ähnliche Informationen

Entwicklung maßgeschneiderter Verbraucher mit dediziertem Durchsatz (verbessertes Fan-Out)

Überwachen des Amazon Kinesis Data Streams Service mit Amazon CloudWatch

Enable-enhanced-monitoring

Kontingente und Grenzwerte für Kinesis Data Streams