Die Kunst, Container zu skalieren: Verteilung
Beim Skalieren von Containern handelt es sich um mehr, als einfach einen Proxy vor einen Dienst zu setzen und sich dann zurückzuziehen. Zur Skalierung gehört mehr als nur die Verteilung. In der schnelllebigen Welt der Container sind zur Gewährleistung der Skalierbarkeit fünf verschiedene Funktionen erforderlich: Wiederholungsversuche, Leistungsschalter, Erkennung , Verteilung und Überwachung.
In diesem Beitrag zur Kunst der Container-Skalierung befassen wir uns mit der Verteilung.
Verteilung
Der Schlüssel zur Skalierung beruht immer wieder darauf, wie Anfragen auf eine begrenzte Anzahl von Ressourcen verteilt werden. Nicht einmal die Cloud mit ihrer scheinbar unbegrenzten Rechenkapazität ändert daran Grundlegendes. Im Moment des Eingangs einer Anfrage ist die Auswahl an Ressourcen, die diese annehmen und verarbeiten können, endlich. Das ist unumstößlich.
Die Entscheidung, wohin Sie eine Anfrage leiten, spielt eine zentrale Rolle. Leiten Sie sie an die falsche Ressource, leidet die Performance. Leiten Sie sie an die richtige Ressource, freuen sich Anwender und Mitarbeiter über das Ergebnis.
In der Anfangszeit von Scale basierten diese Entscheidungen ausschließlich auf Algorithmen. Rundenturnier. Wenigste Verbindungen. Schnellste Antwort. Diese bewährten Mechanismen bestehen auch heute noch, doch sind sie langsam aber sicher nicht mehr der einzige Faktor im Entscheidungsprozess, sondern nur noch ein weiterer.
Das liegt daran, dass wir uns nicht mehr ausschließlich auf verbindungsbasierte Entscheidungsprozesse (auch bekannt als „gutes altes Lastenausgleichssystem“) verlassen. Als es beim Lastenausgleich in erster Linie um die Verwaltung von TCP-Verbindungen ging, waren auf Verbindungen basierende Verteilungsschemata sinnvoll. Doch die Skalierung basiert heute ebenso sehr auf der Architektur wie auf den Algorithmen, und die Verteilung der Anfragen kann eine komplexe Berechnung sein, in die viele Variablen oberhalb (im wahrsten Sinne des Wortes) und jenseits der Layer-4-Protokolle einfließen.
Erschwerend kommt hinzu, dass die heutigen Architekturen selbst zunehmend verteilt sind. Nicht nur über Clouds, sondern auch über Container hinweg. Es können mehrere Versionen derselben App (oder API) gleichzeitig im Einsatz sein. Das für die Verteilung der Anfragen zuständige System muss diese erkennen und zwischen ihnen unterscheiden können, um die Zustellung an den richtigen Endpunkt sicherzustellen.
Heutzutage werden Entscheidungen nicht mehr nur auf Grundlage der Verbindungskapazität, sondern zunehmend auch auf Grundlage von Layer-7-Parametern (HTTP) getroffen. Hostnamen. API-Methoden (auch bekannt als URI). API-Schlüssel. Benutzerdefinierte HTTP-Header mit eingebetteten Versionsnummern. Standort. Gerät. Benutzer. Anfragen werden im jeweiligen Kontext ausgewertet und Entscheidungen innerhalb von Mikrosekunden getroffen.
Die heutige Verteilung erfordert einen mehrstufigen, architektonischen Ansatz. Je tiefer Sie in die App-Architektur vordringen, desto weniger granular wird Ihre Verarbeitung. Bis ein Proxy eine Entscheidung zum Lastausgleich zwischen X-Klonen desselben Mikrodienstes trifft, verwendet er möglicherweise lediglich herkömmliche, algorithmisch gesteuerte Gleichungen. Währenddessen treffen Ingress-Controller an den äußeren Rändern der Umgebung teilweise komplexe Entscheidungen auf Grundlage von HTTP-Layer-Variablen.
Nach außen wird die Verteilung durch die Architektur bestimmt. Im Inneren durch Algorithmen .
Beides sind kritische Komponenten – vielleicht die kritischsten – für die Skalierung von Containern.
Beide verlassen sich auf genaue Echtzeitinformationen über den Zustand (Gesundheit) der Ressourcen, an die sie Anfragen weiterleiten könnten. Wir werden uns dem Thema Monitoring in den nächsten Beiträgen dieser Serie widmen.