L4/L7-Loadbalancing für zustandsbehaftete Anwendungen

TL;DR

Bei zustandsbehafteten Anwendungen entscheidet nicht allein die Verteilung von Verbindungen über die passende Loadbalancing-Ebene. L4 bietet geringe Eingriffstiefe und eignet sich für stabile Verbindungen, während L7 Routinglogik und Session Persistence gezielter abbilden kann. Entscheidend sind Session-Modell, Backend-Pools, Skalierungsverhalten und Failover-Strategie.

Einleitung

Zustandsbehaftete Anwendungen scheitern häufig nicht an fehlender Rechenleistung, sondern an einer unpassenden Lastverteilungsstrategie. Wird eine laufende Verbindung ohne Rücksicht auf ihren Zustand an ein anderes Backend weitergeleitet, verliert die Anwendung Kontext: Sitzungen brechen ab, Transaktionen werden inkonsistent oder Nutzer müssen sich erneut authentifizieren. Die zentrale Architekturentscheidung lautet deshalb nicht einfach „L4 oder L7“, sondern: Wo wird der Zustand gehalten, und welche Komponente kann die notwendige Bindung zuverlässig durchsetzen? L4- und L7-Loadbalancing verfolgen dabei unterschiedliche Ansätze. Die Wahl beeinflusst Session Persistence, Backend-Skalierung, Failover und den Betriebsaufwand an der Edge.

1. Warum Zustände die Lastverteilung begrenzen

Eine zustandsbehaftete Anwendung hält Informationen über eine Verbindung oder Sitzung entweder im Prozess, im lokalen Speicher des Backends oder in einer gemeinsam genutzten Datenbank. Typische Beispiele sind langlebige TCP-Verbindungen, WebSockets, bestimmte Messaging-Dienste und Anwendungen mit lokalem Session-Kontext. Eine beliebige Verteilung auf mehrere Backends ist in diesen Fällen nicht möglich, ohne den Zustand explizit zu replizieren oder zentral verfügbar zu machen.

Bei L4-Loadbalancing wird der Traffic auf Verbindungs- beziehungsweise Transportebene verteilt. Der Loadbalancer kennt typischerweise weder URL noch Cookie noch den fachlichen Kontext einer HTTP-Session. Er kann eine bestehende TCP-Verbindung einem Backend zuordnen, aber nicht anhand anwendungsbezogener Merkmale entscheiden, ob eine Sitzung logisch zusammenbleiben muss.

Das ist kein Nachteil an sich. L4 benötigt weniger Protokollverständnis und eignet sich für viele TCP-basierte Anwendungen. Problematisch wird der Ansatz, wenn eine Architektur Session Persistence erwartet, diese aber nicht auf Transportebene oder in der Anwendung abgesichert ist. Dann wird aus Backend-Skalierung ein Konsistenzproblem.

2. L4: stabile Verbindungen, begrenzte Session-Logik

Bei L4 bleibt eine einzelne Verbindung üblicherweise einem Backend zugeordnet, solange diese Verbindung besteht. Für Anwendungen mit langlebigen Sessions kann das ausreichend sein. Neue Verbindungen dürfen jedoch auf andere Backends verteilt werden. Nach einem Client-Reconnect oder bei mehreren parallelen Verbindungen entsteht daher keine automatische Garantie, dass derselbe Anwendungskontext wieder erreicht wird.

Der Vorteil liegt in der geringen Verarbeitungstiefe: TLS kann bis zum Backend durchgereicht werden, und der Loadbalancer muss die Anwendung nicht interpretieren. Das reduziert Protokollabhängigkeiten und kann für heterogene TCP-Dienste sinnvoll sein. Gleichzeitig fehlen L7-Möglichkeiten wie Routing nach Host, Pfad oder HTTP-Header.

Für die ayedo Edge Cloud ist L4 damit vor allem dann relevant, wenn die Anwendung selbst mit Verbindungsbindung, repliziertem Zustand oder einem externen Session Store arbeitet. Die Edge kann eingehende Verbindungen über verteilte PoPs und Anycast annehmen und zu Backend-Pools weiterleiten. Die eigentliche Zustandsstrategie bleibt jedoch eine Architekturentscheidung der Anwendung. Health Checks und Failover müssen außerdem so gewählt werden, dass ein Backend-Ausfall nicht nur neue, sondern auch bestehende Verbindungen berücksichtigt.

3. L7: gezieltere Persistence und höhere Komplexität

L7-Loadbalancing verarbeitet Anwendungsprotokolle wie HTTP oder HTTPS. Dadurch können Routingentscheidungen auf Basis von Hostnamen, Pfaden, Headern oder Cookies getroffen werden. Für Sticky Sessions lässt sich beispielsweise ein Sitzungsmerkmal verwenden, das einen Client wieder demselben Backend oder Backend-Pool zuordnet. Das ist präziser als eine reine Transportzuordnung, setzt aber voraus, dass die Anwendung und die Routinglogik dieses Verfahren unterstützen.

