Auf dem richtigen Weg?

Wie ich bereits in einem vorherigen Blogpost beschrieben habe ist recht eindeutig wodurch ein solches System verbessert werden kann: Effizientes Request Routing. Aber ist das wirklich der Fall?

Im Voraus ist so etwas oft schwer zu sagen. Erst nachdem das System angepasst und umfassend getestet wurde steht fest wie groß die Verbesserungen wirklich sind. Frei nach Remzi Arpaci-Dusseaus ausgesprochen nützlichen Vortrag (kann hier gefunden werden), habe ich mich entschlossen noch vor der gänzlichen Implementierung erste Tests durchzuführen um abschätzen zu können mit welcher Größenordnung an Verbesserung ich rechnen kann. Schließlich sollte man seine Energie und Zeit möglichst dort investieren, wo sie am effektivsten genutzt wird.

Für diese Tests habe ich den Serverless Function Simulator faas-sim angepasst und erweitert. Von sich aus unterstützt dieser Simulator lediglich Round-Robin Load Balancer, und auch nur einen einzelnen. Außerdem wird der Netzwerkverkehr von Requests, und die damit einhergehende Verzögerung vom Simulator vollkommen ignoriert. Für die bisherigen Anwendungen war dies passend, aber für meine Experimente ist diese Funktionalität zentral. Mit meinen Änderungen werde nun auch die Clients, der Netzwerkverkehr, die Platzierung von Clients, Load Balancern, und Funktionen, und eine Reihe anderer Faktoren erfasst.

Wie ist es damit nun möglich zu erkennen, oder zumindest eine Idee davon zu bekommen ob sich die besprochenen Änderungen auszahlen? Ich habe dazu insgesamt 12 Experimente durchgeführt. Ich teste mit diesen Experimenten die Extremfälle in allen möglichen Kombinationen. Das bedeutet auf der einen Seite, dass es nur einen einzigen, zentralen, Load Balancer gibt, und auf der anderen Seite das Szenario, dass auf jeder Node im System ein Load Balancer existiert. Vom Typ her kann der Load Balancer entweder klassisch Round Robin oder Least Response Time sein. Es ergeben sich also 4 Szenarien für die Load Balancer:

• Round Robin zentral

• Round Robin auf allen Nodes

• Least Response time zentral

• Least Response time auf allen Nodes

Darüber hinaus existieren 3 Szenarien für das Netzwerk. In jedem Szenario gibt es drei Cluster, die jeweils eine Stadt repräsentieren sollen. Jeder der Cluster hat zwischen 100 und 150 Nodes. Die drei Szenarien sind wie folgt:

• Die 3 Städte sind nahe beiinander

• Die 3 Städte sind über ein großes Land (USA) verteilt

• Die 3 Städte sind auf der ganzen Welt verteilt

Hierdurch ergeben sich natürlich unterschiedliche Verzögerungen beim Netzwerk. In jedem Netzwerk wurde jedes Load Balancer Szenario getestet, was insgesamt 12 Experimente bedeutet. Über einen Simulationszeitraum von 1000 Sekunden, bei 75 Anfragen pro Sekunde werden die Unterschiede zwischen den Herangehensweisen deutlich.

Wie erwartet ist die Performance von Least Response Time auf allen Nodes mit Abstand am besten. Im durchschnitt ist die Anfragezeit hierbei zwischen 23% (wenn die Städte nahe beiinander sind), und 75% (bei global verteilten Städten) geringer, wenn man es mit der Ausgangsituation, einem zentralen Round Robin Load Balancer, vergleicht. Wie man in der Grafik sehen kann, sind die Ergebnisse aber noch deutlicher als das. Auf allen Ebenen ist die neue Methode nicht nur schneller, sondern auch verlässlicher. Wenn man im selben Vergleich das 50% quantil heranzieht, dann ist die Antwortzeit von verteilten LRT sogar 91% geringer. Das bedeutet, eine über 10-Fache Verbesserung. Interessant ist auch, dass diese Verbessungen sowohl durch die Auswahl näherer Nodes, also vom Netzwerk, aber auch durch die Auswahl schnellerer, also rechenstärkerer, Nodes entstehen.

Ich könnte wohl noch einige Seiten weiter ins Detail dieser Ergebnisse gehen, aber das würde den Rahmen dieses ohnehin langen Blogposts eindeutig sprengen. Es soll so viel gesagt sein: Die Ergebnisse zeigen eindeutig, dass die Herangehensweise sich auszahlt, und zeigen auch, dass in Extremsituationen Verbesserungen von einem Faktor 10 und darüber nicht ausgeschlossen sind.