Die zwei Fragen, die Sie beantworten müssen, um Hochverfügbarkeit zu erreichen

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Die vielleicht größte Auswirkung der abrupten Verlagerung von Verbrauchern und Beschäftigten hin zu digitalen Angeboten auf den Betrieb betrifft deren Verfügbarkeit. Zweifellos hatte ein erheblicher Anteil der Unternehmen Probleme mit dem Fernzugriff, als die Beschäftigten vom Büro ins Homeoffice wechselten. Doch während nur ein Teil der Beschäftigten letztlich von zu Hause aus arbeitete, waren plötzlich ganze Bevölkerungsgruppen auf digitale Alternativen für ihren Alltag angewiesen.

Betrachten wir die Ergebnisse von Nokia, denen zufolge der „Upstream-Datenverkehr (in ausgewählten Netzen in den USA) im März 2020“ gegenüber dem Niveau vor der Pandemie „um 30 % gestiegen ist“. Oder diese Daten, die für die zweite Aprilwoche einen Anstieg der Transaktionen um 72 % (und der Seitenaufrufe um 29 %) zeigen.

Die Nachfrage nach digitalen Erlebnissen steigt. Und für Nutzer gibt es kaum etwas Frustrierenderes als eine App oder Website, die nicht geladen werden kann. Ehrlich gesagt gibt es auch für einen Betreiber kaum etwas Frustrierenderes als eine App oder Website, die nicht geladen werden kann.

Um Hochverfügbarkeit zu erreichen, reicht es nicht aus, einfach einen Load Balancer in den Datenpfad einzufügen. Das ist zwar ein Teil der Lösung, aber nur einer der notwendigen Schritte, um sicherzustellen, dass eine App oder Website verfügbar bleibt.

Als Erstes müssen Sie zwei nicht ganz einfache Fragen beantworten:

• Wie verteilen Sie den Datenverkehr auf mehrere Server, um eine hohe Verfügbarkeit zu gewährleisten?
• Welcher Umfang an Zustandsprüfungen ist erforderlich, um die Verfügbarkeit eines Servers zuverlässig zu überprüfen?

Auf den ersten Blick scheinen diese Fragen einfacher zu sein, als sie tatsächlich sind. Denn um sie beantworten zu können, muss man viel über die App und ihre Infrastruktur wissen.

Legen wir los, oder?

Wie verteilen Sie den Datenverkehr auf mehrere Server, um eine hohe Verfügbarkeit zu gewährleisten?

Diese Frage zielt im Kern darauf ab, welcher Lastverteilungsalgorithmus der richtige ist, denn Algorithmen bestimmen, wie der Datenverkehr (Anfragen) auf die Ressourcen (Server) verteilt wird. Die Antwort darauf hängt von vielen Faktoren ab, wobei zunächst die Architektur und die Nutzungsmuster der Anwendung betrachtet werden müssen.

Wenn Sie eine herkömmliche Anwendung (Monolith, Client-Server, dreischichtige Webanwendung) hochverfügbar machen möchten, müssen Sie die Nutzungsmuster aus einer völlig anderen Perspektive betrachten.

Das liegt daran, dass ein einziger Backend-„Server“ für die Ausführung der gesamten Geschäftslogik verantwortlich ist. Sie möchten sich anmelden? Ein Produkt bestellen? Im Katalog stöbern? Dafür ist immer derselbe „Server“ zuständig. Man könnte nun meinen, dass sich der Datenverkehr einfach mit einem simplen Algorithmus wie Round-Robin verteilen ließe. Weit gefehlt, mein Freund. Jede Geschäftsfunktion stellt andere Anforderungen an Rechenleistung, Arbeitsspeicher, Netzwerk und Daten. Das bedeutet, dass jede Geschäftsfunktion den „Server“ unterschiedlich stark belastet. Eine einzelne „Server“-Instanz kann schnell überlastet werden, wenn zu viele ressourcenintensive Anfragen an sie weitergeleitet werden.

Die beste Möglichkeit, die Verteilung von Anfragen zu optimieren und so die Verfügbarkeit herkömmlicher Anwendungen sicherzustellen, ist die Verwendung eines Algorithmus nach dem Least-Connections-Prinzip. Dadurch wird die Last anhand der Anzahl der aktuell offenen Verbindungen auf die einzelnen „Server“-Instanzen verteilt. Das funktioniert, weil die Verarbeitung ressourcenintensiver Anfragen länger dauert und die Verbindungen dadurch länger aktiv bleiben. Indem Anfragen an „Server“ mit weniger Verbindungen weitergeleitet werden, lässt sich die Verfügbarkeit aller Instanzen mit höherer Wahrscheinlichkeit aufrechterhalten.

