Wie erkenne und behebe ich ReadProvisionedThroughputExceeded-Ausnahmen in Kinesis Data Streams?
In Amazon Kinesis Data Streams tritt ein ReadProvisionedThroughputExceeded-Fehler auf, und ich weiß nicht, warum das passiert.
Kurzbeschreibung
Der ReadProvisionedThroughputExceeded-Fehler tritt auf, wenn Kinesis-Datenströme GetRecords-Aufrufe über einen bestimmten Zeitraum drosseln.
Wenn die folgenden Kontingente überschritten werden, kann Ihr Amazon-Kinesis-Datenstrom gedrosselt werden:
- Jeder Shard unterstützt bis zu fünf Lesetransaktionen pro Sekunde oder fünf GetRecords-Aufrufe pro Sekunde für jeden Shard.
- Jeder Shard unterstützt eine maximale Leserate von 2 MiB pro Sekunde.
- GetRecords ruft bis zu 10 MiB an Daten pro Aufruf von einem einzelnen Shard und bis zu 10.000 Datensätze pro Aufruf ab. Wenn ein Aufruf von GetRecords 10 MiB an Daten zurückgibt, führen nachfolgende Aufrufe innerhalb der nächsten 5 Sekunden zu einem Fehler.
Wenn ein ReadProvisionedThroughputExceeded-Fehler auftritt, führen Sie eine der folgenden Aufgaben aus:
- Identifizieren Sie die Ursache Ihres Problems.
- Identifizieren Sie einen möglichen Microburst.
- Folgen Sie den Best Practices von Kinesis Data Streams.
Behebung
Identifizieren Sie die Ursache Ihres Problems
Um die Ursache des Fehlers ReadProvisionedThroughputExceeded in Data Streams zu ermitteln, überwachen Sie den Amazon Kinesis Data Streams Service mit Amazon CloudWatch.
Überprüfen Sie die folgenden Metriken in CloudWatch:
- **GetRecords.Bytes:**Die Anzahl der Byte, die über einen bestimmten Zeitraum aus dem Datenstrom abgerufen werden.
- **GetRecords.Records:**Die Anzahl der Datensätze, die über einen bestimmten Zeitraum aus dem Datenstrom abgerufen werden.
- **ReadProvisionedThroughputExceeded:**Die Anzahl der GetRecords-Aufrufe, die Ihren Datenstrom drosseln.
Richten Sie Ihr CloudWatch-Dashboard so ein, dass Ihre Statistiken als Summe angezeigt werden, wobei der Zeitraum auf 1 Minute festgelegt ist. Teilen Sie dann die Summe durch 60 Sekunden, um einen Durchschnittswert zu erhalten.
Wenn Sie beispielsweise den Metrikwert GetRecords.Records verwenden, teilen Sie die Summe durch 60 Sekunden, um die durchschnittliche Anzahl der pro Sekunde gesendeten Datensätze zu berechnen. Prüfen Sie dann, ob der Durchschnittswert unter den pro Sekunde gesendeten Datensätzen für das für Ihren Datenstrom festgelegte Limit liegt. Weitere Informationen zu Shard-Kontingenten finden Sie unter Kontingente und Grenzwerte.
**Hinweis:**Aktivieren Sie die erweiterte Überwachungsfunktion, um sicherzustellen, dass die Last gleichmäßig auf alle Ihre Shards verteilt wird.
Sie können auch die GetRecords.Records-Metrik verwenden, wobei die Statistik als SampleCount angezeigt wird und der Zeitraum auf 1 Minute festgelegt ist. Teilen Sie den SampleCount-Wert durch 60 Sekunden, um die durchschnittliche Anzahl der GetRecords-Aufrufe pro Sekunde für jeden Shard zu berechnen. Wenn der Durchschnittswert ungefähr fünf GetRecords-Aufrufe pro Sekunde beträgt und der ReadProvisionedThroughputExceeded-Fehler auftritt, überprüfen Sie Ihre Verbraucher und Shard-Kontingente. Wenn die Verbraucher die Shard-Limits nicht überschreiten, liegt der ReadProvisionedThroughputExceeded-Fehler möglicherweise daran, dass Ihre Verbraucher mehr als fünf GetRecords-Aufrufe pro Sekunde tätigen.
Prüfen Sie abschließend, ob es einen Unterschied zwischen den ReadProvisionedThroughputExceeded-Werten Ihrer Shards gibt. Wenn die Verteilung der Shards ungleichmäßig ist oder ein Shard mehr oder weniger Daten erhält als der andere, kann es zu einem Ungleichgewicht in der Verteilung kommen. Um dieses Ungleichgewicht bei der Shard-Verteilung zu beheben und heiße Shards zu vermeiden, verwenden Sie UUID als Partitionsschlüssel im putRecords-API-Aufruf.
Identifizieren Sie einen möglichen Microburst
In seltenen Fällen können Metrikwerte unter den Shard-Kontingenten liegen und dazu führen, dass ein Datenstrom während eines Lesevorgangs gedrosselt wird.
Ein Wert von GetRecords.Bytes Sum:1min steht beispielsweise für 10 MiB an Daten, die 1 Minute lang gelesen wurden. Nach einer Sekunde liest der GetRecords.Bytes-Aufruf 2 MiB an Daten ohne Drosselung. Nach 2 Sekunden liest der GetRecords.Bytes-Aufruf 8 MiB an Daten. Nach 3 Sekunden gibt es möglicherweise keine Lesevorgänge oder Drosselungen. Obwohl das Shard-Kontingent für die Minute nicht erreicht ist (2 MiB * 60 = 120 MiB an Daten), erhalten Sie möglicherweise einen ReadProvisionedThroughputExceeded-Fehler. Wenn Sie einen plötzlichen Anstieg der Metrikwerte feststellen, suchen Sie nach dem Microburst, der die ReadProvisionedThroughputExceeded-Ausnahme verursacht.
Folgen Sie den Best Practices von Kinesis Data Streams
Gehen Sie wie folgt vor, um ReadProvisionedThroughputExceeded-Ausnahmen zu vermeiden:
- Resharden Sie Ihren Stream, um die Anzahl der Shards im Stream zu erhöhen.
- Reduzieren Sie die Größe der GetRecords-Anfragen. Konfigurieren Sie den Limit-Parameter oder reduzieren Sie die Häufigkeit von GetRecords-Anfragen.
Hinweis:Wenn es sich bei dem Verbraucher um Amazon Kinesis Data Firehose handelt, passt sich der Datenstrom an die Häufigkeit derGetRecords-Aufrufe an. Wenn es sich bei dem Verbraucher um eine AWS-Lambda-Funktion mit Zuordnung von Ereignisquellen handelt, wird der Strom einmal pro Sekunde abgefragt. Sie können die Abfragefrequenz nicht ändern. Wenn es sich bei dem Verbraucher um eine Amazon Kinesis Client Library (KCL)-Anwendung handelt, passen Sie die Abfragefrequenz an. Um die Abfragefrequenz anzupassen, ändern Sie den Parameterwert DEFAULT_IDLETIME_BETWEEN_READS_MILLIS in der KinesisClientLibConfiguration-Datei. Sie können diesen Wert im Code dynamisch festlegen. Weitere Informationen zum Ändern dieses Werts in der KCL finden Sie unter amazon-kinesis-client auf der GitHub-Website. - Verteilen Sie Lese- und Schreibvorgänge so gleichmäßig wie möglich auf alle Shards in Data Streams.
- Wenn Ihr Datenstrom mehr als fünf Verbraucher verwendet, verwenden Sie Verbraucher mit erweitertem Fan-Out.
- Wenn Sie auf ReadProvisionedThroughputExceeded-Ausnahmen stoßen, verwenden Sie einen Fehlerwiederholungs- und einen exponentiellen Backoff-Mechanismus in der Verbraucherlogik. Bei Verbraucheranwendungen, die ein AWS SDK verwenden, werden die Anfragen standardmäßig wiederholt.
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 6 Monaten
- AWS OFFICIALAktualisiert vor 8 Monaten