Wie Messaging erfolgreich auf Azure eingesetzt werden kann – Teil 2

26.10.2020

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.

Service Bus Architecture
Service Bus Architecture, Quelle: Eigene Darstellung draw.io

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
  • „Normale“ Anzahl an Nachrichten
  • Erweiterte Message Features wie Duplikatserkennung,etc nötig
  • Für sehr viele Nachrichten >3 Mrd. pro Monat
  • Benötigt isolierte Umgebung
  • Erweiterte 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 Grid Architecture
Event Grid Architecture, Quelle: https://docs.microsoft.com/de-de/azure/event-grid/overview

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.

Event Hub Architecture
Event Hub Architecture, Quelle: https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-about

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
  • Development/Test
  • Geringe WorkLoads
  • keine speziellen Anforderungen
  • Integration mit Services, welche auf Kafka basieren
  • Automatische Speicherung auf dem BlobStorage
  • Bei einer hohen Auslastung

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
 
  • Übermittlung von Events
  • Broadcast-Szenarien
  • Events von Azure Managed Services vermitteln (Serverless)
  • Serverless Kafka Alternative
  • Kontinuierlicher Strom an Daten, (Telemetriedaten, Logs, IoT, etc.)
  • Echtzeitdatenanalyse mit zum Beispiel StreamAnalytics etc.
  • Sehr viele Datenquellen
  • Übermittlung von Nachrichten
  • Kommunikation zwischen Services in einem Workflow
  • Besondere Anforderungen an die Übermittlung der Daten zwischen Services
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.

Zu Teil 1 der Blogserie

Zu Teil 3 der Blogserie

 

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/

Zurück zur Übersicht

Kommentar verfassen

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

*Pflichtfelder

*