Amazon Kinesis Data Streams – Häufig gestellte Fragen

Ein Shard hat eine Folge von Datenakten in einem Strom. Es ist die Basiseinheit für die Durchsatzeinheit eines Kinesis-Datenstroms. Ein Shard unterstützt 1 MB/Sekunde und 1 000 Akten pro Sekunde für Schreiben und 2 MB/Sekunde für Lesen. Die Shard schränkt verhersehbare Leistungen ein, welches das Entwickeln und Betreiben eines höchst zuverlässigen Datenstroms-Workflow erleichtert. Ein Produzent legt Datenakten in ein Shard und Konsumenten erhalten Datenakten von Shards. Konsumenten verwenden Shards, um entweder Daten zu verarbeiten als auch für den Verbrauch von Daten in der exakten Reihenfolge, in der sie gespeichert sind. Falls Lesen und Schreiben die Shard-Beschränkungen überschreiten, werden die Produzenten- und Konsumentenanwendungen gedrosselt, welches mit Wiederholversuchen bearbeitet werden kann.

Ein Datensatz ist die Dateneinheit, die in einem Amazon Kinesis-Daten-Stream gespeichert ist. Ein Datensatz besteht aus einer Sequenznummer, einem Partitionsschlüssel und einem Daten-Blob. Ein Daten-Blob sind die Daten von Interesse, die Ihr Datenproduzent einem Daten-Stream hinzufügt. Die maximale Größe eines Datenblobs (Nutzdaten vor der Base64-Kodierung) beträgt 1 MB.

Ein Partitionsschlüssel wird genutzt, um Datensätze zu isolieren und an verschiedene Shards eines Datenstroms zu leiten. Ein Partitionsschlüssel wird von Ihrem Datenproduzenten angegeben, während Daten einem Kinesis Datenstrom hinzugefügt werden. Angenommen, Sie haben einen Datenstrom mit zwei Shards (Shard 1 und Shard 2). Nun können Sie Ihren Datenproduzenten so konfigurieren, dass er zwei Partitionsschlüssel verwendet (Schlüssel A und Schlüssel B), sodass alle Datensätze mit dem Schlüssel A zu Shard 1 und alle Datensätze mit Schlüssel B zu Shard 2 hinzugefügt werden.

Eine Sequenznummer ist eine eindeutige Kennung für jeden einzelnen Datensatz. Sequenznummern werden von Amazon Kinesis zugewiesen, wenn ein Datenproduzent den Vorgang PutRecord oder PutRecords-betrieb aufruft, um einem Amazon-Kinesis-Datenstrom Daten hinzuzufügen. Sequenznummern für denselben Partitionsschlüssel steigen im Allgemeinen mit der Zeit. Je länger der Zeitraum zwischen PutRecord- oder PutRecords-Anforderungen, desto größer die Sequenznummer.

Der Kapazitätsmodus von Kinesis Data Streams bestimmt, wie eine Kapazität verwaltet wird und wie der Verbrauch für einen Datenstrom berechnet wird. Sie können zwischen bereitgestellten und on-demand-Modi wählen. Im Bereitstellungs-Modus spezifizieren Sie die Anzahl der Shards für den Datenstrom. Die Gesamtkapazität eines Datenstroms ist die Summe der Kapazitäten seiner Shards. Sie können die Anzahl der Shards in einem Datenstrom je nach Bedarf erhöhen oder verringern, und Sie zahlen die Anzahl der Shards zu einer stündlichen Rate. Im On-Demand-Modus, verwaltet AWS die Shards, um den notwendigen Durchsatz bereitzustellen. Sie zahlen nur für den tatsächlich verwendeten Durchsatz und Kinesis Data Streams passt automatisch Ihren Bedarf an Workload-Durchsatz an, wenn diese hoch- oder runterfahren. Alle Kinesis Data Streams schreiben und lesen APIs, mitsamt wahlweisen Funktionen, wie erweiterter Aufbewahrung und verstärktes Fan-Out, werden in beiden Kapazitätmodi unterstützt.

On-Demand-Modus ist am Besten für Workloads geeignet, mit unvorhersehbaren und sehr variablen Verkehrsmustern. Sie sollten diesen Modus verwenden, wenn Sie es vorziehen, dass AWS die Kapazität anstelle von Ihnen verwaltet oder wenn sie lieber pro Durchsatz bezahlen. Bereitstellungs-Modus ist am Besten für vorhersehbaren Verkehr geeignes, wo Kapazitätsanforderungen leicht vorhersehbar sind. Sie sollten den Bereitstellungs-Modus in Betracht ziehen, falls Sie fein abgestufte Kontrolle über die Art und Weise, wie Daten über Shards verteilt werden, haben möchten. Bereitstellungs-Modus ist ebenfalls geeignet, falls Sie zusätzliche Shards bereitstellen möchten, damit die Konsumenten-Anwendungen einen höheren Lese-Durchsatz haben sollen, und um den Gesamtprozess zu beschleunigen.

Ja. Sie können zwischen On-Demand- und Bereitstellungmodus zwei Mal täglich wechseln. Die Shardanzahl Ihres Datenstroms bleibt gleich, wenn Sie zwischen Bereitstellungsmodus und On-Demand-Modus wechseln. Mit dem Wechsel von Bereitstellungs- zu On-Demand-Kapazitäts-Modus, behält Ihr Datenstrom die Shardanzahl, die er vor der Übertragung hatte. Ab diesem Zeitpunkt, überwacht Kinesis Data Streams Ihren Datenverkehr und skaliert die Shardanzahl auf diesean On-Demand-Datenstrom entsprechend zu Ihrem Verkehr, erhöhen oder verringern.

Sie können einem Kinesis-Datenstrom Daten über PutRecord- und PutRecords-Vorgänge, KPL oder Amazon Kinesis Agent hinzufügen.

Mit dem PutRecord-Vorgang ist ein einzelner Datensatz in einem API-Aufruf möglich; die PutRecords-Vorgänge lassen mehrere Datensätze in einem API-Aufruf zu. Weitere Informationen finden Sie unter PutRecord und PutRecords.

KPL ist eine benutzerfreundliche und umfassend konfigurierbare Bibliothek, mit der Sie Daten in einen Amazon-Kinesis-Datenstrom einleiten können. KPL ist eine einfache, asynchrone und verlässliche Oberfläche, die Ihnen dabei hilft, unter Einsatz minimaler Client-Ressourcen schnell einen höheren Produzentendurchsatz zu erzielen.

