Die Zukunft des Load Balancings liegt in den Daten

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Cloud-native-Anwendungen werden in rasantem Tempo entwickelt. Auch wenn sie die Anwendungsportfolios noch nicht ganz dominieren, nimmt ihre Zahl stetig zu. Das Interesse an Containern ist eng mit Cloud-native-Architekturen auf Basis von Microservices verknüpft, da diese für Kommunikation und Skalierung naturgemäß von der Infrastruktur abhängig sind.

Typischerweise werden Microservices durch horizontales Klonen skaliert. Das heißt: Benötigen wir mehr Instanzen eines bestimmten Dienstes, klonen wir ihn einfach und fügen ihn dem verfügbaren Pool hinzu, aus dem ein Load Balancer eine Instanz zur Bearbeitung der Anfragen auswählt. Kinderleicht. Wenn diese Microservices eng an funktionalen Elementen ausgerichtet sind, funktioniert dieses Modell sogar noch besser.

Der betreffende Load Balancer ist häufig eine Komponente des Container-Orchestrators und verwendet standardmäßig den branchenüblichen TCP-basierten Round-Robin-Algorithmus. Das bedeutet: Wenn eine Anfrage eingeht, wählt der Load Balancer die Ressource aus, die als Nächstes an der Reihe ist, um darauf zu antworten.

Diese Methode wird oft mit der Warteschlange in einer Bank oder bei der Kfz-Zulassungsstelle verglichen. Das ist jedoch nicht ganz zutreffend. Bei einem echten Round-Robin-Verfahren werden Sie nicht an die „nächste verfügbare“ Ressource weitergeleitet, sondern an die „nächste Ressource in der Reihenfolge“ – selbst wenn diese gerade ausgelastet ist. Ironischerweise sind die Zuteilungsverfahren bei der Kfz-Zulassungsstelle und Ihrer örtlichen Bank effizienter als ein echter Round-Robin-Algorithmus.

Ich weiß, oder?

Das gilt auch für Anwendungen. Derselbe Dienst kann – selbst auf funktionaler Ebene – geklont werden, weil die Instanzen dieselbe Art von Anfragen verarbeiten. Doch hinsichtlich der Ausführung sind diese Anfragen aufgrund der Daten nicht immer gleich. Richtig: aufgrund der Daten. Die Ausführung derselben funktionalen Anfrage – oder desselben API-Aufrufs – kann je nach den übermittelten oder angeforderten Daten mehr oder weniger Zeit in Anspruch nehmen. Schließlich dauert es weniger lange, einen einzelnen Kundendatensatz abzurufen und zu serialisieren, als zehn oder hundert Kundendatensätze abzurufen und zu serialisieren.

Und genau hier stößt das Round-Robin-Verfahren an seine Grenzen und führt zu Schwankungen, die sich auf die Leistung auswirken können. Das zweite Betriebsaxiom gilt auch weiterhin für Cloud-native- und Microservices-basierte Architekturen: Mit zunehmender Last nimmt die Leistung ab.

Round Robin ist wie ein Honigdachs. Es kümmert sich nicht darum, ob eine Ressource durch Anfragen überlastet wird, deren Antworten umfangreiche Datensätze enthalten. Round Robin sagt einfach: „Du bist als Nächstes dran“ – ob du bereit bist oder nicht. Dies kann bei denjenigen Benutzern zu Leistungsschwankungen führen, deren Anfragen letztlich in der Warteschlange einer zunehmend belasteten Ressource landen.

Wenn Ihnen die Performance wichtig ist – und das sollte sie sein –, ist praktisch jeder andere Standardalgorithmus eine bessere Alternative, etwa „Least Connections“ oder „Fastest Response Time“. Grundsätzlich sollte Ihr Algorithmus die Auslastung und/oder Geschwindigkeit berücksichtigen, anstatt Anfragen einfach blind an Ressourcen weiterzuleiten, die möglicherweise nicht optimal geeignet sind.

Die Zukunft des Load Balancings

Manche mögen denken, dass sich dieses Problem von selbst löst, wenn wir uns im Stack von TCP über HTTP zu HTTP+ nach oben bewegen. Das ist jedoch keineswegs der Fall. Die Verteilungsmethode – der Load-Balancing-Algorithmus – bleibt unabhängig von der zugrunde liegenden Schicht relevant. Round Robin interessiert sich nicht für die Architektur, sondern für die Ressourcen und trifft Entscheidungen auf Grundlage eines verfügbaren Pools. Ob dieser Pool dazu dient, einen einzelnen API-Aufruf oder einen ganzen Monolithen zu skalieren, macht für den Algorithmus keinen Unterschied.

Es wäre also wünschenswert, wenn der Load Balancer intelligent genug wäre, um zu erkennen, wann eine Abfrage zu einer „überdurchschnittlich“ großen Datenmenge führen würde, bevor sie ausgeführt wird. Web Application Firewalls wie F5 WAF können erkennen, wenn ein Ergebnis ungewöhnlich ist – allerdings erst anhand der Antwort, was in erster Linie die Anwendungssicherheit verbessert. Der Load Balancer müsste intelligent genug sein, um eine legitime Antwort mit „besonders großem“ Umfang vorherzusagen.

Wenn der Load Balancer zu einer solchen Einschätzung in der Lage wäre, könnte er dies bei seiner Entscheidungsfindung berücksichtigen und Anfragen gleichmäßiger auf die verfügbaren Ressourcen verteilen. Was wir wirklich wollen, ist, nicht zur Festlegung eines starren Algorithmus gezwungen zu sein, auf dessen Grundlage Entscheidungen getroffen werden. Besser wäre es, wenn der Load Balancer seine Entscheidung anhand geschäftlicher Schwellenwerte und technischer Merkmale wie Antwortzeiten, voraussichtlicher Ausführungsdauer, Umfang der zurückgegebenen Daten und der aktuellen Auslastung der einzelnen Ressourcen treffen könnte.

Letztlich lässt sich diese Art von Intelligenz nur durch bessere Transparenz und maschinelles Lernen realisieren. Wenn der Load Balancer aus Erfahrung lernen kann, welche Abfragen mehr Zeit in Anspruch nehmen als andere, kann er dieses Wissen anschließend nutzen, um Anfragen besser zu verteilen und so eine gleichbleibende, vorhersehbare Antwortzeit zu erreichen.

Load Balancing wird nicht verschwinden. Es ist unsere beste technische Lösung, um alles vom Netzwerk bis hin zu Anwendungen zu skalieren. Doch es muss sich gemeinsam mit der übrigen Infrastruktur weiterentwickeln und dynamischer, autonomer und intelligenter werden.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie