Microservices, Load Balancing

Die Prüfung der Skalierbarkeit von Microservices war ein weiteres sehr wichtiges Thema in unserem Microservices Projekt. Im Rahmen unser dazugehörigen Blog Serie möchte ich hier das Thema Load Balancing im Kontext der Microservice Architektur näher beleuchten. Häufig werden im Bereich der Bibliothekssysteme zentrale Dienste, wie zum Beispiel ein zentrales Dokumentenmanagement wie Fedora oder eine zentrale Suche mit Solr oder Elasticsearch benötigt. In unserem Projekt wollten wir herausfinden, wie und mit welchem Aufwand Services dynamisch skaliert werden können. Dies bedeutet, dass in Situationen in welchen die Client Anwendungen durch die Nutzer der Bibliothek stark verwendet werden, die Services dynamisch auf zusätzliche Server installiert und anschließend verwendet werden. Dynamisch bedeutet an dieser Stelle automatisiert und damit ohne Administrations-, Konfigurations- bzw. Entwicklungsaufwand.

Wie in unserem ersten Beitrag beschrieben, bietet die Microservices Architektur unter anderem den Vorteil der einfacheren und genaueren Skalierung einzelner Microservices. Wird nun eine Softwarekomponente bzw. ein Service auf mehrere Server automatisiert installiert, müssen diese auch durch die Anwendungen genutzt werden können. Als Teil der „Platform Services“ bietet der Netflix Open Source Stack (Netflix OSS) auch hier eine sehr gute Lösung. Bevor ich die konkrete Lösung vorstelle, möchte ich noch etwas zur Theorie des Load Balancing sagen. Grundsätzlich gibt es zwei wesentliche Varianten um dieses aufzubauen.

Zentrales Load Balancing.

Dabei wird ein zentraler Load Balancer zwischen den Client Anwendungen und den Services aufgebaut. Alle Anfragen der Clients werden über den Load Balancer geroutet und dieser verteilt die Anfragen nach einem bestimmten Verfahren auf die einzelnen Service Instanzen. Ein Nachteil dieser Lösung ist, dass der Load Balancer ein Single Point of Failure ist. Dies bedeutet, dass wenn diese Komponente ausfällt bzw. stark überlastet ist, sie keine Anfragen mehr von den Anwendungen zu den Services weiterleitet.

Zentrales Load Balancing

Dezentrales Load Balancing

Hierbei hält die Client Anwendung alle Informationen, welche Service Instanzen verfügbar sind, bei sich lokal vor. Diese Informationen werden regelmäßig aktualisiert, sodass die aktuelle Situation der verfügbaren Services dem Client jederzeit bekannt ist. Die Client Anwendung entscheidet mit Hilfe eines eingebauten Load Balancing Mechanismus selbst, welche Service Instanz für eine Anfrage verwendet wird. Damit ist keine zentrale Load Balancer Instanz mehr notwendig und es gibt keinen Single Point of Failure. Auch bei dieser Lösung gibt es wiederum Nachteile, dass zum Beispiel die lokale Information, welche Instanzen der Services verfügbar sind, veraltet sein kann.

Dezentrales Load Balancing

Die einzelnen Load Balancing Verfahren, nach welchem Algorithmus eine von mehreren verfügbaren Service Instanzen ausgewählt wird, möchte ich hier nicht aufführen, da es in diesem Beitrag um die Integration im Bereich der Microservices Architektur geht und nicht um das Load Balancing als solches. Der Netflix OSS bietet mit der Bibliothek Ribbon eine Möglichkeit des dezentralen, client-seitigem Load Balancing. Die Information, welche Service Instanzen auf welchem Server verfügbar sind, basieren auf den Informationen aus der Service Registry Eureka. Durch die Integration von Eureka ist das Load Balancing dynamisch und wird jederzeit an die verfügbaren Instanzen angepasst. Es ist auch möglich, Ribbon ohne Eureka einzusetzen, was hier aber nicht näher erläutert werden soll, da es für den produktiven Einsatz nicht empfohlen werden kann.

Unsere Erfahrungen

Die Integration von Ribbon in eine Client Anwendung ist einmal mit der Spring Cloud oder aber durch die Einbindung der nativen Netflix Bibliothek möglich. Bei beiden Varianten gibt es jeweils die Möglichkeit mittels direkter Verwendung eines Ribbon Clients das Load Balancing zu integrieren oder die Methode REST Templates zu definieren und zu verwenden. Beide Varianten unterscheiden sich vom Aufwand nicht. Elegant bei der Template Variante ist aus meiner Sicht die Trennung der Definition der zur Verfügung stehenden Funktionalität und deren Verwendung. So können zentral alle zur Verfügung stehenden Templates definiert und diese anschließend an den unterschiedlichsten Stellen eingesetzt werden. Dies vereinfacht die Wartung der bestehenden Möglichkeiten sehr stark. Allerdings konnten wir beim Einsatz des REST Templates für einen HTTP POST Request mit Multipart Upload nicht erfolgreich umsetzen. Beim Absetzen des HTTP POST Request wurde jeweils folgender Fehler gemeldet:

the request was rejected because no multipart boundary was found

Bisher haben wir noch keine Antwort zu unsere Anfrage nach einer Lösung aus der ribbon usergroup erhalten. Zusätzlich zur Integration im Quellcode muss das Load Balancing noch konfiguriert werden. Hier kann zum Beispiel auch zwischen den möglichen Verteilungsverfahren gewählt werden. Ribbon unterstützt zum Beispiel folgende:

• RoundRobinRule
• AvailabilityFilteringRule
• WeightedResponseTimeRule

Alle Details zur Konfiguration von Ribbon können im Wiki des Projektes nachgelesen werden. Zusammenfassend können wir sagen, dass die Integration von Ribbon in eine Anwendung ohne großen Aufwand umzusetzen ist und sehr zuverlässig funktioniert. Bis auf die Ausnahme des HTTP POST Multipart Request sind wir auf keine weiteren Schwierigkeiten gestoßen.

Einsatz des Load Balancing

Unsere Client Anwendungen im Pilotprojekt bietet die Funktion eines Upload von XML Dateien. Diese lädt die Dateien nach der Auswahl im Browser via einer REST Schnittstelle in ein Dokumentenmanagementsystem (Microservice). In die Client Anwendungen haben wir das Load Balancing mit Hilfe der nativen Netflix Bibliothek integriert. In einem Test eines Ausfalls von einem der Dokumentenmanagement Services während des Uploads von 1000 XML Dateien konnten wir zeigen, dass der Upload nicht beeinträchtigt wird. Der Anwender bemerkt nicht, dass zu Beginn des Uploads noch zwei und während des Uploads nur noch eine Service Instanz des Dokumentenmanagement Services die Daten speichert. Ohne den Einsatz von Eureka und Ribbon wäre der Upload bei Ausfall des Dokumentenmanagement Services abgebrochen.

Fazit:

Auch für das Thema Load Balancing kann ich den Einsatz für zentrale Services in Kombination mit einer Service Registry nur stark empfehlen. Der Aufwand der Integration in eine Java Anwendung ist meines Erachtens eher gering und lohnt sich. Nach Abschluss der Integration können die Microservices einfach skaliert und die Client Anwendung kann so jederzeit stärker verwendet werden und reagiert robuster auf Ausfälle.