Amazon Kinesis Agent ist eine vorgefertigte Java-Anwendung, die eine einfache Methode zur Erfassung von Daten und deren Einspielen in Ihren Amazon-Kinesis-Datenstrom ermöglicht. Sie können den Agenten in Serverumgebungen auf Linux-Basis, auf Protokollservern und Datenbankservern installieren. Der Agent überwacht bestimmte Dateien und sendet fortlaufend Daten in Ihren Daten-Stream. Weitere Informationen finden Sie unter Schreiben Sie mit Kundendienstmitarbeitern.

Ihr Daten-Blob, Partitionsschlüssel und Datenstrom-Name sind die Pflichtparameter eines Aufrufs von PutRecord oder PutRecords. Die Größe Ihres Datenblobs (vor der Base64-Kodierung) und der Partitionsschlüssel werden bei der Ermittlung des Datendurchsatzes Ihres Amazon Kinesis-Daten-Streams berücksichtigt, der von der Anzahl der Shards innerhalb des Daten-Streams bestimmt wird.

Ein Konsument ist eine Anwendung, die alle Daten von einem Kinesis Data Stream verarbeitet. Sie können zwischen geteilten Fan-out und verstärkten Fan-out Konsumententypen wählen, um Daten von einem Kinesis-Datenstrom zu lesen. Die geteilten Fan-out Kosumenten teilen alle die 2 MB/Sekunde des Lese-Durchsatzes einer Shard, die Beschränkung von fünf Transaktionen pro Sekunde und benötigen die Verweundung von GetRecords API. Ein verstärkter Fan-out Konsument bekommt seine 2 MB/Sekunde für Lese-Durchsatz, welches mehreren Konsumenten ermöglicht, Daten vom gleichen Strom parallel zu lesen, ohne erfassen von Lese-Durchsatz mit anderen Konsumenten. Sie müssen die SubscribeToShard API mit den verstärkten Fan-out Konsumenten verwenden. Wir empfehlen die Verwendung von verstärkten Fan-out Konsumenten, falls sie mehr als einen Konsumenten an Ihren Datenstrom hinzufügen möchten.

Sie können verwaltete Services wie AWS Lambda, Amazon Managed Service für Apache Flink oder AWS Glue verwenden, um die in Kinesis-Datenströmen gespeicherten Daten zu verarbeiten. Diese verwalteten Services kümmern sich um Bereitstellung und Verwaltung der unterliegenden Infrastruktur, damit Sie sich auf das Schreiben Ihrer Geschäftslogik konzentrieren können. Sie können auch Daten an Amazon S3, Amazon OpenSearch Service, Amazon Redshift und benutzerdefinierte HTTP-Endpunkte, mittels vorgefertigter Integration mit Kinesis Data Firehose liefern, die in Kinesis Data Streams gespeichert sind. Sie können ebenfalls benutzerdefinierte Anwendungen aufbauen, und zwar mithilfe von Amazon Kinesis Client Library, einer vorgefertigten Library oder der Amazon Kinesis Data Streams API.

KCL für Java, Python, Ruby, Node.js, .NETist eine vordefinierte Bibliothek, mit deren Hilfe Sie bequem Amazon-Kinesis-Anwendungen zum Lesen und Verarbeiten von Daten aus einem Amazon-Kinesis-Datenstrom entwickeln können.

Die KCL übernimmt automatisch komplexe Aufgaben wie die Anpassung an Änderungen beim Datenstrom-Volumen, die Lastenverteilung für Streaming-Daten, die Koordination verteilter Services und fehlertolerante Datenverarbeitung. Die KCL ermöglicht, dass Sie sich beim Entwickeln von Anwendungen ganz auf die Geschäftslogik konzentrieren können. Beziehen Sie sich hier auf die Kinesis-Data-Streams-Dokumentation, für weitere Details von KCL.

Bei der SubscribeToShard-API handelt es sich um eine hochleistungsfähige Streaming-API, die Daten von Shards zu Benutzern leitet, über eine beständige Verbindung, ohne dass ein Anforderungszyklus vom Client gestartet wird. Die SubscribeToShard-API verwendet das HTTP/2-Protokoll, um Daten an registrierte Benutzer zu übertragen wenn neue Daten beim Shard eintreffen, in der Regel innerhalb von 70 Millisekunden, und bietet somit eine um ca. 65 % schnellere Bereitstellung im Vergleich zur GetRecords-API. Die Benutzer haben den Vorteil einer schnellen Bereitstellung, auch wenn mehrere registrierte Benutzer auf denselben Shard zugreifen.

Erweitertes Rundsenden ist eine optionale Funktion für Benutzer von Kinesis Data Streams, die logische Durchsatz-Pipes von 2 MB/Sek zwischen Kunden und Shards bietet. Auf diese Weise können die Kunden die Anzahl der Benutzer skalieren, die unter Beibehaltung hoher Leistung parallel einen Datenstrom lesen.

Sie sollten das erweiterte Rundsenden nutzen, über das Sie verfügen oder das Sie erwarten, wobei mehrere Benutzer gleichzeitig Daten von einem Strom abrufen, oder, wenn Sie mindestens einen Benutzer haben, der die SubscribeToShard-API benötigt, um Datenbereitstellungsgeschwindigkeiten von sub-200 Millisekunden zwischen Bereitstellern und Benutzern zu ermöglichen.

Die Benutzer verwenden das erweiterte Rundsenden, indem Sie Daten mit der SubscribeToShard-API abrufen. Der Name des registrierten Benutzers wird in der SubscribeToShard-API verwendet, was eine Nutzung der Vorteile des erweiterten Rundsendens ermöglicht, das dem Benutzer zur Verfügung gestellt wird.

Ja. Sie können mehrere Benutzer besitzen, die das erweiterte Rundsenden verwenden und andere das erweiterte Rundsenden nicht zur selben Zeit verwenden. Die Nutzung des erweiterten Rundsendens hat keine Auswirkung auf das Shards-Limit für die herkömmliche GetRecords-Nutzung.

Ja. Zur Nutzung von SubscribeToShard müssen Sie Ihre Benutzer registrieren und durch die Registrierung wird dann erweitertes Rundsenden aktiviert. Standardmäßig verwenden Ihre Benutzer erweitertes Rundsenden automatisch, wenn Daten über SubscribeToShard abgerufen werden.