Bei modernen (auf Microservices basierenden) Anwendungen lässt sich diese Frage leichter beantworten. Das liegt daran, dass eine moderne Anwendung bereits in Geschäftsfunktionen unterteilt ist, die sich unabhängig voneinander skalieren lassen. Dennoch empfiehlt sich ein Algorithmus nach dem Least-Connections-Prinzip, da manche Anfragen für dieselbe Funktion mehr Ressourcen beanspruchen können als andere. In einer modernen Anwendungsarchitektur wird der Datenverkehr jedoch auf natürliche Weise verteilt, sodass praktisch jeder Algorithmus dazu beiträgt, dass alle „Server“ verfügbar bleiben.

Das Interessante an der Verfügbarkeit ist – zumindest für mich –, dass das Wissen darüber, wie Anfragen verteilt werden müssen, nur die halbe Miete ist. Bei der anderen Hälfte geht es leider nicht um rote und blaue Laser, sondern darum, Einblick in den Zustand der Anwendung zu haben.

Welcher Umfang an Zustandsprüfungen ist erforderlich, um die Verfügbarkeit eines Servers zuverlässig zu überprüfen?

An dieser Stelle müsste eigentlich meine Abhandlung über Observability* stehen, aber der Kürze und Ihrer geistigen Gesundheit zuliebe fasse ich es einfach wie folgt zusammen:

Wenn Sie den Status einer Anwendung anhand eines anderen Kriteriums als der „Anwendungsverfügbarkeit“ bestimmen, gefährden Sie die Hochverfügbarkeit. Denn keine der anderen beobachtbaren Messgrößen sagt etwas über die Anwendung selbst aus. Netzwerk, Transport und Plattform müssen zwar verfügbar sein, doch solange nicht sichergestellt ist, dass die Anwendung Anfragen entgegennehmen kann, riskieren Sie Probleme, wenn Sie Datenverkehr an sie weiterleiten.

Alle vier Komponenten der Observability sind wichtig. Wenn die Netzwerkverbindung ausfällt, spielt der Rest letztlich keine Rolle mehr. Daher müssen Sie alle vier Messgrößen im Blick behalten, also auch alle überprüfen. Dabei spielt es keine Rolle, wie die App-Architektur aufgebaut ist. Alle Apps sind von der Netzwerk-, Transport- und Plattformschicht abhängig. Einen Unterschied macht die Architektur auf der App-Schicht, da sie die Möglichkeiten einschränken kann, mit denen Sie feststellen, ob die App funktioniert oder nicht.

Während der Entwicklung sollten Sie immer nach einer Möglichkeit fragen, einen „Health Check“ für die App durchzuführen. Ob über eine API oder eine HTTP-Anfrage: Ein dedizierter „Health Check“ bietet Entwicklern und Betriebsteams eine einfache Möglichkeit, zu überprüfen, ob die App ordnungsgemäß funktioniert. Dies kann auch Funktionen umfassen, mit denen die Verbindung zu externen Ressourcen wie Datenquellen oder Partner-APIs überprüft wird. Da der Ausfall einer dieser Komponenten dazu führen kann, dass die App für den Nutzer nicht verfügbar erscheint oder nicht reagiert, ist es wichtig, die Verfügbarkeit aller erforderlichen Komponenten zu überprüfen.

Hochverfügbarkeit ist schwieriger, als es scheint

Marketingmaterialien vermitteln oft den Eindruck, Hochverfügbarkeit sei so einfach, wie einen Server zu klonen und einen Load Balancer davorzuschalten. Tatsächlich sind jedoch sorgfältige Überlegungen, Messungen und Vorbereitungen erforderlich, um die Hochverfügbarkeit einer Anwendung sicherzustellen. Es reicht nicht aus, dafür zu sorgen, dass die Instanzen verfügbar sind. Auch alle Anwendungen, von denen sie abhängen, müssen verfügbar sein, und die Anfragen müssen so verteilt werden, dass keine einzelne Instanz überlastet wird.

Der Vorteil des zusätzlichen Aufwands, den Sie betreiben, um eine hohe Verfügbarkeit Ihrer Apps sicherzustellen, liegt in einem positiven Kundenerlebnis und weniger hektischen Anrufen spät in der Nacht wegen ausgefallener Apps.

_{* Ich habe eigentlich keine Dissertation zum Thema Observability. Aber wenn ich eine hätte, wäre sie an dieser Stelle eingefügt worden.}

Ü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