Die Zukunft des Lastenausgleichs beruht auf Daten
Cloud-native Applications werden in zügigem Tempo entwickelt. Zwar dominieren sie die App-Portfolios noch nicht, ihre Zahl nimmt jedoch zu. Das Interesse an Containern ist eng mit Cloud-nativen (auf Microservices basierenden) Architekturen verbunden, da diese hinsichtlich Kommunikation und Skalierung von der Infrastruktur abhängig sind.
Normalerweise wird die Skalierung von Microservices durch horizontales Klonen erreicht. Das heißt, wenn wir mehr Instanzen eines bestimmten Dienstes benötigen, klonen wir ihn einfach und fügen ihn dem verfügbaren Pool hinzu, aus dem ein Load Balancer auf Anfragen antwortet. Kinderleicht. Wenn diese Microservices funktionale Elemente genau darstellen, funktioniert dieses Modell sogar noch besser.
Der Load Balancer ist oft Teil des Container-Orchestrators und nutzt standardmäßig den branchenüblichen TCP-basierten Round-Robin-Algorithmus. Das heißt, wenn eine Anfrage eingeht, wählt der Load Balancer die nächste verfügbare Ressource aus, die antwortet.
Man vergleicht diese Methode oft mit der Schlange in der Bank oder beim Straßenverkehrsamt. Doch das trifft nicht ganz zu. Beim echten Round-Robin-Verfahren leiten wir Sie nicht zur "nächstverfügbaren" Ressource weiter. Wir leiten Sie zur "nächsten in der Reihenfolge" Ressource weiter – selbst wenn diese gerade beschäftigt ist. Ironischerweise arbeiten die Verteilungsmechanismen beim Straßenverkehrsamt und Ihrer Bank effizienter als ein echter Round-Robin-Algorithmus.
Ich weiß richtig?
Dies gilt auch für Applications . Derselbe Dienst kann – sogar auf Funktionsebene – geklont werden, da er denselben Satz von Anforderungen bedient. Aber diese Anfragen sind hinsichtlich der Ausführung nicht immer gleich, da Daten vorliegen. Genau: Daten. Die Ausführung derselben Funktionsanforderung – oder desselben API-Aufrufs – kann je nach den übermittelten oder angeforderten Daten mehr oder weniger Zeit in Anspruch nehmen. Schließlich nimmt das Abrufen und Serialisieren eines einzelnen Kundendatensatzes weniger Zeit in Anspruch als das Abrufen und Serialisieren von zehn oder hundert Kundendatensätzen.
Und hier bricht das Round Robin-Verfahren etwas zusammen und führt zu Variabilitäten, die die Leistung beeinträchtigen können. Für Cloud-native und auf Microservices basierende Architekturen gilt weiterhin das Betriebsaxiom Nr. 2: Mit zunehmender Belastung nimmt die Leistung ab .
Round Robin verhält sich wie ein Honigdachs. Er beachtet nicht, ob eine Ressource durch Anfragen mit umfangreichen Datenmengen überlastet wird. Round Robin signalisiert „Du bist als Nächstes dran“, egal ob du bereit bist oder nicht. Dadurch kann die Leistung für Nutzer ungleichmäßig sein, deren Anfragen in einer Warteschlange bei einer zunehmend belasteten Ressource landen.
Wenn Ihnen die Leistung wichtig ist – und das sollte sie –, sind praktisch alle anderen Standardalgorithmen, etwa Least Connections oder schnellste Reaktionszeit, eine bessere Wahl. Sie möchten, dass Ihr Algorithmus die Auslastung und/oder Geschwindigkeit berücksichtigt, statt Anfragen einfach an Serverressourcen zu senden, die möglicherweise nicht ideal sind.
Die Zukunft des Lastenausgleichs
Manche denken vielleicht, dass sich dieses Problem mit dem Aufstieg im Protokollstapel von TCP über HTTP zu HTTP+ von selbst erledigt. Dem ist keinesfalls so. Die Verteilungsmethode – der Lastausgleichsalgorithmus – bleibt unabhängig von der zugrunde liegenden Schicht entscheidend. Round Robin richtet sich nicht nach der Architektur, sondern trifft Entscheidungen basierend auf verfügbaren Ressourcen. Ob dieser Pool eine einzelne API-Anfrage oder einen gesamten Monolithen skaliert, spielt für den Algorithmus keine Rolle.
Daher wäre es schön, wenn der Load Balancer intelligent genug wäre, um vor der Ausführung zu erkennen, wann eine Abfrage „überdurchschnittlich viele“ Daten ergeben würde. Web Application Firewalls wie F5 WAF können erkennen, wenn ein Ergebnis vom Normalen abweicht – dies liegt jedoch an der Reaktion und ermöglicht in erster Linie eine bessere Application . Was wir brauchen, ist, dass der Load Balancer intelligent genug wird, um eine „extragroße“ legitime Antwort vorherzusagen.
Wenn der Load Balancer zu dieser Art von Unterscheidungsvermögen fähig wäre, könnte er dies bei seiner Entscheidungsfindung berücksichtigen und die Anfragen gleichmäßiger auf die verfügbaren Ressourcen verteilen. Was wir wirklich wollen, ist, nicht gezwungen zu werden, einen starren Algorithmus vorzugeben, auf dessen Grundlage Entscheidungen getroffen werden. Es wäre besser, wenn der Load Balancer die Entscheidung auf Grundlage von Geschäftsschwellenwerten und technischen Merkmalen wie Reaktionszeiten, voraussichtlicher Ausführungszeit, Größe der zurückgegebenen Daten und der aktuellen Belastung jeder Ressource treffen könnte.
Letztendlich ist dies die Art von Intelligenz, die nur durch bessere Sichtbarkeit und maschinelles Lernen realisiert werden kann. Wenn der Load Balancer durch Erfahrung lernt, zu erkennen, welche Abfragen mehr Zeit in Anspruch nehmen als andere, kann er dieses Wissen nutzen, um die Anfragen besser zu verteilen und so eine konsistente, vorhersehbare Antwortzeit zu erreichen.
Das Lastenausgleichssystem wird nicht verschwinden. Es ist unsere beste technische Antwort auf die Skalierung aller Aspekte vom Netzwerk bis zu den Applications. Aber es muss sich zusammen mit der übrigen Infrastruktur weiterentwickeln, um dynamischer, autonomer und intelligenter zu werden.