Ein neuer Datenstrom, der im On-Demand-Modus erstellt wurde, hat ein Kontingent von 4 MB/Sekunde und 4 000 Akten pro Sekunde für Schreiben. Standardmäßig werden diese Streams automatisch auf 200 MB/Sekunde skaliert und 200 000 pro Sekunde für Schreiben.

Ein Datenstrom im On-Demand-Modus passt bis zu doppelt seiner vorhegehenden Höchstleistung, den Schreib-Durchsatz an, den er über die letzten 30 Tage beobachtet hat. Wenn der Schreib-Durchsatz Ihres Datenstroms einen neuen Höhepunkt erreicht, skaliert Kinesis Data Streams die Stream-Kapazität automatisch. Falls beispielsweise Ihr Datenstrom einen Schreib-Durchsatz hat, der zwischen 10 MB/Sekunde und 40 MB/Sekunde variiert, wird Kinesis Data Streams sicherstellen, dass Sie ganz einfach das Doppelte des letzten Durchsatz-Höhepunktes von 80 MB/Sekunde erreichen. Falls anschließend der gleiche Datenstrom einen neuen Höhepunkt von 50 MB/Sekunde aufrecht erhält, wird Data Streams sicherstellen, das ausreichend Kapazität besteht, um 100 MB/Sekund von Schreib-Durchsatz zu erfassen. Sie werden jedoch „ProvisionedThroughputExceeded“-Ausnahmen sehen, falls Ihr Verkehr mehr als doppelt im Vergleich zum zuvorigen Höhepunkt wächst, mit einer Dauer von 15 Minuten. Sie müssen diese gedrosselten Anforderungen erneut versuchen.

Die Lese-Kapazität vom On-Deman-Modus erhöht im Verhältnis den Schreib-Durchsatz, um sicherzustellen, dass Konsumenten-Anwendungen immer einen angemessenen Lese-Durchsatz haben, um eingehende Daten in Echtzeit zu verarbeiten. Sie bekommen mindestens den doppelten Schreib-Durchsatz als Lese-Daten, mithilfe von GetRecords API. Wir empfehlen die Verwendung von einem Konsumenten mit GetRecord API, damit dieser genug Platz hat aufzuholen, wenn die Anwendung von sich von Ausfallzeiten erholen muss. Um mehr als nur eine Konsumenten-Anwendung hinzuzufügen, müssen Sie den verstärkten Fan-out verwenden, welcher die Zugabe von bis zu 20 Konsumentenin einen Datenstrom unterstützt, mithilfe der SubscribeToShard API, von denen jeder einen benannten Durchsatz hat.

Der Durchsatz eines Kinesis-Datenstroms im Bereitstellungsmodus ist so konzipiert, dass er unbegrenzt skaliert werden kann, indem die Anzahl der Shards innerhalb eines Datenstroms erhöht wird.

Sie können die Kapazität von Kinesis Data Stream im Bereitstellungsmodus hochskalieren, indem Sie die bestehenden Shards mittels SplitShard API aufteilen. Sie können Kapazität herabsetzen, indem zwei Shards mittels MergeShard API verschmolzen werden. Alternativ können Sie die UpdateShardCount API verwenden, um eine Stream-Kapazität auf eine spezielle Shardanzahl aufzustocken (oder herabzusetzen).

Der Durchsatz eines Kinesis-Datenstroms wird von der Anzahl der Shards innerhalb eines Datenstroms bestimmt. Befolgen Sie die Schritte weiter unten und schätzen Sie die anfängliche Anzahl der Shards, die Ihr Datenstrom im Bereitstellungsmodus benötigt. Beachten Sie, dass Sie die Anzahl der Shards in Ihrem Datenstrom über resharding dynamisch anpassen können.

Schätzen Sie die durchschnittliche Größe des Datensatzes, der in den Datenstrom geschrieben wird, in Kilobyte (KB), gerundet auf das nächste 1 Kilobyte. (average_data_size_in_KB)

Schätzen Sie die Anzahl der Aufnahmen pro Sekunde. (number_of_records_per_second)

Legen Sie die Anzahl der Amazon Kinesis-Anwendungen fest, die gleichzeitig und unabhängig Daten aus dem Datenstrom nutzen. (number_of_consumers)

Berechnen Sie die eingehende Schreibbandbreite in KB (Eingehende_Schreibbandbreite_in_KB). Sie ergibt sich aus Durchschnittliche_Datengröße_in_KB multipliziert mit Anzahl_von_Datensätzen_pro_Sekunde.

Berechnen Sie die ausgehende Lesebandbreite in KB (Ausgehende_Schreibbandbreite_in_KB). Sie ergibt sich aus Eingehende_Schreibbandbreite_in_KB multipliziert mit Anzahl_der_Nutzer.

Anschließend können Sie dann die erste Anzahl der Shards (number_of_shards) berechnen, die Ihre Datenstrom benötigt, mit der folgenden Formel: number_of_shards = max (incoming_write_bandwith_in_KB/1000, outging_read_bandwith_in _KB/2000)

Der Durchsatz eines Kinesis-Datenstroms ist so konzipiert, dass er unbegrenzt skaliert werden kann. Das standardmäßige Shard-Kontingent beträgt 500 Shards pro Stream für die folgenden AWS-Regionen: USA Ost (Nord-Virginia), USA West (Oregon) und Europa (Irland). Für alle anderen Regionen beträgt das Standard-Shard-Kontingent 200 Shards pro Stream. Sie können die Erhöhung des Shard-Kontingents über die AWS-Service-Kontingent-Konsole anfordern.

