Lastausgleichs-Apps und APIs: Algorithmen versus Architektur

Die Skalierung von Apps und APIs funktioniert im Wesentlichen gleich. Beide setzen auf einen Load Balancer – meist einen Proxy – und erfordern die Verteilung von Anfragen auf einen Pool von Ressourcen.

Es gibt einen deutlich spürbaren Unterschied darin, wie diese Anfragen auf die Ressourcen verteilt werden. Bei Algorithmen verteilen wir wirklich die Last, bei der Architektur lenken wir die Last bewusst. Das mag wie eine akademische Spitzfindigkeit erscheinen. Doch die Wahl zwischen Algorithmen und Architektur beeinflusst maßgeblich Skalierung und Leistung. Da Ihnen beide Konzepte aus gutem Grund beim Lastenausgleich helfen, ist diese Unterscheidung entscheidend.

Einfaches, gutes Lastenausgleichssystem

Algorithmenbasierter Lastausgleich kann einfach als Lastausgleich oder, wie ich es gerne nenne, als einfaches altes Lastausgleich bezeichnet werden. Dies ist die Skalierungsmethode, die wir bereits seit vor der Jahrhundertwende verwenden. Sein Alter bedeutet nicht, dass man es aufgeben sollte, ganz im Gegenteil. In vielen Situationen ist das gute alte Lastenausgleichsverfahren die beste Wahl, um Skalierung und Leistung in Einklang zu bringen.

Klassisches algorithmisches Load Balancing nutzt, wie man vermuten kann, Algorithmen zur Entscheidungsfindung. Dabei setzen wir Verteilungsalgorithmen wie Round Robin, Least Connections, Fastest Response und deren gewichtete Varianten ein, um gezielt eine Ressource zur Beantwortung einer Anfrage auszuwählen.

Das ist eine klare Entscheidung. Ähnlich wie beim Honigdachs konzentrieren sich Algorithmen allein darauf, die verfügbaren Daten umzusetzen. Sind fünf Ressourcen verfügbar, wählen wir eine davon basierend auf dem Algorithmus aus. Ende der Durchsage.

Algorithmenbasierte Lastverteilung ist, wie Sie sicher erwarten, äußerst schnell. Mit heutiger Rechenleistung führt sie den passenden Algorithmus schnell aus und trifft die richtige Entscheidung. Außer bei Round Robin und einigen gewichteten Verteilungsalgorithmen arbeiten Algorithmen zustandsbehaftet. Das heißt, sie verfolgen Variablen wie „Wie viele Verbindungen bestehen aktuell zu Ressource A, B und C?“ oder „Welche Ressource hat zuletzt am schnellsten reagiert?“ Der Load Balancer speichert diese Informationen. Je größer die Umgebung mit traditionellen, monolithischen Anwendungen wird, die mehrere langlebige Verbindungen benötigen, desto umfangreicher werden diese Daten und desto mehr Ressourcen braucht das Management.

Die Stärken des herkömmlichen Lastenausgleichs liegen in der Skalierung von Microservices. Das liegt daran, dass jeder Microservice eine Funktion hat (oder in einer idealen Architektur haben sollte). Die Skalierung dieser Dienste lässt sich durch den Einsatz eines Basisalgorithmus (normalerweise Round Robin) problemlos erreichen, da sie im Allgemeinen hinsichtlich Kapazität und Leistung gleichwertig sind. Aufgrund der Art von Microservices-Architekturen, die möglicherweise mehrere Serviceaufrufe erfordern, um eine einzelne Benutzeranforderung zu erfüllen, sind schnelle Entscheidungen ein Muss. Daher ist ein grundlegender, algorithmusbasierter Lastausgleich für solche Umgebungen eine gute Wahl.

Grundsätzlich gilt die Faustregel: Wenn Sie einfache Dienste mit einem begrenzten Funktionsumfang skalieren, die alle im Hinblick auf die Leistung im Allgemeinen gleichwertig sind, reicht das gute alte Lastenausgleichsverfahren aus. Dies sehen Sie in Containerumgebungen und der Grund, warum so viele der nativen Skalierungsfunktionen auf einfachen Algorithmen basieren.  

Für andere Applications und Situationen müssen Sie sich mit einer architekturbasierten Lastverteilung befassen.

HTTP-Lastenausgleich

Architekturbasiertes Lastenausgleich ist die Kunst (ja, Kunst, keine Wissenschaft), mithilfe eines Lastenausgleichs Anfragen so aufzuteilen, dass sie der Architektur der zu skalierenden Application entsprechen. Beim architekturbasierten Lastenausgleich geht es eher darum, den Datenverkehr zu lenken, als ihn zu verteilen. Das liegt daran, dass es die Vorteile von Layer 7 (normalerweise HTTP) nutzt, um zu entscheiden, wohin eine bestimmte Anfrage gehen muss, und deshalb nennen wir es in der Regel HTTP-Lastausgleich (neben anderen esoterischeren (und netzwerkbezogeneren) Begriffen). 

