Lastverteilung für Apps und APIs: Algorithmen versus Architektur

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Im Großen und Ganzen funktioniert die Skalierung von Apps und APIs nahezu gleich. Beide benötigen eine Art Load Balancer – in der Regel einen Proxy –, der die Anfragen auf einen Ressourcenpool verteilt.

Es gibt jedoch einen ziemlich bedeutenden Unterschied darin, wie diese Anfragen auf die Ressourcen verteilt werden. Bei Algorithmen verteilen wir tatsächlich die Last, während wir sie bei der Architektur gezielt lenken. Das mag wie eine pedantische Unterscheidung erscheinen, die man besser der Wissenschaft überlässt. Tatsächlich hat die Entscheidung zwischen Algorithmen und Architektur jedoch tiefgreifende Auswirkungen auf Skalierbarkeit und Leistung. Da beides gewissermaßen der Grund für den Einsatz von Lastverteilung ist, wird diese Unterscheidung zu einem wichtigen Faktor.

Ganz gewöhnlicher Lastenausgleich

Algorithmusbasiertes Load Balancing kann einfach als Load Balancing bezeichnet werden oder, wie ich es gerne nenne, ganz klassisches Load Balancing. Diese Skalierungsmethode verwenden wir bereits seit der Zeit vor der Jahrtausendwende. Ihr Alter bedeutet jedoch nicht, dass sie aufgegeben werden sollte – ganz im Gegenteil. In vielen Situationen ist ganz klassisches Load Balancing die beste Wahl, um Skalierbarkeit und Leistung in Einklang zu bringen.

Beim guten alten algorithmischen Load Balancing kommen – wie man sich denken kann – Algorithmen zur Entscheidungsfindung zum Einsatz. Das bedeutet, dass Verteilungsalgorithmen wie Round Robin, Least Connections, Fastest Response und deren gewichtete Varianten verwendet werden, um eine Ressource auszuwählen, die auf eine bestimmte Anfrage antwortet.

Das ist eine eindeutige Entscheidung. Wie der Honigdachs kümmern sich Algorithmen um nichts anderes, als auf Grundlage der verfügbaren Daten ihre Aufgabe auszuführen. Wenn fünf Ressourcen verfügbar sind, wird anhand des Algorithmus eine dieser fünf ausgewählt. Punkt.

Algorithmusbasiertes Load Balancing ist, wie Sie sich vorstellen können, ziemlich schnell. Mit der heutigen Rechenleistung dauert es nicht lange, den passenden Algorithmus auszuführen und eine Entscheidung zu treffen. Mit Ausnahme von Round Robin und bestimmten Algorithmen zur gewichteten Verteilung sind Algorithmen zustandsbehaftet. Das bedeutet, dass sie Variablen nachverfolgen müssen, etwa: „Wie viele Verbindungen zu den Ressourcen A, B und C bestehen derzeit?“ oder „Welche Ressource hat auf die letzte Anfrage am schnellsten reagiert?“ Der Load Balancer muss diese Informationen nachverfolgen. In Umgebungen, in denen herkömmliche monolithische Anwendungen skaliert werden, die mehrere langlebige Verbindungen benötigen, kann diese Datenmenge erheblich anwachsen und ihre Verwaltung zusätzliche Ressourcen erfordern.

Beim Skalieren von Microservices spielt herkömmliches Load Balancing seine Stärken aus. Das liegt daran, dass jeder Microservice nur eine Funktion hat (oder in einer idealen Architektur haben sollte). Diese Services lassen sich problemlos mithilfe eines einfachen Algorithmus (in der Regel Round Robin) skalieren, da sie hinsichtlich Kapazität und Leistung im Allgemeinen gleichwertig sind. Aufgrund der Beschaffenheit von Microservices-Architekturen, bei denen zur Bearbeitung einer einzelnen Benutzeranfrage möglicherweise mehrere Serviceaufrufe erforderlich sind, müssen Entscheidungen schnell getroffen werden. Daher ist einfaches, algorithmusbasiertes Load Balancing eine gute Wahl für solche Umgebungen.

Als Faustregel gilt: Wenn Sie einfache Dienste mit einem begrenzten Funktionsumfang skalieren, die hinsichtlich ihrer Leistung im Allgemeinen gleichwertig sind, reicht herkömmliches Load Balancing aus. Genau das ist innerhalb von Container-Umgebungen zu beobachten und der Grund dafür, dass so viele der nativen Skalierungsfunktionen auf einfachen Algorithmen basieren.

Für andere Anwendungen und Szenarien müssen Sie auf architekturbasiertes Load Balancing zurückgreifen.

HTTP-Lastverteilung