Im Bereitstellungsmodus werden die Kapazitätsgrenzen eines Kinesis-Datenstroms werden von der Anzahl der Shards innerhalb eines Datenstroms bestimmt. Die Grenzen können entweder vom Datendurchsatz oder von der Anzahl der PUT-Datensätze überschritten werden. Wenn die Kapazitätsgrenzen überschritten werden, werden Put-Datenaufrufe mit der Ausnahme ProvisionedThroughputExceeded zurückgewiesen. Falls dies durch einen vorübergehenden Anstieg der Eingangsdatenrate des Datenstroms verursacht wurde, werden die Anforderungen durch erneute Versuche seitens des Datenproduzenten schließlich erfüllt. Falls dies durch einen anhaltenden Anstieg der Eingangsdatenrate des Daten-Streams verursacht wurde, sollten Sie die Anzahl der Shards innerhalb Ihres Datenstroms erhöhen, damit ausreichende Kapazitäten vorhanden sind und die Put-Datenaufrufe konsistent abgeschlossen werden. In beiden Fällen können Sie anhand der Amazon CloudWatch-Metriken mehr über die Änderung der Eingangsdatenrate des Daten-Streams und das Auftreten der Ausnahme ProvisionedThroughputExceeded erfahren.

Im Bereitstellungsmodus werden die Kapazitätsgrenzen eines Kinesis-Datenstroms werden von der Anzahl der Shards innerhalb eines Datenstroms bestimmt. Die Grenzen können entweder vom Datendurchsatz oder von der Anzahl der gelesenen-Datenaufrufe überschritten werden. Wenn die Kapazitätsgrenzen überschritten werden, werden die gelesenen-Datenaufrufe mit der Ausnahme ProvisionedThroughputExceeded zurückgewiesen. Falls dies durch einen vorübergehenden Anstieg der Ausgangsdatenrate des Datenstroms verursacht wurde, werden die Anforderungen durch erneute Versuche seitens der Amazon Kinesis-Anwendung schließlich erfüllt. Falls dies durch einen anhaltenden Anstieg der Ausgangsdatenrate des Datenstroms verursacht wurde, sollten Sie die Anzahl der Shards innerhalb Ihres Stroms erhöhen, damit ausreichende Kapazitäten vorhanden sind und die gelesenen-Datenaufrufe konsistent abgeschlossen werden. In beiden Fällen können Sie anhand der Amazon CloudWatch-Metriken mehr über die Änderung der Ausgangsdatenrate des Daten-Streams und das Auftreten der Ausnahme ProvisionedThroughputExceeded erfahren.

Die Standardaufbewahrungsdauer von 24 Stunden deckt Szenarien ab, in denen zeitweise auftretende Verzögerungen bei der Verarbeitung das Aufholen mit den Echtzeitdaten erfordern. Eine 7-tägige Aufbewahrung ermöglicht Ihnen, Daten bis zu 7 Tage lang erneut zu verarbeiten, um potenzielle nachgelagerte Datenverluste zu beheben. Mit einer langfristigen Datenaufbewahrung von mehr als 7 und bis zu 365 Tagen können Sie alte Daten für Anwendungsfälle wie Algorithmus-Back-Testing, Datenspeicher-Auffüllungen und Prüfungen erneut verarbeiten.

Ja. Sie können dieselben getShardIterator-, GetRecords- und SubscribeToShard-APIs verwenden, um Daten zu lesen, die länger als 7 Tage gespeichert sind. Die Verbraucher können den Iterator an den gewünschten Ort im Stream verschieben, die Shard-Map (einschließlich offenen und geschlossenen) abrufen und die Datensätze lesen.

Ja. Es stehen API-Verbesserungen für ListShards-, GetRecords- und SubscribeToShard-APIs zur Verfügung. Sie können die neue Filteroption mit dem in der ListShards-API verfügbaren TimeStamp-Parameter verwenden, um die Shard-Map effizient abzurufen und die Leistung beim Lesen alter Daten zu verbessern. Mit dem TimeStamp-Filter von ListShards können Anwendungen Shards ab dem Zeitpunkt erkennen und aufzählen, an dem Sie Daten erneut verarbeiten möchten, und müssen nicht mehr am Trimmhorizont beginnen. GetRecords und SubscribeToShards besitzen ein neues Feld, ChildShards, mit dem Sie die untergeordneten Shards schnell erkennen können, wenn eine Anwendung das Lesen von Daten aus einem geschlossenen Shard beendet hat, anstatt die Shard-Map erneut durchlaufen zu müssen. Durch die schnelle Erkennung von Shards werden die Rechenressourcen der Anwendung für Ströme jeder Größe effizient genutzt, unabhängig von der Dauer der Datenaufbewahrung.

Sie sollten diese API-Verbesserungen in Betracht ziehen, wenn Sie Daten länger aufbewahren und die Kapazität Ihres Stroms regelmäßig skalieren möchten. Stream-Skalierungsvorgänge schließen vorhandene Shards und öffnen neue untergeordnete Shards. Die Daten in allen offenen und geschlossenen Shards bleiben bis zum Ende des Aufbewahrungszeitraums erhalten. Dies bedeutet, dass die Gesamtzahl der Shards linear mit einer längeren Aufbewahrungsdauer und mehreren Skalierungsvorgängen ansteigt. Für diese Vergrößerung der Shard-Map müssen Sie ListShards mit TimeStamp-Filter und ChildShards-Feld in GetRecords sowie die SubscribeToShard-API verwenden, damit Shards für den Datenabruf effizient ermittelt werden können. Für diese Funktionen müssen Sie Ihre KCL auf die neueste Version (1.x für Standardkonsumenten und 2.x für Fan-out-Konsumenten) aktualisieren.

Ja. Kunden von Kinesis Data Streams können die AWS Glue Schema Registry, eine Serverless-Feature von AWS Glue, entweder über die KPL und KCL oder über die AWS Glue Schema Registry APIs im AWS SDK for Java nutzen. Das Schema Registry ist ohne zusätzliche Kosten verfügbar. 

Besuchen Sie die Benutzerdokumentation von Schema Registry für die ersten Schritte und weitere Informationen.

Sie haben zwei Möglichkeiten, um den Durchsatz Ihres Datenstroms zu verändern. Skalieren Sie entweder mithilfe der UpdateShardCount API oder den AWS-Managementkonsole die Anzahl der Shards in einem Daten-Stream, oder ändern Sie den Durchsatz eines Amazon Kinesis-Datenstroms, indem Sie die Anzahl der Shards innerhalb des Daten-Streams (Resharding) anpassen.

In der Regel werden angeforderte Skalierungen innerhalb weniger Minuten vorgenommen. Größere Skalierungen dauern länger als kleinere.

Ja. Sie können Ihrem Kinesis-Datenstrom weiterhin Daten hinzufügen oder daraus lesen, während Sie den Durchsatz des Datenstroms mit UpdateShardCount oder per Resharding ändern oder wenn Kinesis Data Streams dies im On-Demand-Modus automatisch tut.

