NETWAYS Blog

ZeroMQ ist eine in C++ geschriebene Library, die verschiedene Messaging-Funktionen anbietet, darunter z.B. Verteilung von Meldungen an mehrere Clients mit Loadbalancing (analog zu Anycast bei IP). Dies kann verwendet werden, um Anwendungen auf mehrere Systeme zu verteilen und so zu skalieren. Dabei wird die Anwendung grundsätzlich in zwei Komponenten getrennt:

• Eine zentral laufende Komponente ist dafür zuständig, eine größere Aufgabe in kleinere Arbeitseinheiten aufzuteilen und diese an Worker-Prozesse zu vermitteln. Am Ende muss diese Komponente die gesammelten Resultate der Workerprozesse zu einem Gesamtergebnis zusammenzufassen.
• Die zweite Komponente sind die Worker-Prozesse, von denen es beliebig viele geben kann. Ihre Aufgabe ist es, Arbeitseinheiten zu berechnen und das Ergebnis an die zentrale Komponente zurückzuliefern.

Der Vorteil dieses Konzepts gegenüber traditionellen Multi-Thread-Anwendungen ist, dass keinerlei Locks notwendig sind, da die einzelnen Worker-Prozesse keinen gemeinsamen Zustand besitzen. Außerdem können Worker-Prozesse auch über Rechnergrenzen hinweg verteilt werden und die Anwendung so theoretisch beliebig skaliert werden.
In der Beispielanwendung (die einen Teil des Mandelbrot-Sets berechnet) werden zwei ZeroMQ-Sockets verwendet: einer zum Verteilen der Aufgaben und ein weiterer zum Einsammeln der Ergebnisse. Die „render“-Anwendung zerteilt dabei ein 12800×12800 Pixel großes Bild in Segmente zu jeweils 320×320 Pixeln, die dann an einen oder mehrere „render-worker“-Prozesse zum Rendern verteilt werden. Im Anschluss werden die Ergebnis-Segmente zusammengefügt und das fertig gerenderte Bild als PNM-Datei ausgegeben.
Die Berechnungen skalieren dabei fast linear mit der Anzahl der verwendeten CPU-Cores:

In der Praxis gibt es jedoch einige Stolperfallen, die vor der Implementation eines solchen Systems bedacht werden müssen:

• Größe der Arbeitseinheiten: sind sie zu klein, gibt es Overhead durch die Vielzahl an Messages (Netzwerkbandbreite, CPU-Zeit); wenn sie zu groß sind, geht evtl. viel Arbeit verloren, wenn eines der Systeme sein Ergebnis aus irgendeinem Grund nicht abliefern kann
• bleibt für eine Arbeitseinheit das Ergebnis aus, muss sie evtl. an ein anderes System erneut verteilt werden
• Das Zusammenfassen der Arbeitseinheiten läuft in einem einzelnen Thread ab und skaliert daher nicht
• Das Format der Messages sollte betriebssystemunabhängig sein; zu beachten ist hier Little Endian vs. Big Endian und Unterschiede zwischen Compilern (z.B. wie structs im Speicher angeordet werden); idealerweise wird hier auf ein Standard-Format wie z.B. JSON zurückgegriffen