Wie Messaging erfolgreich auf AWS eingesetzt werden kann – Teil 3

13.11.2020

Neben Azure als Cloud Plattform, bietet auch der Cloud Anbieter AWS diverse Services, welche dem Entwickler out-of-the-box Funktionalitäten bieten, mit denen er einfach und komfortabel Messages und Events umsetzen kann. Dabei kann jeder Dienst – je nach Anwendungsfall – nützlich sein.

Die AWS Messaging Services im Überblick

Wir haben uns die AWS Messaging Services im Hinblick auf Architecture, Features und Funktionen, Tools sowie Tiers/Pricing genauer angeschaut:

 

Amazon Simple Notification Service
Amazon Simple Queue Service
Amazon Kinesis
Amazon MQ
AWS Services im Vergleich

Amazon Simple Notification Service

Amazon SNS ist ein vollständig verwaltender Nachrichtendienst, um Messages zwischen Systemen, Anwendungen und Personen auszutauschen. Das Messaging wird ermöglicht durch das „Publish/Subscribe“ Muster, bei dem die Nachrichten von Publishern an Subscriber (auch bekannt als Producer/Consumer) zugestellt werden. Die Kommunikation läuft asynchron, bei dem die Publisher Nachrichten an ein SNS Topic senden, welches einen logischen Zugangspunkt darstellt und als Kommunikationskanal dient. Subscriber können das SNS Topic abonnieren und dadurch bereits veröffentlichte Nachrichten über ein unterstütztes Protokoll (HTTP/S, SQS, SMS etc.) empfangen.

Architecture

SNS Architekur
Abbildung 1: SNS Architektur, Quelle: Eigene Darstellung

Features und Funktionen

  • Warteschlange für unzustellbare Nachrichten (Dead Letter Queues)
  • Serverseitige Verschlüsselung der Nachrichten
  • Zonenübergreifender Nachrichtenspeicher –> hoher Nachrichten Durchsatz
  • Nachrichten nach Interesse filtern (Message Filterung)
  • Übertragungsrichtlinien zur erneuten Nachrichtenübermittlung bei serverseitigen Problemen

Der Nachteil: Amazon SNS ist bislang nicht kompatibel mit FIFO Queues.

Tools

Verwalten und konfigurieren lässt sich Amazon SNS über die Amazon SNS Konsole. Sie stellt eine Benutzeroberfläche für das Erstellen von Topics und Subscriptions, aber auch für das Senden und Empfangen von Nachrichten bereit. Weitere Konfigurationsmöglichkeiten werden durch die AWS CLI geboten. Darüber hinaus lässt sich Amazon SNS über das AWS SDK verwalten.

Tier/Pricing

Pay per Use: Gezahlt wird basierend auf der Anzahl der veröffentlichten bzw. übermittelten Benachrichtigungen und etwaiger weiterer API-Aufrufe für die Verwaltung von Themen und Abonnements. Dabei hängen die Kosten für die Übermittlung vom jeweiligen Endpunkttyp ab.

Standard
Kostenmodell Pay per use
Max Message Size 256 KB
Veröffentlichungen* 0,50 USD pro Mio. Amazon SNS-Anfragen
Preise Endpunkttypen
Mobile Push Benachrichtigungen 0,50 USD pro Mio.
SMS Bislang keine genauen Informationen vorhanden (Stand November 2020)
HTTP/S** 0,60 USD pro Mio.
Email/Email-JSON 2,00 USD pro 100.000
SQS Keine Gebühr für Übermittlungen an SQS-Warteschlangen. Es gelten normale SQS Preise
Lambda-Funktionen
Keine Gebühr für Übermittlungen an Lambda-Funktionen. Es gelten normale Lambda Preise
Preise Datenübertragung
ab 10TB ausgehende Daten pro Monat
0,09 USD pro GB

*Im kostenlosen Kontingent sind die ersten 1 Mio. Anfragen kostenlos. Preise gelten für jede weitere Mio.
**Im kostenlosen Kontingent sind die ersten 100.000 Anfragen kostenlos. Preise gelten für jede weitere Anfrage.

Amazon Simple Queue Service