Die Managementkonsole von Amazon Kinesis Data Streams zeigt wichtige Betriebs- und Leistungsmetriken an, wie etwa Durchsatz bei Dateneingang und -ausgang Ihrer Kinesis-Datenstroms. Kinesis Data Streams ist auch in Amazon CloudWatch integriert, sodass Sie CloudWatch-Metriken für Ihre Datensträme- und Shards innerhalb dieser Datenströme sammeln, anzeigen und analysieren können. Weitere Informationen über Amazon-Kinesis-Data-Streams-Metriken finden Sie unter Überwachung von Amazon Kinesis Data Streams mit Amazon CloudWatch.

Bitte beachten Sie, dass alle Metriken auf Stream-Ebene kostenlos sind. Alle aktivierten Shard-Ebenen-Metriken werden gemäß Preise zu Amazon CloudWatch in Rechnung gestellt.

Kinesis Data Streams ist mit AWS Identity and Access Management (IAM) kombiniert, einem Service, der Ihnen dabei hilft, den Zugriff auf Ihre AWS-Services und Ressourcen für Ihre Benutzer sicher zu steuern. Sie können beispielsweise eine Richtlinie erstellen, die es nur einem bestimmten Benutzer oder einer bestimmten Gruppe ermöglicht, Daten zu Ihrem Datenstrom hinzuzufügen. Sie können Ihrem Datenstrom oder registrierten Verbraucher auch eine ressourcenbasierte Richtlinie hinzufügen, um den Zugriff auf Ressourcenebene zu kontrollieren. Weitere Informationen zur Zugriffsverwaltung und Steuerung Ihres Datenstroms finden Sie unter Zugriffskontrolle zu Ressourcen von Amazon Kinesis Data Streams mithilfe von IAM.

Sie können die rollenbasierte oder ressourcenbasierte IAM-Richtlinie verwenden, um den Zugriff mit einem anderen Konto zu teilen. Um den Zugriff mit einer kontoübergreifenden AWS-Lambda-Funktion zu teilen, fügen Sie Ihrem Datenstrom oder Verbraucher eine ressourcenbasierte Richtlinie hinzu, um Zugriff auf die Ausführungsrolle der Lambda-Funktion zu gewähren. Weitere Informationen finden Sie unter Verwenden von AWS Lambda mit Amazon Kinesis.

Kinesis Data Streams ist integriert in Amazon CloudTrail, einem Service, der Aufrufe von AWS-APIs für Ihr Konto aufzeichnet und Protokolldateien an Sie übermittelt. Weitere Informationen zur Protokollierung von API-Aufrufen und eine Liste der unterstützten Amazon Kinesis API-Vorgänge finden Sie unter Protokollierung von Amazon Kinesis API-Aufrufen mit Amazon CloudTrail.

In Kinesis Data Streams können Sie Ihre Kinesis-Datenströme mit Tags versehen, wodurch das Ressourcen- und Kostenmanagement vereinfacht wird. Ein Tag ist ein benutzerdefiniertes Label in Form eines Schlüssel-Wert-Paares, mit dessen Hilfe Sie AWS-Ressourcen organisieren können. Sie können Ihre Datenströme zum Beispiel nach Kostenstellen mit Kategorien versehen, anhand derer Sie Ihre Kosten Kinesis-Data-Streams kategorisieren und nachverfolgen können. Weitere Informationen über Amazon Kinesis Data Streams finden Sie unter Markierung Ihrer Amazon Kinesis Data Streams.

Amazon Kinesis ist standardmäßig sicher. Nur die Konten- und Datenstrom-Besitzer haben Zugang zu den von ihnen erstellten Kinesis-Ressourcen. Kinesis unterstützt Funktionen zur Benutzerauthentifizierung, um den Zugriff auf die Daten zu kontrollieren. Sie können IAM-Richtlinien verwenden, um selektiv Benutzern und Benutzergruppen Zugriffsrechte zu erteilen. Sie können Ihre Daten über SSL-Endpunkte mithilfe des HTTPS-Protokolls sicher in Kinesis einleiten und aus Kinesis holen. Wenn Sie zusätzliche Sicherheit brauchen, können Sie serverseitige Verschlüsselung mit Schlüsseln von AWS Key Managment Service (AWS KMS) verwenden, um in Ihrem Datenstrom gesicherte Daten zu verschlüsseln. AWS KMS erlaubt Ihnen, in AWS erzeugte KMS-Schlüssel für die Verschlüsselung zu verwenden oder Ihren eigenen KMS-Schlüssel in AWS KMS mitzubringen, wenn Sie dies bevorzugen. Schließlich können Sie Ihre eigenen Verschlüsselungsbibliotheken zur Verschlüsselung von Daten Client-seitig verwenden, bevor Sie die Daten in Kinesis einspeisen.

Ja. Sie können privat über Ihre Amazon VPC auf die Kinesis Datenstrom-APIs zugreifen, indem Sie VPC-Endpunkte erstellen. Mit VPC-Endpunkten wird das Routing zwischen der VPC und Kinesis Data Streams durch das AWS-Netzwerk gesteuert, ohne dass ein Internet-Gateway, ein NAT-Gateway oder eine VPN-Verbindung erforderlich ist. Die neueste Generation der von Kinesis Data Streams verwendeten VPC-Endpunkte wird von AWS PrivateLink unterstützt. Diese Technologie ermöglicht die private Konnektivität zwischen AWS-Services, indem eine Elastic-Network-Schnittstelle (ENI) mit privaten IP-Adressen in Ihren VPCs genutzt werden. Weitere Informationen zu PrivateLink erhalten Sie in der PrivateLink-Dokumentation.

Ja, und es gibt zwei Möglichkeiten dafür. Sie können serverseitige Verschlüsselung verwenden; dabei handelt es sich um eine voll-verwaltete Funktion, die Daten automatisch ver- und entschlüsselt, während Sie diese in den Datenstrom einleiten oder herausholen. Sie können verschlüsselte Daten an einen Datenstrom schreiben, indem Sie auf der Clientseite ver- und entschlüsseln.

Sie können aus folgenden Gründen eine serverseitige Verschlüsselung gegenüber einer clientseitigen Verschlüsselung bevorzugen:

• Es ist schwierig, eine clientseitige Verschlüsselung durchzusetzen.
• Sie möchten eine zweite Sicherheitsebene zusätzlich zur clientseitigen Verschlüsselung.
• Es ist schwierig, clientseitige Schlüsselverwaltungs-Schemen zu implementieren

Die serverseitige Verschlüsselung für Kinesis Data Streams verschlüsselt Daten automatisch mithilfe eines benutzerdefinierten AWS KMS-Schlüssels, bevor sie auf die Speicherebene des Daten-Streams geschrieben werden und entschlüsselt die Daten, nachdem sie aus dem Speicher geholt wurden. Die Verschlüsselung macht Schreibvorgänge unmöglich und Nutzlasten und Partitionsschlüssel unlesbar, außer der Benutzer, der auf den Daten-Stream schreibt oder daraus liest, verfügt über die Berechtigung, den für die Verschlüsselung auf dem Daten-Stream ausgewählten Schlüssel zu nutzen. Deshalb kann eine serverseitige Verschlüsselung das Erfüllen interner Sicherheits- und Compliance-Anforderungen beim Verwalten Ihrer Daten vereinfachen.

Bei einer serverseitigen Verschlüsselung brauchen sich Anwendungen auf der Clientseite (Produzenten und Verbraucher) der Verschlüsselung nicht bewusst sein; sie müssen KMS-Schlüssel oder kryptografische Vorgänge nicht verwalten, und Ihre Daten sind verschlüsselt, wenn sie im Kinesis Data Streams-Service gespeichert oder in Bewegung sind. Alle von der serverseitigen Verschlüsselungsfunktion verwendeten KMS-Schlüssel werden vom AWS KMS bereitgestellt. AWS KMS erleichtert die Verwendung eines AWS-verwalteten KMS-Schlüssels für Kinesis (eine „One-Click“-Verschlüsselungsmethode), Ihres eigenen, vom Kunden verwalteten AWS KMS-Schlüssels, oder eines KMS-Schlüssels, den Sie zur Verschlüsselung importiert haben.

Ja, es gibt ein Handbuch „Erste Schritte“ in der Benutzerdokumentation.

Möglicherweise. Das hängt vom Schlüssel ab, den Sie für die Verschlüsselung und die Berechtigungen zum Verwalten des Zugriffs auf den Schlüssel verwenden.

• Wenn Sie den AWS-verwalteten KMS-Schlüssel für Kinesis (Schlüssel-Alias = aws/kinesis) verwenden, hat die Aktivierung oder Deaktivierung der Verschlüsselung mit diesem Schlüssel keine Auswirkungen auf Ihre Anwendungen.
• Wenn Sie einen anderen KMS-Schlüssel verwenden, wie einen benutzerdefinierten AWS KMS-Schlüssel oder einen, den Sie in den AWS KMS-Service importiert haben, und wenn Ihre Produzenten und Verbraucher von einem Daten-Stream keine Berechtigung zur Verwendung des für die Verschlüsselung eingesetzten KMS-Schlüssel haben, werden Ihre PUT- und GET-Anforderungen fehlschlagen. Bevor Sie eine serverseitige Verschlüsselung verwenden können, müssen Sie AWS KMS-Schlüsselrichtlinien so konfigurieren, dass sie das Verschlüsseln und Entschlüsseln von Nachrichten erlauben. Bitte konsultieren Sie für Beispiele und weitere Informationen zu AWS KMS-Berechtigungen AWS KMS API-Berechtigungen: Actions and Resources Reference im AWS Key Management Service Developer Guide oder die Berechtigungsrichtlinien in der Benutzerdokumentation zur serverseitigen Verschlüsselung von Kinesis Data Streams.

Ja, wenn Sie jedoch den AWS-verwalteten KMS-Schlüssel für Kinesis verwenden und das kostenlose Nutzungskontingent der KMS API nicht überschreiten, dann ist Ihre Nutzung der serverseitigen Verschlüsselung kostenlos. Im Folgenden werden die Kosten durch Ressourcen beschrieben:

Schlüssel:

Der AWS-verwaltete KMS-Schlüssel für Kinesis (Alias = „aws/kinesis“) ist kostenlos.
Kunden-verwaltete KMS-Schlüssel unterliegen den KMS-Schlüssel-Kosten. Weitere Informationen.

KMS-API-Nutzung:

Für jeden KMS-Schlüssel (auch für die benutzerdefinierten) fallen API-Nutzungsgebühren an. Kinesis Data Streams ruft die KMS bei der Rotation der Datenschlüssen ungefähr alle 5 Minuten auf. In einem Monat mit 30 Tagen sollten sich die Gesamtkosten der von einem Kinesis-Datenstrom initiierten KMS API-Aufrufe auf wenige Euro belaufen. Bitte beachten Sie, dass diese Kosten mit der Anzahl an Anmeldedaten, die Sie für Ihre Datenproduzenten und -verbraucher verwenden, steigen, da für die einzelnen Anmeldedaten je ein individueller API-Aufruf an AWS KMS erforderlich ist. Wenn Sie die IAM-Rolle für die Authentifizierung verwenden, werden bei jedem Aufruf zu Übernahme der Rolle individuelle Benutzeranmeldedaten erstellt und Sie möchten die vom Aufruf zu Übernahme der Rolle generierten Benutzeranmeldedaten möglicherweise cachen, um KMS-Kosten zu sparen.

Die serverseitige Verschlüsselung von Kinesis Data Streams ist in der AWS-GovCloud-Region und in allen öffentlichen Regionen, ausgenommen China (Peking), verfügbar.

All diese Vorgänge können mithilfe der AWS-Managementkonsole oder des AWS SDK durchgeführt werden. Weitere Informationen erhalten Sie im Handbuch „Erste Schritte“ zum Thema serverseitige Verschlüsselung mit Kinesis Data Streams.

Kinesis Data Streams verwendet einen AES-GCM-256-Algorithmus zur Verschlüsselung.

Nein, nur neue Daten, die auf den Datenstrom geschrieben werden, werden durch die neue Anwendung der Verschlüsselung verschlüsselt (oder bleiben unverschlüsselt).

Die serverseitige Verschlüsselung verschlüsselt die Nutzlast der Nachricht sowie den Partitionsschlüssel, der durch die Produzentenanwendungen des Daten-Streams festgelegt wird.