In einer Welt, die durch APIs zugänglich gemacht und auf Mikroservices basiert, wird die Fähigkeit, Anfragen weiterzuleiten, immer wichtiger. Denn Sie müssen in der Lage sein, API-Anfragen versioniert weiterzuleiten, Hostnamen oder URI-Pfade zu verwenden, um Anfragen an bestimmte Microservices zu versenden oder eine Application in ihre Funktionalität zu zerlegen.

Die meisten Organisationen möchten eine konsistente API bereitstellen, die einfach zu verwenden ist. Unabhängig davon, ob es darum geht, „Citizen Developer“ zur Erstellung neuer Applications unter Verwendung der API zu ermutigen oder Partnern eine einfache Verbindung und Integration zu ermöglichen, ist eine konsistente, einfache API für die Gewährleistung der Akzeptanz zwingend erforderlich.

APIs sind in der Praxis häufig komplex. Hinter ihnen stehen mehrere Dienste (oft Microservices), die über verschiedene Standorte verteilt sein können. Sie beschränken sich selten auf einen einzelnen Dienst. Hinzu kommt: Sie werden häufiger aktualisiert als frühere App-Generationen und sind nicht zuverlässig rückwärtskompatibel. Mobile Apps nutzen sowohl ältere als auch neue Ressourcen – sie teilen Bilder mit Web-Apps und greifen auf dieselben APIs zu wie alle anderen.

Um diese „Apps“ und APIs zu skalieren, ist ein architektonischer Ansatz zum Lastenausgleich erforderlich. Sie müssen den Datenverkehr leiten , bevor Sie ihn verteilen. Das bedeutet, dass Sie einen Layer 7-fähigen (HTTP) Load Balancer verwenden müssen, um Architekturmuster wie URL-Versand, Datenpartitionierung und funktionale Zerlegung zu implementieren. Jedes dieser Muster ist architektonischer Natur und erfordert eine größere Affinität zum Application oder API-Design als dies bei herkömmlichen Apps der Fall ist.

Der HTTP-Lastausgleich wird immer wichtiger, wenn es darum geht, Apps zu skalieren und gleichzeitig Effizienz und Agilität in Einklang zu bringen sowie APIs zu unterstützen. 

Skalierbarkeit erfordert beides

In der realen Welt sieht man selten nur eine Art von Waage. Das liegt daran, dass Unternehmen zunehmend robuste Applications bereitstellen, die sich über Jahrzehnte der Entwicklung, App-Architekturen, Plattformen und Technologien erstrecken. Nur sehr wenige Organisationen können von sich behaupten, nur „moderne“ Applications zu unterstützen (es sei denn, „modern“ umfasst alles, was nicht auf einem Mainframe läuft).

Daher werden Sie wahrscheinlich sowohl algorithmische als auch architektonische Lastverteilung sehen – und verwenden –, um eine Vielzahl von Applications zu skalieren. Deshalb ist es wichtig, den Unterschied zu verstehen. Denn die Verwendung des einen, wenn das andere besser geeignet ist, kann zu Leistungseinbußen und/oder Ausfällen führen, was wiederum weder für die Benutzer noch für das Unternehmen oder für Sie gut ist. 

Um moderne Applications zu skalieren, werden Sie die beiden Ansätze immer häufiger kombiniert sehen. Manchmal bestehen die beiden tatsächlich als ein einziger Dienst, der darauf ausgelegt ist, das Logische (die API) und das Physische (den eigentlichen Dienst hinter der API) zu skalieren. Application Delivery Controller (ADC) sind üblicherweise die Plattform, auf der ein kombinierter Ansatz implementiert wird, da sie beides mit der gleichen Geschwindigkeit ausführen können.

Manchmal werden diese von zwei verschiedenen Systemen durchgeführt. Beispielsweise ist in Containerumgebungen ein Ingress-Controller für den architektonischen Lastausgleich verantwortlich, während interne, native Dienste im Allgemeinen mithilfe eines algorithmischen Lastausgleichs für die Skalierung zuständig sind.

Unabhängig von den Implementierungs- und Bereitstellungsdetails spielen bei der Skalierung von Apps und APIs tatsächlich sowohl algorithmische als auch architekturbasierte Ansätze zum Lastenausgleich eine Rolle. Der Schlüssel zur Maximierung Ihrer Stärken zu Ihrem Vorteil liegt darin, den Lastausgleich an die Application anzupassen.

Skalieren Sie.