Engineering
In verteilten IT-Systemen besteht häufig die Anforderung Nachrichten zwischen Anwendungen entkoppelt asynchron versenden zu können. Neben der Punkt-zu-Punkt-Kommunikation ist häufig auch das broad- und multicasten von Nachrichten erwünscht. Eine solche anwendungsneutrale Kommunikationsinfrastruktur wird als Message Oriented Middleware (MOM) bezeichnet. Komponenten sind neben den Nachrichten häufig Warteschlangen (Queues), Publish/Subscribe, sowie Sender und Empfänger (Messaging Clients) der Nachrichten, die diese auch nach offline Zeiten abrufen können. Implementierungen einer MOM sind zum Beispiel RabbitMQ oder auch Apache Kafka. Deren Grundlagen, sowie ihre Gemeinsamkeiten und Unterschiede stellten Zweitag-Mitarbeiter Heiko Zeus und meine Wenigkeit, Nicolas Dillmann, beim diesmaligen User Group Treffen in Vorträgen vor.
RabbitMQ
Heiko machte den Anfang und gab eine Einführung in RabbitMQ. RabbitMQ ist eine in Erlang programmierte Implementierung des offenen Advanced Message Queuing Protocol (AMQP). Das Konzept von AMQP sieht die Komponenten Exchanges, Queues, Bindings sowie Publisher und Subscriber vor. Publisher veröffentlichen Nachrichten an Exchanges. Exchanges nehmen diese Nachrichten und verteilen diese an 0 bis n Queues anhand von bestimmten Regeln (Bindings). Die in den Queues gespeicherten Nachrichten können dann von Subscribern (oder auch Consumer genannt) abgerufen werden.
Anhand des Anwendungsbeispiels eines Fußball-Tickers präsentierte Heiko diese dadurch ermöglichte asynchrone Kommunikation zwischen Anwendungen. Er implementierte mit dem Ruby-Gem Bunny zwei Publisher, einen Reporter und einen Ticker mit Spielergebnissen sowie zwei Subscriber (Ergebnisdienst und Push Notifications).
Durch die Beispiele wurde deutlich, wie schnell - entsprechende Gems vorausgesetzt - sich RabbitMQ in ein verteiltes Szenario einbinden lässt. Insgesamt überzeugt RabbitMQ mit einer ausgereiften Implementierung, übersichtlichen Konzepten und vielfältigen Anwendungsszenarien. In verteilten Architekturen dürfte RabbitMQ zur ersten Wahl gehören, wenn es um die Einführung einer MOM geht.
Apache Kafka
Im zweiten Vortrag stellte ich Apache Kafka vor. Apache Kafka ist eine von LinkedIn in Scala entwickelte verteilte Open-Source Messaging-Lösung, welche sich im Gegensatz zu RabbitMQ auf hohe Datendurchsätze und geringe Latenzzeiten zur Bewältigung von Echtzeitdatenströmen spezialisiert hat. Erreicht wird dies durch den Verzicht auf zu viel Logik auf Server- (Broker-) Seite, sowie einigen speziellen Implementierungsdetails. So verzichtet Apache Kafka z.B. völlig auf die Nutzung des RAMs und schreibt Daten sofort auf das Filesystem eines Servers. Da alle Daten sequentiell geschrieben werden, erreicht man eine Schreib-Lese-Performance, die vergleichbar mit dem des RAMs ist. Zusätzlich beschleunigt Kafka die Übertragung von Daten durch die Verwendung des zero-copy Verfahrens. Logik, wie z.B. die Verwaltung der zuletzt gelesenen Nachrichten-ID eines Consumers (analog Subscriber bei RabbitMQ) oder auch die Entscheidung, auf welche Partition neu ankommenden Daten geschrieben werden, wird komplett auf den Client (Producer oder Consumer) verlagert. Neben den Konzepten des Producers und Consumers gibt es noch die Konzepte des Topics, Partitions und Replication. Ein Topic beschreibt eine Kategorie von Nachrichten (z.B. User-Clicks). Fehlertoleranz wird bei Kafka durch Replikation der Daten eines Topics, Skalierung durch Partitionierung der Topics auf mehrere Server erzielt.
Apache Kafka hat unterschiedliche Anwendungsszenarien. LinkedIn nutzt Kafka als einheitliche Daten-Pipeline die alle Event-Ströme (Nutzerinteraktionen, Metriken etc. (aufnimmt und an die entsprechenden Datenauswertungssysteme wie z.B. Hadoop, Data Warehouse, Recommender Systeme etc.) ausliefert. Unternehmen wie Twitter nutzen Kafka dagegen um Echtzeitauswertungen durchführen zu können. Eine Übersicht der Firmen, die Kafka nutzen ist auf der Kafka Homepage zu finden.
Wer sich das Setup und die Administration eines Kafka Clusters sparen möchte, kann stattdessen auch auf den Amazon Web Service Kinesis zurückgreifen. Kinesis bietet ähnliche Garantien und Funktionalitäten wie Apache Kafka.
Im Anschluss der beiden Vorträge wurde noch ein wenig diskutiert und das nächste Treffen geplant. Das nächste Monster on Rails findet am 30. Oktober um 19:00 Uhr im Zweitag Büro, Am Alten Fischmarkt 12, statt. Geplant ist das Thema „Go Programming Language“, sowie ein weiterer Vortrag. Wir danken allen Teilnehmern und freuen uns auf zahlreiche Anmeldungen für das nächste Treffen.
Über Monster on Rails
Die „Monster on Rails“ User Group Münster beschäftigt sich mit Themen rund um Ruby on Rails, diskutiert aber auch über Technologien, die das Ruby-Ökosystem betreffen, wie z. B. Javascript, node.js, Go, Docker und NoSQL. In der Regel treffen wir uns immer am letzten Donnerstag im Monat. Nach einigen Vorträgen zum jeweiligen Thema beenden wir den Abend in entspannter Atmosphäre bei einem Bier. Wir freuen uns über jedes neue Gesicht!
