Wie Messaging erfolgreich auf Azure eingesetzt werden kann – Teil 2
Die Cloud-Plattform Azure von Microsoft bietet diverse Services, welche dem Entwickler out-of-the-box-Funktionalitäten bietet, mit denen er einfach und komfortabel Messages und Events umsetzen kann – besonders im Kontext von Microservice-Architekturen ein wichtiger Faktor.
Im Folgenden beleuchten wir diese Services im Detail.
Azure Service Bus
Der Azure Service Bus ist ein vollständig verwalteter Nachrichtenbroker. Dieser Service ist dafür konzipiert, Messages und somit Daten zwischen Services auszutauschen. Der Fokus liegt hierbei auf der sicheren Übermittlung der Nachrichten. Nachrichten werden von einem „broker“, beispielsweise eine Queue oder einem Topic, verwaltet, also bereitgehalten, bis ein konsumierender Service in der Lage ist, diese Nachrichten zu verarbeiten. Darüber hinaus bietet der Service Bus noch weitere Features, welche die Umsetzung fortgeschrittener Szenarien für den Nachrichtenaustausch abdeckt.
Namespace
Der Namespace ist ein Container, welcher mehrere Queues und Topics zu einer Einheit zusammenfasst.
Queue
Hierbei handelt es sich um eine First-In-First-Out Queue – wobei Nachrichten typischerweise jeweils nur von einem Consumer verarbeitet werden. Die Nachrichten werden hier solange in der Queue aufbewahrt, bis sie von einem Consumer gepulled, verarbeitet und anschließend gelöscht werden.
Topics
Bei Topics hingegen werden alle Nachrichten an alle Subscriber eines Topics übermittelt. Die Übermittlung der Nachricht findet dabei durch einen Push von Seiten des Service Bus statt, wobei festgelegt werden kann, wie viele Nachrichten geschickt werden. Topics eignen sich daher für Szenarien, in denen eine Nachricht Informationen enthält, welche für mehrere Consumer von Bedeutung ist.
Features
- Unterstützt „publish-subscribe“ Szenarien mit Hilfe von Topics
- Unterstützt Point-to-Point Szenarien mit Hilfe von Queues
- Lösungen für einige komplexere Messaging Herausforderungen werden bereitgestellt
- Nachrichtensitzungen nach dem first in, first out (FIFO) Prinzip
- automatische Weiterleitung
- Warteschlange für unzustellbare Nachrichten (Dead-Letter Queue, DLQ)
- zeitgesteuerte Zustellung
- Nachrichtenverzögerung
- clientseitige Batchverarbeitung
- Transaktionen
- automatisches Löschen
- Duplikatserkennung
Tools
Neben dem üblichen Ressourcen Management über das Azure Portal und die Azure CLI kann der Service Bus auch bequem mit dem Tool Service Bus Explorer verwaltet werden. Hierbei handelt es sich um ein Community Projekt, welches aber von Microsoft in ihre Dokumentation aufgenommen wurde.
Tier/Pricing
Beim Service Bus gibt es drei verschiedene Tiers, die sich wie folgende Matrix zeigt, unterscheiden:
Basic | Standard | Premium | |
Kostenmodell | Pay-per-use | Grundgebühr + Pay-per-use | Pre-Paid-Consumption Flatrate |
Erweiterte Features (Deduplikation… etc.) | – | ✔ | ✔ |
Basic | Standard | Premium | |
Max Message Size | 256 KB | 256 KB | 1 MB |
Resource isolation | – | – | ✔ |
Geo-Disaster Recovery (Geo-DR) | – | – | ✔ |
Einsatzszenario | Keine erweiterten Message Features benötigt |
|
|
Weitere Informationen bezüglich Features und Pricing befinden sich hier:
https://azure.microsoft.com/en-us/pricing/details/service-bus/
Azure Event Grid
Das Event Grid ist ein Managed Service, welcher mithilfe des publish-subscribe Mechanismus Events von Event Publishern empfangen und an Event Handler weiterleiten kann.
Architecture
Event Publisher
Wie im Bild bereits dargestellt, gibt es Event Publisher, wobei es sich hier vorrangig um Services aus dem Azure Umfeld handelt, welche bereits nativ vom Event Grid unterstützt werden. Zudem können aber auch Custom Topics erstellt werden, wodurch beispielsweise eine selbst geschriebene API als Event Publisher fungieren und fachspezifische Events versenden kann.
Event Handler
Auf der anderen Seite gibt es eine Reihe von Services in Azure, welche als sogenannter Event Handler bereits nativ Events vom EventGrid als Trigger verarbeiten können. Auch hier gibt es die Möglichkeit, über WebHooks jeden beliebigen Service, welcher einen http-Endpunkt bereitstellt, als EventHandler festzulegen.
Features
- Erstellung eines Wiederholungszeitplans und Dauer
- Events können als Batch bis zu einer Größe von 1 MB zusammengefasst werden, um den Durchsatz zu erhöhen
- Auf unzustellbare Events kann reagiert werden
Tools
Für das EventGrid gibt es neben dem Azure Portal und der Azure CLI weiterhin die Möglichkeit, mithilfe des EventGridViewer die Events in Echtzeit protokollieren zu können. Zudem gibt es noch eine Extension für VS Code, mit der Event Grids gemanaged und auch Mock Events generiert werden können.
Tier/Pricing
Für das EventGrid gibt es aktuell nur ein einziges Tier. Dieses Pricing Tier ist dabei auf Pay-Per-Use ausgelegt.
Azure Event Hub
Bei dem Event Hub handelt es sich um eine Big Data-Streamingplattform, welche mit dem Hauptfokus auf die Übermittlung einer großen Anzahl von Serien-Event entwickelt wurde. Die Architektur des Service und auch das Preismodell sind dabei so festgelegt, dass die Verarbeitung großer Datenmengen möglichst reibungslos und effizient erfolgen kann.
Namespace
Der Namespace ist ein übergeordneter Container, welcher mehrere EventHubs zusammenfasst. Der Namespace bestimmt das Tier der EventHubs.
EventHub
EventHubs sind Instanzen, welche die Endpunkte für das Senden und Empfangen von Events bereitstellen. Für jeden EventHub kann ein individueller Wert für den Durchsatz festgelegt werden.
Consumer Group
ConsumerGroups bieten jeweils eine eigene Sicht mit eigenem PartitionOffset auf einen EventHub. Das bedeutet, man benötigt zwei ConsumerGroups, wenn es zwei Applikationen gibt, welche unabhängig voneinander alle Events erhalten sollen.
Partition
Damit ein EventHub horizontal skalieren kann, verteilt dieser alle empfangenen Events auf mehrere Partitionen. Die Anzahl der Partitionen bestimmt auch, wie viele Consumer die Events unabhängig voneinander parallel verarbeiten können.
Features
- Kann mehrere Millionen Events pro Sekunde verarbeiten
- Kann als Alternative zu Apache Kafka Cluster verwendet werden
- Daten können in Echtzeit übermittelt werden
- Daten können automatisch in einem Blob Storage / Data Lake abgelegt werden
- Events können auf mehrere Partitionen verteilt werden, wodurch eine verteilte Bearbeitung der Events ermöglich wird
- Daten können werden für eine wählbare Zeitspanne gespeichert und im Fehlerfall erneut geladen werden
Tools
Neben dem Tool Azure Portal und der Azure CLI gibt es die Visual Studio Code Extension EventHubExplorer, womit zum einen direkt in der IDE Testnachrichten an einen EventHub gesendet werden können und zum anderen eingehende Nachrichten an den EventHub überwacht werden können.
Tier/Pricing
Basic | Standard | Dedicated | |
Kostenmodell | Pay per Throughput Unit | Pay Per Throughput Unit | Pay per Capacity Unit (CU) |
Automatische Speicherung auf Blob Storage | – | ✔ | ✔ |
Unterstützung für Apache Kafka | – | ✔ | ✔ |
Einsatzszenario |
|
|
https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-faq#dedicated-clusters |
Weitere Informationen zu Tiers und Preisen gibt es hier:
https://azure.microsoft.com/en-us/pricing/details/event-hubs/
Die drei Azure Services im Vergleich
Event Grid | Event Hub | Service Bus | |
Datenart | |||
Handling Telemetry Data, Logging (IoT) | – | ✔ | – |
Übertragung von Nachrichten | – | – | ✔ |
Discrete Events | ✔ | – | – |
Series Events | – | ✔ | – |
Business Logik relevante Daten | ℹ | – | ✔ |
Use Cases | |||
Kommunikation zwischen Services eines Workflows | ℹ | – | ✔ |
Ereignisorientierte Architekturen (Trigger) | ✔ | – | – |
Publish-Subscribe Szenario | ✔ | – | ✔ |
Point-to-Point Szenario | – | – | ✔ |
Echtzeit Datenanalyse | – | ✔ | – |
Features | |||
Retention | ℹ (Retry Logic) |
✔ | ✔ |
Build-In Support for Azure Service Events | ✔ | – | – |
Kostenmodell | |||
Pay-Per-Use | ✔ | – | ✔ |
Prepaid Consumption | – | ✔ | ✔ (Premium) |
Einsatzgebiete |
|||
|
|
|
|
Fazit und Empfehlung – wie die Azure Messaging Dienste optimal genutzt werden können | |||
Das Event Grid ist der Service in Azure, wenn es darum geht, diskrete Events in Azure zwischen Managed Services oder auch Custom Services (APIs, etc.) zu übermitteln. Bei diesen Events handelt es sich um diskrete Events, welche beispielsweise auf eine Änderung des Status oder die Erstellung einer neuen Datei auf dem Blob Storage hinweisen wollen. Diskrete Events enthalten also keine Daten, sondern fungieren lediglich als Trigger für andere Services, um auf eine Änderung zu reagieren. Azure stellt für viele seiner gemanaged Komponenten bereits entsprechende Events zur Verfügung, welche im Event Grid platziert werden können. So kann z.B. ein Storage Account mit dem Event Grid gekoppelt werden, um andere Services (z.B. APIs, Azure Functions, …) – beispielsweise über die Erstellung/Änderung eines Blobs – zu informieren. Wird in diesem Szenario eine Function App mit einem Event Grid Trigger als Subscriber genutzt, kann dieses Beispiel komplett „serverless“ umgesetzt werden. | Der EventHub klingt zwar zunächst ähnlich wie das Event Grid – doch sind ihre Einsatzzwecke sehr unterschiedlich. Die Aufgabe des EventHub ist es, eine Lösung für Szenarien zu bieten, in denen von sehr vielen Datenquellen in einer hohen Frequenz Daten an ein (oder mehrere) Backend verschickt werden. Hierbei gibt es die Möglichkeit, Daten in Echtzeit zu verarbeiten, wodurch beispielsweise Telemetrie- oder IoT-Daten genutzt werden können, um durch die Analyse auf Anomalien zeitnah reagieren zu können. Durch die Architektur mit Verwendung von Partitionen und paralleler Vearbeitung der Daten, kombiniert mit einem Preismodell, welches sich an garantierten und reserviertem Durchsatz orientiert, eignet sich dieser Service für die Verarbeitung von hohen Datenmengen von diversen Datenquellen. |
Zunächst unterscheidet sich der Service Bus zu den anderen Services dadurch, dass dieser für die Übermittlung von Messages konzipiert ist. Daher eignet er sich besonders gut für Szenarien, in denen es einen Workflow gibt und verschiedene Services miteinander kommunizieren, beziehungsweise Daten austauschen müssen. Die Daten und Informationen sind hierbei essentiell für die korrekte Abarbeitung des Workflows und dürfen deshalb auf keinen Fall verloren gehen. Mit dieser großen Bedeutung der Daten gibt es auch einige komplexere Herausforderungen für die Übermittlung der Daten – wie beispielsweise Duplikatserkennung und -filterung, Erkennung unzustellbarer Nachrichten, automatische Weiterleitung, etc. Diese Anforderungen sind bereits als Features in den Service Bus integriert. |
Fazit
Je nach Anwendungsfall bietet die Azure Plattform bereits ein großes Produkporttfolio, um die Problemstellungen von Messaging und Events abzudecken. Eine detaillierte Evaluierung kann dem Entwickler hier eine Menge Arbeit abnehmen. Die obenstehende Übersicht kann dabei sinnvoll unterstützen.
Quellen
https://docs.microsoft.com/en-us/azure/messaging-services/
https://docs.microsoft.com/en-us/azure/event-grid/
https://docs.microsoft.com/en-us/azure/event-hubs/
https://docs.microsoft.com/en-us/azure/service-bus-messaging/