Amazon SQS ist ein einfacher Message Queue Service zur Verarbeitung der eingehenden Nachrichten in Form eines temporären Pufferspeichers, wodurch die einzelnen Systeme unabhängig voneinander arbeiten können. Das heißt, wenn eine Komponente Daten sehr schnell produziert, eine andere Komponente die Daten aber nicht mit derselben Geschwindigkeit verarbeiten kann, sichert die Queue die Daten, sodass der Consumer sie jederzeit lesen und verarbeiten kann. Unterstützt werden zwei Arten von Queues:

  • Zum einen die Standard Queue, die genutzt werden sollte, wenn der Durchsatz an Nachrichten zwischen zwei Anwendungen sehr hoch ist – wobei keine Garantie besteht, dass sich die Daten nicht doppeln können oder in der richtigen Reihenfolge geliefert werden.
  • Und zum anderen gibt es die FIFO (First In – First Out) Queue, bei der die Reihenfolge, in der die Nachrichten gesendet und empfangen werden, streng eingehalten wird. Obendrein entstehen keine Duplikate, da die Nachrichten nur einmal überliefert werden und solange in der Queue bleiben, bis der Consumer die Nachricht verarbeitet und löscht. Der Durchsatz an Daten ist dabei limitiert auf 3.000 Transaktionen pro Sekunde.

Architecture

Architektur Amazon SQS
Abbildung 2: Architektur Amazon SQS, Quelle: Eigene Darstellung

Message Lifecycle

Message Lifecycle Amazon SQS
Abbildung 3: Message Lifecycle Amazon SQS, Quelle: Eigene Darstellung

Features und Funktionen

  • Zugriffskontrolle
  • Serverseitige Verschlüsselung
  • Verhinderung, dass Nachrichten wiederholt verarbeitet werden (SQS Visibility Timeout)
  • Warteschlange für unzustellbare Nachrichten (Dead Letter Queues)

Tools

  • AWS CLI
  • AWS SDK

Tier/Pricing

Pay per Use: Dabei werden die Kosten aus den Kosten pro Anforderung plus den Datenübertragungskosten für die aus Amazon SQS ausgelesen Daten berechnet.

Standard*
Kostenmodell Pay per Use
Max Message Size 256 KB
Standardwarteschlange** 0,40 USD (0,0000004 USD pro Anfrage)
FIFO Warteschlange** 0,50 USD (0,0000005 USD pro Anfrage)
Kosten für Datentransfer Übertragungen ausgehender Daten ab 10 TB pro Monat kosten 0,09 USD pro GB***

*Die ersten eine Million Anforderungen im Monat sind kostenlos, Datenübertragungskosten fallen dennoch an.
**Preise nach Verbrauch des kostenlosen Kontingents.
*** Grundsätzlich mehr TB an Daten → weniger USD pro GB

Amazon Kinesis

Amazon Kinesis vereinfacht das Erfassen, Verarbeiten und Analysieren von Echtzeit-Streaming-Daten. Dabei sendet der Producer eine Nachricht an Kinesis Stream. Kinesis speichert die Nachricht temporär für 24h ab. In der Zeit können alle Consumer die Nachrichten in der richtigen Reihenfolge lesen und verarbeiten.

Architecture

Architektur Amazon Kinesis
Abbildung 4: Architektur Amazon Kinesis, Quelle: Eigene Darstellung

Features und Funktionen

  • Put-to-Get Verzögerung weniger als eine Sekunde
  • Skalierung von Streams
  • Mehrere Anwendungen können gleichzeitig Daten aus einem Stream auslesen, verarbeiten und archivieren
  • Kinesis Client Library ermöglicht eine fehlerhafte Nutzung von Daten aus Streams
  • Serverseitige Verschlüsselung

Tools

  • AWS SDK
  • AWS CLI
  • AWS Client Library

Tier/Pricing

Auch bei Amazon Kinesis wird nur für die Ressourcen, die auch tatsächlich genutzt werden, bezahlt. Die Kosten ergeben sich aus den Kerndimensionen, der Shard-Stunde* und den PUT-Nutzlasteinheiten.

Standard Höheres Fanout/GB Höheres Fanout/Shard-Stunde für Verbraucher Verlängerte Datenaufbewahrung
Kostenmodell Pay per Use Pay per Use Pay per Use Pay per Use
Shard-Stunde 0,015 USD +0,013 USD +0,015 USD +0,02 USD
PUT-Nutzlasteneinheit** 0,014 USD +0,013 USD +0,015 USD +0,02 USD
maximale Datenausgabe Datenausgabe von 1MB/Sek Datenausgabe von 2MB/Sek Datenausgabe von 2MB/Sek Datenausgabe von 1MB/Sek

