Wie Messaging erfolgreich auf AWS eingesetzt werden kann – Teil 3
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
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
Message Lifecycle
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
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.
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.
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 | ||||
|
|
|
|
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