Lastausgleichs-Apps und APIs: Algorithmen versus Architektur
Im Großen und Ganzen sind das Skalieren von Apps und APIs so ziemlich dasselbe. Beide erfordern eine Art Lastenausgleich – normalerweise einen Proxy – und müssen Anfragen auf einen Ressourcenpool verteilen.
Es gibt jedoch ziemlich große Unterschiede hinsichtlich der Art und Weise, wie diese Anfragen auf die Ressourcen verteilt werden. Bei Algorithmen verteilen wir tatsächlich die Last, während wir bei der Architektur die Last lenken. Nun mag dies wie eine pedantische Unterscheidung erscheinen, die man besser der Wissenschaft überlässt. Die Wahrheit ist, dass die Wahl zwischen Algorithmen und Architektur erhebliche Auswirkungen auf Umfang und Leistung hat. Da beides im Grunde der Grund dafür ist, dass Sie Lastenausgleich verwenden, ist die Unterscheidung wichtig.
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.
Wie man sich denken kann, werden bei der guten alten algorithmischen Lastverteilung im Entscheidungsprozess Algorithmen verwendet. Das bedeutet, dass Verteilungsalgorithmen wie Round Robin, Least Connections, Fastest Response und deren gewichtete Äquivalente verwendet werden, um eine Ressource auszuwählen, die auf eine bestimmte Anfrage antwortet.
Dies ist eine einfache Entscheidung. Wie dem Honigdachs geht es Algorithmen nur um die Ausführung auf Grundlage der verfügbaren Daten. Wenn fünf Ressourcen verfügbar sind, wird basierend auf dem Algorithmus eine dieser fünf ausgewählt. Zeitraum.
Wie Sie sich vorstellen können, ist der algorithmusbasierte Lastausgleich ziemlich schnell. Mit der heutigen Rechenleistung dauert es nicht lange, den entsprechenden Algorithmus auszuführen und eine Entscheidung zu treffen. Mit Ausnahme von Round Robin und bestimmten Algorithmen zur gewichteten Verteilung sind Algorithmen zustandsbehaftet. Das heißt, sie müssen Variablen im Auge behalten wie „Wie viele Verbindungen bestehen derzeit zu den Ressourcen A, B und C?“ oder „Welche Ressource hat am schnellsten auf ihre letzte Anfrage reagiert?“ Der Load Balancer muss diese Informationen im Auge behalten. Diese Informationen können sehr umfangreich werden und in Umgebungen, in denen herkömmliche, monolithische Applications skaliert werden, die mehrere langlebige Verbindungen erfordern, mehr Ressourcen für die Verwaltung erfordern.
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.
Doch in der Realität sind APIs häufig chaotisch. Sie werden von mehreren Diensten (oft Mikroservices) unterstützt und können über mehrere Standorte verteilt sein. Sie sind selten 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. Darüber hinaus können mobile Apps sowohl alte als auch neue Ressourcen nutzen, indem sie Bilder mit Web-Apps teilen und dieselben APIs wie alle anderen verwenden.
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.