Session Persistence ist kein Ersatz für eine belastbare Zustandsarchitektur. Fällt das gebundene Backend aus, muss die Sitzung entweder auf einen replizierten Zustand zugreifen können oder verloren gehen. Auch ungleich große Sessions können die Lastverteilung verzerren: Ein Backend mit vielen langlebigen Verbindungen bleibt stark belastet, während neue Requests bereits auf andere Instanzen verteilt werden.

L7 bringt zudem TLS Termination, Protokollverarbeitung und zusätzliche Betriebsverantwortung an die Edge. In der ayedo Edge Cloud kann diese Verarbeitung mit WAF, Backend-Pools, Health Checks und Failover zusammenspielen. Das schafft zentrale Steuerungsmöglichkeiten, sollte aber nicht als automatische Garantie für Session Persistence verstanden werden. Die konkrete Persistenzlogik muss zum Session-Modell passen.

4. Backend-Skalierung und Failover richtig modellieren

Zustandsbehaftete Anwendungen skalieren anders als stateless Services. Bei stateless Workloads kann ein neuer Pod oder Server meist sofort Requests übernehmen. Bei Sticky Sessions oder langlebigen Verbindungen ist ein Backend-Pool dagegen nicht homogen: Einige Instanzen halten viele aktive Sitzungen, andere sind kaum belastet. Durchschnittliche Request-Zahlen bilden diese Situation nur unzureichend ab.

Vor einer Skalierung müssen daher mindestens drei Fragen beantwortet werden: Werden Sitzungen lokal gehalten? Wie lange bleiben Verbindungen bestehen? Was passiert bei einem Backend-Ausfall? L4 kann bestehende Verbindungen stabil halten, aber nicht sinnvoll auf eine andere Instanz migrieren. L7 kann neue Requests gezielter routen, verliert den lokalen Zustand jedoch ebenfalls, wenn keine Replikation oder externe Speicherung existiert.

Für eine Edge-Plattform bedeutet das: Health Checks sollten nicht nur den Prozessstatus prüfen, sondern die tatsächliche Bereitschaft des Backends für neue Sitzungen. Failover muss zwischen neuen Verbindungen und bestehenden Sessions unterscheiden. Backend Cloaking reduziert dabei die öffentliche Angriffsfläche, ersetzt aber keine Session- oder Replikationsstrategie. Die ayedo Edge Cloud kann vor Kubernetes-Clustern bei ayedo oder anderen Providern sowie vor eigener Infrastruktur eingesetzt werden. Damit bleibt die Zustandsarchitektur vom Compute-Standort getrennt planbar.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine Webanwendung mit lokalen Sessions und mehreren Kubernetes-Backends . Zunächst wird L4 eingesetzt. Bestehende TCP-Verbindungen bleiben stabil, aber nach Reconnects landen Nutzer teilweise auf einer anderen Instanz und verlieren ihren Kontext. Eine Umstellung auf L7 mit Cookie-basierter Bindung verbessert das Verhalten bei normalen Requests. Beim Ausfall eines Backends gehen die dort lokal gehaltenen Sessions trotzdem verloren.

Die nachhaltigere Variante verschiebt den Session-Zustand in einen gemeinsam erreichbaren Store oder repliziert ihn zwischen Instanzen. Danach kann L7 Persistence weiterhin Verbindungen und Requests gezielt verteilen, während Failover technisch beherrschbar wird. Alternativ bleibt L4 sinnvoll, wenn die Anwendung selbst Verbindungszustand und Wiederaufnahme kontrolliert. Entscheidend ist nicht die vermeintlich höhere Ebene, sondern die Übereinstimmung von Loadbalancer, Session-Modell und Ausfallverhalten.

FAQ

Sind Sticky Sessions immer erforderlich?

Nein. Sie sind nur nötig, wenn Sitzungszustand lokal am Backend liegt oder Verbindungen an eine bestimmte Instanz gebunden sind. Replizierte oder externe Zustände erlauben meist eine freiere Verteilung.

Ist L7 grundsätzlich besser für zustandsbehaftete Anwendungen?

Nein. L7 bietet mehr Routinginformationen, aber auch mehr Komplexität. Für reine TCP-Dienste oder anwendungsseitig kontrollierte Zustände kann L4 die passendere und robustere Ebene sein.

Was passiert bei der Backend-Skalierung?

Neue Backends übernehmen meist neue Verbindungen oder Sessions. Bestehende Bindungen werden nicht automatisch migriert. Bei Sticky Sessions kann deshalb eine kontrollierte Drain- und Failover-Strategie notwendig sein.

Fazit

Loadbalancing zustandsbehaftete Anwendungen verlangt eine klare Trennung zwischen Verbindungsbindung, Session Persistence und eigentlicher Zustandsverwaltung. L4 bewahrt Verbindungen mit geringer Protokolltiefe, L7 ermöglicht gezielteres Routing, löst aber keine lokalen Zustände. Eine Edge-Plattform wie die ayedo Edge Cloud schafft den verteilten öffentlichen Einstieg, Schutz und Backend-Failover. Die belastbare Lösung entsteht erst durch das Zusammenspiel mit Session- und Skalierungsdesign der Anwendung.