*Basiseinheit für den Durchsatz eines Amazon Kinesis Streams
**Nutzlasteinheiten pro Mio.

Amazon MQ

AWS stellt mit Amazon MQ einen verwalteten Nachrichten Broker Service für Apache Active MQ bereit und bietet dabei eine Alternative zum Simple Queue Service. Mithilfe verschiedener Programmiersprachen erlauben es Nachrichten Broker, Softwaresystemen von unterschiedlichen Plattformen untereinander Informationen auszutauschen.

Architecture

Single Instance Broker

Die Nachrichten-Broker Umgebung läuft auf Amazon MQ. Eine Single Broker Instanz besteht aus nur einem Broker, der mit der Anwendung und einem AWS Speicherort kommuniziert.

Single Instance Broker
Abbildung 5: Single Instance Broker, Quelle: Eigene Darstellung

Aktiver/Standby Broker

Für Anwendungsfälle mit einem hohen Verfügbarkeitsanspruch eignet sich der Active/Standby Broker, der aus zwei redundanten Broker Instanzen besteht. Die Broker Instanzen kommunizieren synchron mit der Anwendung und mit einem AWS Speicher. Dabei ist eine Instanz aktiv in Betrieb und die andere auf Standby. Falls die aktive Instanz ausfällt, wird die Standby-Instanz aktiv und gewährleistet so einen Failover von nur wenigen Sekunden.

Aktiver/Standby Broker
Abbildung 6: Aktiver/Standby Broker, Quelle: Eigene Darstellung

Features

  • JavaEE Integration
  • Konfigurationsmöglichkeiten der Broker über XML Konfiguration
  • Zusammengesetzte Ziele (Producer können dieselbe Nachricht an mehrere Ziele senden)
  • Einhaltung der Reihenfolge der Nachrichten
  • Erneute Nachrichtenzustellung und DLD (Dead Letter Queues)

Tools

Broker können mithilfe von:

  • AWS CLI
  • AWS Management Console
  • Amazon MQ-REST-API

erstellt, verwaltet oder gelöscht werden.

Tier/Pricing

Bei Amazon MQ wird nur für die Ressourcen, die auch tatsächlich genutzt werden, gezahlt. Dabei fallen sowohl Kosten für die Nutzung der Broker Instanzen als auch für die Speichernutzung an. Dabei können die Preise je nach Region und Konfiguration abweichen.

Instance Single Broker Aktiver/Standby Broker
Kostenmodell Pay per Use Pay per Use
Stündliche Instance Nutzung* 0,03 USD/Stunde 0,06 USD/Stunde
Broker Speicherpreise** 0,10 USD/Monat 0,30 USD/Monat

*Preise hängen von der verwendeten Broker Instanz ab. Die Werte ergeben sich aus der minimalsten Konfigurationsmöglichkeit [1 CPU Kern, 1GIB Arbeitsspeicher].
**Die ersten von 5GB pro Monat sind kostenlos, abhängig vom Speichertyp (standardmäßig Amazon EFS oder Amazon EBS).

AWS Services im Vergleich

Amazon Simple Notification Service Amazon Simple Queue Service Amazon Kinesis Amazon MQ
Datenart
Übertragung von Nachrichten
Discrete Events
Handling Telemetry Data, Logging (IoT)
Features
Data retention Bis zu 2 Wochen, wenn die Daten nicht vorher schon gelöscht werden Bis zu 1 Woche
FIFO
Realtime data processing
Push Mechanism
Pull Mechanism
Auto scalable
Message size 256 KB 256 KB 1 MB
Kostenmodell
Pay per Use
Use Cases/Einsatzgebiete
  • Fanout (Broadcast-Szenarien)
  • Push email/SMS messages to individuals or groups
  • Mobile push notifications
  • Automatically retry processing errors
  • Buffer between Components
  • Automatically retry processing errors
  • Processing messages in the order they are received (FIFO-Queue)
  • Real time analysis
  • Real time metrics and reports
  • Complex stream processing
  • JavaEE Integration
  • Komplexere messaging Anforderungen

 

So können die AWS Dienste optimal genutzt werden – Fazit und Empfehlung