Architekturbasiertes Load Balancing ist die Kunst (ja, Kunst, nicht Wissenschaft), mithilfe eines Load Balancers Anfragen so aufzuteilen, dass dies der Architektur der zu skalierenden Anwendung entspricht. Beim architekturbasierten Load Balancing geht es eher darum, den Datenverkehr zu lenken, als ihn zu verteilen. Denn es nutzt Layer 7 (in der Regel HTTP), um zu entscheiden, wohin eine bestimmte Anfrage geleitet werden muss. Deshalb bezeichnen wir es meist als HTTP Load Balancing (neben anderen, eher esoterischen und netzwerkorientierten Begriffen).

Die Fähigkeit, Anfragen gezielt weiterzuleiten, gewinnt in einer Welt, die über APIs zugänglich gemacht wird und auf Microservices basiert, zunehmend an Bedeutung. Denn API-Anfragen müssen je nach Version weitergeleitet, anhand von Hostnamen oder URI-Pfaden bestimmten Microservices zugeordnet oder zur funktionalen Zerlegung einer Anwendung entsprechend verteilt werden können.

Die meisten Unternehmen möchten eine einheitliche, benutzerfreundliche API bereitstellen. Ob damit Citizen Developer dazu angeregt werden sollen, neue Anwendungen zu entwickeln, die diese API nutzen, oder Partnern eine einfache Anbindung und Integration ermöglicht werden soll – eine einheitliche, unkomplizierte API ist für eine breite Akzeptanz unerlässlich.

Doch in der Praxis sind APIs oft unübersichtlich. Sie basieren auf mehreren Diensten (häufig Microservices), die über verschiedene Standorte verteilt sein können. Nur selten sind sie auf einen einzigen Dienst beschränkt. Erschwerend kommt hinzu, dass sie häufiger aktualisiert werden als frühere App-Generationen und nicht zuverlässig abwärtskompatibel sind. Zudem können mobile Apps sowohl alte als auch neue Ressourcen nutzen, Bilder mit Web-Apps teilen und dieselben APIs wie alle anderen verwenden.

Um diese „Apps“ und APIs zu skalieren, ist ein architektonischer Ansatz für den Lastenausgleich erforderlich. Sie müssen den Datenverkehr zunächst steuern, bevor Sie ihn verteilen. Das bedeutet, dass Sie einen Layer-7-fähigen (HTTP) Load Balancer einsetzen müssen, um Architekturmuster wie URL-Weiterleitung, Datenpartitionierung und funktionale Zerlegung zu implementieren. Jedes dieser Muster ist architektonischer Natur und muss stärker auf das Anwendungs- oder API-Design abgestimmt sein als bei herkömmlichen Apps.

HTTP-Lastverteilung gewinnt zunehmend an Bedeutung, wenn es darum geht, Anwendungen zu skalieren, dabei Effizienz und Agilität in Einklang zu bringen und zugleich APIs zu unterstützen.

Skalierbarkeit erfordert beides

In der Praxis werden Sie nur selten ausschließlich eine Art der Skalierung vorfinden. Das liegt daran, dass Unternehmen zunehmend ein umfangreiches Anwendungsportfolio bereitstellen, das Jahrzehnte der Entwicklung sowie unterschiedlichste Anwendungsarchitekturen, Plattformen und Technologien umfasst. Nur sehr wenige Unternehmen können von sich behaupten, ausschließlich „moderne“ Anwendungen zu unterstützen (es sei denn, als modern gilt alles, was nicht auf einem Mainframe läuft).

Daher werden Sie wahrscheinlich sowohl algorithmischen als auch architektonischen Lastenausgleich sehen – und einsetzen –, um eine Vielzahl von Anwendungen zu skalieren. Deshalb ist es wichtig, den Unterschied zu verstehen, denn wenn Sie die eine Methode verwenden, obwohl die andere besser geeignet wäre, kann dies zu Leistungseinbußen und/oder Ausfällen führen – und beides ist weder für die Benutzer noch für das Unternehmen oder für Sie selbst gut.

Zunehmend werden Sie erleben, dass beide Ansätze kombiniert werden, um moderne Anwendungen zu skalieren. Manchmal werden beide sogar in einem einzigen Dienst vereint, der sowohl die logische Ebene (die API) als auch die physische Ebene (den eigentlichen Dienst hinter der API) skaliert. Application Delivery Controller (ADC) dienen in der Regel als Plattform für die Umsetzung eines kombinierten Ansatzes, da sie beide Aufgaben gleichermaßen effizient bewältigen können.

Manchmal werden diese Aufgaben von zwei verschiedenen Systemen übernommen. In containerisierten Umgebungen ist beispielsweise ein Ingress-Controller für den architekturbasierten Lastenausgleich zuständig, während interne, native Dienste in der Regel die Skalierung mithilfe eines algorithmischen Lastenausgleichs übernehmen.

Unabhängig von den Details der Implementierung und Bereitstellung spielen sowohl algorithmische als auch architekturbasierte Ansätze für den Lastenausgleich eine wichtige Rolle bei der Skalierung von Anwendungen und APIs. Um ihre jeweiligen Stärken optimal zu nutzen, muss der Lastenausgleich auf die Anwendungsarchitektur abgestimmt werden.

Weiter skalieren.

Ü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