Die serverseitige Verschlüsselung ist eine für Streams spezifische Funktion.

Ja, Sie können mithilfe der AWS-Managementkonsole oder des AWS SDK einen neuen KMS-Schlüssel aussuchen, der auf einen bestimmten Datenstrom angewendet werden soll.

Nein. Kinesis Data Streams fällt derzeit nicht unter das kostenlose Nutzungskontingent für AWS. Das kostenlose Kontingent für AWS ist ein Programm, das einen kostenlosen Test bestimmter AWS-Services bietet. Weitere Informationen über das kostenlose AWS-Kontingent finden Sie unter „Kostenloses AWS-Kontingent“.

Unser Kinesis Data Streams SLA garantiert einen monatlichen Verfügbarkeitsprozentsatz von mindestens 99,9 % für Kinesis Data Streams.

Sie sind für eine SLA-Gutschrift für Kinesis Data Streams im Rahmen des Kinesis Data Streams SLA anspruchsberechtigt, wenn mehr als eine Availability Zone, in der Sie eine Aufgabe ausführen, innerhalb derselben Region während eines beliebigen monatlichen Abrechnungszyklus einen monatlichen Verfügbarkeitsprozentsatz von weniger als 99,9 % aufweist.

Ausführliche Informationen zu allen Bestimmungen des SLA sowie Einzelheiten zur Geltendmachung eines Anspruchs finden Sie auf der SLA-Detailsseite zu Amazon Kinesis Data Streams.

Kinesis Data Streams verwendet nutzungsabhängige Preisberechnungen. Es fallen keine Vorabkosten oder Mindestgebühren an und Sie zahlen nur für die Ressourcen, die Sie nutzen. Kinesis Data Streams hat zwei Kapazitätsmodi – On-Demand und Bereitstellung – beide haben spezielle Abrechnungsoptionen.

Im On-Demand-Modus müssen Sie vorher nicht festlegen, wie viel Durchsatz Lesen und Schreiben Sie von Ihrer Anwendung erwarten durchzuführen. Im On-Demand-Modus basieren die Preise auf dem Volumen der erfassten und abgerufenen Daten, sowie eine Gebühr pro Stunde für jeden Datenstrom in Ihrem Konto. Es gibt zusätzliche Gebühren für mögliche Funktionen: Erweiterte Datenaufbewahrung (über die ersten 24 Stunden hinaus und innerhalb der ersten sieben Tage), Langzeit-Datenaufbewahrung (über sieben Tage hinaus und bis zu einem Jahr), sowie erhöhter Fan-Out. Weitere Informationen zu den Kosten von Kinesis Data Streams finden Sie unter Preise für Amazon Kinesis Data Streams.

Mit dem Bereitstellungsmodus, spezifizieren Sie die Anzahl der für Ihre Anwendung notwendigen Shards, basierend auf der Anforderungsrate von Schreiben und Lesen. Ein Shard ist eine Kapazitätseinheit, die durchgehend 1 MB/Sek. Schreiben und 2 MB/Sek. Lesen bereitstellt. Jeder Shard wird Ihnen mit einem Stundensatz in Rechnung gestellt. Sie zahlen auch für Datensätze, die in Ihrem Kineses Datenstrom geschreiben wurden. Es entstehen zusätzliche Kosten, wenn Sie die wahlweise Funktion der erweiterten Aufbewahrung und verstärkte Fan-Out verwenden.

Es folgen zwei Kerndimensionen und drei optionale Dimensionen im Bereitstellungsmodus zu Kinesis Data Streams:

• Shard-Kosten pro Stunde, die sich nach der Anzahl der Shards in Ihrem Amazon Kinesis-Daten-Stream richten.
• Die Kosten der PUT-Nutzlasteinheit, die sich nach der Anzahl der Datensätze mit einer Größe von 25 KB richten, die Ihre Datenproduzenten Ihrem Datenstrom hinzufügen.

Optional:

• Für die erweiterte Datenspeicherung fallen optionale Kosten an, die durch die Anzahl von Shard-Stunden berechnet werden, die von Ihrem Daten-Stream benötigt werden. Wenn die erweiterte Datenspeicherung aktiviert ist, zahlen Sie die erweiterte Speicherungsgebühr für jeden Shard in Ihrem Stream.
• Die langfristige Datenaufbewahrung ist ein optionaler Kostenfaktor mit zwei Kostendimensionen: langfristige Datenspeicherung und langfristiger Datenabruf. Die langfristige Datenspeicherung gibt die Anzahl der GB-Monate an, in denen Daten für einen Zeitraum von mehr als 7 Tagen und bis zu 365 Tagen gespeichert werden. Der langfristige Datenabruf spiegelt die Anzahl der abgerufenen GB an Daten wider, die länger als 7 Tage gespeichert wurden.
• Erweitertes Rundsenden ist ein optionaler Kostenfaktor mit zwei Kostendimensionen: Benutzer-Shard-Stunden und Datenabrufe. Die Benutzer-Shard-Stunden geben die Anzahl der Shards in einem Stream wieder, multipliziert mit der Anzahl der Benutzer, die das erweiterte Rundsenden nutzen. Datenabrufe werden durch die Anzahl der GBs ermittelt, die den Benutzern über erweitertes Rundsenden bereitgestellt werden.

Weitere Informationen zu den Kosten von Kinesis Data Streams finden Sie unter Preise für Amazon Kinesis Data Streams.

Eine Kunden-Shard-Stunde wird berechnet, indem die Anzahl der registrierten Stream-Benutzer mit der Anzahl der Shards im Stream multipliziert wird. Sie zahlen nur für den anteilig aufgeteilten Teil der Stunde, für den der Benutzer für die Verwendung des erweiterten Rundsendens registriert ist. So kostet eine Benutzer-Shard-Stunde 0,015 USD für einen 10-Shard-Datenstrom; wenn dieser Benutzer das erweiterte Rundsenden nutzt, könnte er von 10 Shards lesen. Somit entsteht ein Benutzer-Shard-Stundensatz von 0,15 USD (1 Benutzer x 10 Shards x 0,015 USD pro Benutzer-Shard-Stunde). Wenn zwei Benutzer gleichzeitig für erweitertes Rundsenden registriert sind, würde die gesamte Benutzer-Shard-Gebühr 0,30 USD pro Stunde betragen (2 Benutzer x 10 Shards x 0,015 USD).

Kinesis Data Streams und Amazon MSK sind beliebte Datenstreaming-Plattformen, mit denen Sie Ihre eigenen Streaming-Workloads erstellen können, die Daten für spezielle Anforderungen verarbeiten. Beide Services sind skalierbar, sicher und hochverfügbar. Beide können für Streaming-Anwendungsfälle wie Web- und Protokollanalysen in Echtzeit, die Personalisierung von Kundenerlebnissen, ereignisgesteuerte Architekturen, IoT-Analysen und Betrugserkennung in Echtzeit eingesetzt werden. Bei der Wahl zwischen den beiden ist es wichtig, Ihren spezifischen Anwendungsfall und Ihre Anforderungen zu berücksichtigen. Hier sind einige Faktoren, die es zu berücksichtigen gilt:

Vertrautheit

•  Wenn Sie mit Streaming-Technologien noch nicht vertraut sind, verwenden Sie Kinesis Data Streams.
• Wenn Sie bereits Anwendungen haben, die auf Apache Kafka laufen, verwenden Sie MSK. MSK verfügt über ein vorhandenes Kafka-Migrationsprogramm (KMP) und einen Migrationsleitfaden, um die Migration zu vereinfachen.

Präferenz für Open Source

• Wenn Sie Open-Source-Technologien bevorzugen, empfehlen wir die Verwendung von MSK. Sowohl MSK als auch MSK Connect sind vollständig kompatibel mit Open-Source-Apache-Kafka bzw. Kafka Connect.

Kinesis Data Streams ermöglicht die Echtzeitverarbeitung gestreamter Big Data. Kinesis Data Streams bietet die Möglichkeit, Datensätze zu sortieren, sowie Datensätze in derselben Reihenfolge zu lesen bzw. an mehrere Amazon Kinesis-Anwendungen wiederzugeben. Die Amazon Kinesis Client Library (KCL) liefert sämtliche Datensätze für einen bestimmten Partitionsschlüssel für denselben Datensatzprozessor, wodurch es einfacher wird, mehrere Anwendungen aufzubauen, die denselben Kinesis-Datenstrom lesen (etwa um eine Zählung, Aggregation und Filterung durchzuführen). Amazon Simple Queue Service (Amazon SQS) bietet eine zuverlässige, hochgradig skalierbare, gehostete Warteschlange zum Speichern von Mitteilungen, während diese zwischen Computern weitergeleitet werden. Mit Amazon SQS können Sie bequem Daten zwischen verteilten Anwendungskomponenten verschieben sowie Anwendungen aufbauen, in denen Nachrichten unabhängig verarbeitet werden (mit Bestätigungs-/Ablehnungssemantik auf Nachrichtenebene), etwa in automatisierten Workflows.

Wir empfehlen Kinesis Data Streams für Anwendungsfälle, die folgenden Szenarien ähneln:

• Das Routing zusammengehöriger Datensätze zum selben Datensatzprozessor (etwa beim Streamen von MapReduce). Das Zählen und Aggregieren ist zum Beispiel einfacher, wenn alle Datensätze für einen bestimmten Schlüssel für denselben Datensatzprozessor geleitet werden.
• Sortieren von Datensätzen.  Wenn Sie zum Beispiel Protokolldaten vom Anwendungshost an den Verarbeitungs-/Archivierungshost transferieren und dabei die Sortierung der Protokollanweisungen beibehalten wollen.
• Die Möglichkeit, dass mehrere Anwendungen gleichzeitig denselben Stream konsumieren.  Wenn Sie zum Beispiel eine Anwendung haben, die ein Echtzeit-Dashboard aktualisiert, und eine andere, die Daten in Amazon Redshift archiviert. Sie möchten, dass beide Anwendungen gleichzeitig und unabhängig Daten aus demselben Stream konsumieren.
• Die Möglichkeit, nach einigen Stunden Datensätze in der gleichen Reihenfolge zu nutzen.  Wenn Sie zum Beispiel eine Fakturierungsanwendung haben sowie eine Audit-Anwendung, die einige Stunden nach der Fakturierungsanwendung ausgeführt wird. Da Kinesis Data Streams die Daten bis zu 365 Tagen speichern, können Sie die Audit-Anwendung bis zu 365 Tagen nach der Fakturierungsanwendung ausführen.

Wir empfehlen Amazon SQS für Anwendungsfälle, die folgenden Szenarien ähneln:

• Nachrichtensemantik (etwa Bestätigung/Ablehnung auf Nachrichtenebene) und Zeitbeschränkung für die Sichtbarkeit.  Wenn Sie zum Beispiel eine Warteschlange mit Arbeitselementen haben und den erfolgreichen Abschluss jedes einzelnen Elements unabhängig verfolgen wollen. Amazon SQS verfolgt die Bestätigung/Ablehnung, sodass die Anwendung keinen ständigen Checkpoint/Cursor aufrechtzuerhalten braucht. Amazon SQS löscht bestätigte Nachrichten und liefert abgelehnte Nachrichten nach einer konfigurierten Zeitbeschränkung für die Sichtbarkeit erneut aus.
• Individuelle Nachrichtenverzögerung.  Zum Beispiel wenn Sie eine Job-Warteschlange haben und einzelne Jobs mit einer Verzögerung eingeplant werden müssen. Bei Amazon SQS können Sie einzelne Nachrichten mit einer Verzögerung von bis zu 15 Minuten konfigurieren.
• Gleichzeitigkeit/Durchsatz beim Lesen dynamisch erhöhen.  Wenn Sie beispielsweise eine Arbeitswarteschlange haben und mehr Leser hinzufügen möchten, bis der Rückstand aufgeholt ist. Bei Kinesis Data Streams können Sie bis zu einer ausreichenden Anzahl von Shards vertikal skalieren (allerdings müssen Sie im Voraus eine ausreichende Anzahl von Shards bereitstellen).
• Die Fähigkeit von Amazon SQS zum transparenten Skalieren nutzen. Zum Beispiel wenn Sie Anfragen puffern und die Last sich je nach den gelegentlichen Lastspitzen oder dem natürlichen Wachstum Ihres Unternehmens ändert. Da jede gepufferte Anfrage unabhängig verarbeitet werden kann, kann Amazon SQS transparent skalieren, um sich der Last anzupassen, ohne dass Sie Anweisungen bereitstellen müssen.