AWS stellt neben den oben beschriebenen Diensten noch weitere Messaging Services bereit. Dabei kann jeder Dienst – je nach Anwendungsfall – nützlich sein. So sollte Amazon SNS genutzt werden, wenn eine einfache Lösung benötigt wird, um andere Services über etwas Bestimmtes per Event zu informieren. Wenn wirklich Nachrichten zwischen Systemen ausgetauscht werden, die dann auch in der richtigen Reihenfolge verarbeitet werden sollen, in der sie empfangen werden, ist die Nutzung von SQS sinnvoll. Amazon Kinesis Data Stream ist eine gute Lösung, sobald wirklich große Mengen an Nachrichten bestehen, die dann auch in der richtigen Reihenfolge bearbeitet werden. Amazon MQ kann als Alternative zum SQS für komplexere Problemstellungen gesehen werden, die sich problemlos in JavaEE Anwendungen integrieren lässt. Für eine genauere Evaluierung kann die folgende Übersicht sinnvoll unterstützen:

Die Tools im Vergleich
Amazon SNS ist ein flexibler vollständig verwalteter Nachrichtendienst nach dem push Mechanismus, der es ermöglicht individuelle oder auch Broadcast -Nachrichten an eine Vielzahl von Empfängern zu senden. Amazon SNS eignet sich dabei sowohl für die Übermittlung von Events, beispielsweise können Statusänderungen an eine Vielzahl von Empfängern gesendet werden, aber auch für den Datenaustausch zwischen den Services. Das heißt für die Übermittlung von Nachrichten. Amazon SQS ist ein verwaltender Warteschlangendienst für Nachrichten. Dabei liegt der Unterschied zu Amazon SNS darin, dass die Empfänger nur über Abfragen (pull) Nachrichten erhalten können. Obendrein kann eine Nachricht nicht zur gleichen Zeit von mehreren Empfängern empfangen werden. Amazon SQS wird häufig auch in Kombination mit Amazon SNS verwendet. Beispielsweise kann eine Anwendung entwickelt werden, die immer, wenn eine Bestellung von einem Produkt getätigt wurde, diese Information an ein SNS Topic veröffentlicht. Alle SQS Queues, die das Topic abonniert haben, empfangen nun alle dieselbe Information. Jetzt kann sich eine Server Instanz diese Information aus der Queue holen (pull) und sich um die Verarbeitung der Bestellung kümmern. Eine andere Server Instanz holt sich ebenfalls die gleiche Information aus einer zweiten Queue und analysiert z.B. alle empfangenen Bestellungen. Amazon Kinesis ist eine Plattform für Datenstreaming, mit der Anwendungen erstellt werden können, die Streaming Daten in Echtzeit verarbeiten und/oder analysieren. Die Architektur basiert auch auf dem pull Mechanismus. Dabei sendet ein Producer eine Nachricht an Kinesis Stream. Dort können die Nachrichten bis zu zwei Wochen gespeichert und von Consumern in der richtigen Reihenfolge gelesen und verarbeitet werden. So können beispielsweise über einen Click-Stream Information über Seitenaufrufe und Ereignisse, die von Nutzern erzeugt wurden, gesammelt und von mehreren Consumern gelesen und verarbeitet werden. Amazon MQ stellt eine Alternative für komplexere Aufgaben zum Simple Queue Service dar. Dabei unterstützt Amazon MQ sowohl haltbarkeitsoptimierte Broker, um eine hohe Verfügbarkeit und Haltbarkeit von Nachrichten zu gewährleisten und durchsatzoptimierte Broker, um hochvolumige Anwendungen zu unterstützen, die eine geringe Latenz und hohen Durchsatz benötigen.


Teil 1 und 2 der Blogreihe findest du hier:

Teil 1: Wie Messaging erfolgreich in Microservices eingesetzt werden kann
Teil 2: Wie Messaging erfolgreich auf Azure eingesetzt werden kann


Quellen

https://docs.aws.amazon.com/sns/latest/dg/welcome.html
https://aws.amazon.com/de/sqs/
https://aws.amazon.com/de/sns/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc
https://aws.amazon.com/de/kinesis/
https://www.schibsted.pl/blog/choosing-best-aws-messaging-service/
https://medium.com/awesome-cloud/aws-difference-between-sqs-and-sns-61a397bf76c5

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*