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 betreffende Load Balancer ist häufig eine Komponente des Container-Orchestrators und verwendet standardmäßig den branchenübliche Round-Robin-TCP-Algorithmus. Das heißt, eine Anfrage geht ein und der Load Balancer wählt die nächste Ressource in der Reihe zur Antwort aus.
Diese Methode wird oft mit der Warteschlange bei einer Bank oder der Kfz-Zulassungsstelle verglichen. Das ist jedoch nicht ganz richtig. In einem echten Round-Robin-Szenario werden Sie nicht zur „nächsten verfügbaren“ Ressource weitergeleitet. Sie werden zur nächsten Ressource weitergeleitet, auch wenn diese beschäftigt ist. Ironischerweise sind die Verteilungsmethoden bei der DMV und Ihrer örtlichen 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 ist wie Honigdachs. Dabei spielt es keine Rolle, ob eine Ressource durch Anfragen mit signifikanten Datensätzen als Antworten überlastet wird. Beim Round Robin heißt es „Du bist der Nächste“, egal, ob du bereit bist oder nicht. Dies kann zu einer ungleichmäßigen Leistung für diejenigen Benutzer führen, deren Anfragen in einer Warteschlange auf einer zunehmend belasteten Ressource landen.
Wenn Ihnen die Leistung wichtig ist – und das sollte sie sein –, dann ist praktisch jeder der anderen Standardalgorithmen, beispielsweise „wenigste Verbindungen“ oder „schnellste Reaktionszeit“, eine bessere Alternative. Grundsätzlich möchten Sie, dass Ihr Algorithmus die Auslastung und/oder Geschwindigkeit berücksichtigt, anstatt Anfragen einfach blind an Ressourcen weiterzuleiten, die möglicherweise nicht die optimale Wahl darstellen.
Die Zukunft des Lastenausgleichs
Manche glauben vielleicht, dass sich dieses Problem von selbst löst, wenn wir im Stapel von TCP über HTTP zu HTTP+ aufsteigen. Das ist überhaupt nicht der Fall. Die Verteilungsmethode – der Lastausgleichsalgorithmus – ist weiterhin relevant, unabhängig von der Ebene, auf der sie basiert. Beim Round Robin ist die Architektur nicht wichtig, es kümmert sich um die Ressourcen und trifft Entscheidungen auf der Grundlage eines verfügbaren Pools. Ob dieser Pool zum Skalieren eines einzelnen API-Aufrufs oder eines ganzen Monolithen gedacht ist, 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.