L7-Loadbalancing: Routing nach HTTP-Merkmalen für APIs

TL;DR

L7 Loadbalancing verteilt Anfragen nicht nur anhand von IP-Adresse und Port, sondern wertet den HTTP-Kontext aus. Pfad, Hostname, Methode oder Header können unterschiedliche Backend-Pools ansprechen. Das ermöglicht API-spezifisches Routing, verlangt aber klar getrennte Backends, konsistente Verträge und ein belastbares Betriebsmodell.

Einleitung

Ein Loadbalancer, der alle Anfragen eines Hosts gleich behandelt, verschenkt bei APIs wichtige Steuerungsmöglichkeiten. /v1/orders, /v2/orders und /health können unterschiedliche Betriebsanforderungen haben, obwohl sie denselben Port verwenden. L4-Loadbalancing sieht an dieser Stelle primär Verbindungen und Netzwerkadressen. L7 Loadbalancing verarbeitet dagegen den HTTP-Kontext und kann Anfragen nach ihrer fachlichen oder technischen Bedeutung verteilen. Damit verschiebt sich die Architekturentscheidung: Nicht mehr nur die Erreichbarkeit eines Backends zählt, sondern die Frage, welcher Backend-Pool für eine konkrete Anfrage zuständig ist. Das verbessert Isolation und Weiterentwicklung, erhöht aber die Anforderungen an Routingregeln und Backend-Strukturen.

1. Was L7 Loadbalancing vom L4-Modell unterscheidet

L4-Loadbalancing arbeitet auf Transportebene. Typische Kriterien sind Ziel-IP, Port und der Zustand einer TCP- oder UDP-Verbindung. Ein Backend erhält dabei grundsätzlich den Traffic, der an einen bestimmten Listener adressiert ist. Die Entscheidung ist schnell und protokollnah, enthält aber keine Information darüber, welche HTTP-Ressource angefordert wird.

L7 Loadbalancing terminiert oder verarbeitet dagegen HTTP beziehungsweise HTTPS und kann den Request-Kontext berücksichtigen. Mögliche Kriterien sind der Hostname, der URL-Pfad, die HTTP-Methode, ausgewählte Header oder weitere anwendungsnahe Attribute. Eine Anfrage an api.example.com kann dadurch anders behandelt werden als eine an www.example.com; ebenso können /v1 und /v2 getrennte Pools erreichen.

Der Preis dieser Kontrolle ist zusätzliche Komplexität. TLS muss an einem Punkt entschlüsselt werden, Regeln müssen versioniert und getestet werden, und Fehlkonfigurationen wirken direkt auf den Anwendungstraffic. L7 ist deshalb keine pauschal bessere Variante, sondern eine bewusste Entscheidung für anwendungsbezogene Steuerung.

2. HTTP-Routing für APIs und Web-Traffic

Für APIs ist der URL-Pfad häufig das stabilste Routingmerkmal. Versionierte Pfade können auf getrennte Backend-Pools zeigen, etwa wenn eine neue API-Version zunächst unabhängig betrieben wird. Auch HTTP-Methoden können relevant sein: Lesezugriffe lassen sich beispielsweise anders verteilen als schreibende Requests, sofern die Backend-Architektur diese Trennung fachlich unterstützt.

Der Hostname trennt häufig unterschiedliche Dienste oder Mandanten. Header können zusätzliche Informationen liefern, etwa einen Kanal, eine API-Version oder einen kontrollierten Testverkehr. Dabei sollten Header nicht blind als vertrauenswürdige Identität behandelt werden. Clientseitig gesetzte Werte müssen validiert werden; für sicherheitsrelevante Entscheidungen sind Authentisierung und Autorisierung in den dafür vorgesehenen Komponenten zuständig.

Ein API-Gateway und ein L7-Loadbalancer überschneiden sich teilweise, sind aber nicht identisch. Das Gateway kann zusätzlich Richtlinien, Quoten oder Transformationen umsetzen. Das L7 Loadbalancing fokussiert auf die Auswahl des Ziel-Backends. Diese Funktionen können kombiniert werden, sollten aber konzeptionell getrennt bleiben, damit Routingregeln nachvollziehbar und betrieblich beherrschbar bleiben.

3. Anforderungen an Backend-Pools und Betriebsmodell

HTTP-basiertes Backend-Routing funktioniert nur, wenn die Zielpools klar definiert sind. Jeder Pool braucht einen eindeutigen Verantwortungsbereich, passende Health Checks und ein Verhalten für nicht verfügbare Instanzen. Ein Routingziel darf nicht lediglich technisch erreichbar sein; es muss die erwartete API-Funktion vollständig und kompatibel bereitstellen.

Besonders wichtig ist die Behandlung von Zuständen. Werden Requests derselben fachlichen Sitzung auf unterschiedliche Pools verteilt, können In-Memory-Sessions, Caches oder Schreib-/Lese-Replikate zu inkonsistentem Verhalten führen. Besser sind zustandsarme Services oder explizite Mechanismen für Session- und Datenkonsistenz. Auch Deployments benötigen ein klares Verfahren: Neue Versionen müssen über Pfade, Header oder kontrollierte Gewichtsverteilung erreichbar sein, ohne bestehende Clients unbeabsichtigt umzuleiten.

Monitoring muss die Routingentscheidung sichtbar machen. Statuscodes, Latenzen und Fehler sollten mindestens nach Host, Pfad oder Backend-Pool analysierbar sein. Sonst bleibt unklar, ob ein Fehler im Edge-Routing, im Gateway oder in der Anwendung entsteht. Diese Transparenz reduziert die Zeit zur Ursachenanalyse und verhindert, dass fehlerhafte Regeln unbemerkt Traffic auf ungeeignete Backends lenken.

4. Sicherheits- und Architekturfolgen

L7 verarbeitet den Inhalt von HTTP-Anfragen und liegt damit an einer sicherheitsrelevanten Kontrollstelle. TLS Termination an der Edge ermöglicht, den Request vor der Weiterleitung zu untersuchen und Routingentscheidungen auf verschlüsselten Traffic anzuwenden. Eine Web Application Firewall kann HTTP-/HTTPS-Services zusätzlich gegen bestimmte Angriffsmuster schützen. Beides ersetzt jedoch keine sichere Anwendung und keine korrekte Autorisierung.

Die Edge sollte nur die für den jeweiligen Dienst vorgesehenen Backends erreichen können. Backend Cloaking verhindert, dass interne Zielstrukturen als öffentlicher Einstiegspunkt verwendet werden. Für die Weitergabe von Client- oder Verbindungsinformationen kann Proxy Protocol relevant sein, sofern die Backends es unterstützen und korrekt auswerten.

In einer verteilten Plattform müssen Routingregeln außerdem über mehrere Edge-Standorte konsistent wirken. Die ayedo Edge Cloud verbindet dafür L7-Loadbalancing mit eigener Netzwerk-Infrastruktur, eigenem Autonomous System, Anycast und einer Aktiv-Aktiv-Architektur. Das ist besonders relevant, wenn dieselben API-Regeln unabhängig von einem einzelnen Compute-Provider gelten sollen. Die Compute-Backends können dabei in ayedo Managed Kubernetes , eigenen Clustern oder Umgebungen anderer Provider betrieben werden.

Praxisszenario: Versionierte API mit getrennten Pools

Ein Unternehmen betreibt api.example.com mit den Pfaden /v1/orders und /v2/orders. Die ältere Version bleibt auf einem stabilen Backend-Pool, während die neue Version zunächst auf einen separat skalierbaren Pool zeigt. Ein Health Check prüft pro Pool einen passenden Endpunkt. Ein L4-Loadbalancer könnte beide Versionen nur gemeinsam über denselben Listener verteilen; die Trennung müsste anschließend in der Anwendung erfolgen.

Beim L7-Modell entscheidet die Edge anhand des HTTP-Pfads. Fällt der v2-Pool aus, kann die Plattform ihn aus dem Routing nehmen, ohne v1 zu beeinflussen. Ein automatisches Fallback auf v1 ist dagegen nur vertretbar, wenn die API-Verträge kompatibel sind. Andernfalls würde Routingverfügbarkeit auf Kosten fachlicher Korrektheit entstehen.

FAQ

Ist L7 Loadbalancing ein Ersatz für ein API-Gateway?

Nein. L7 Loadbalancing wählt primär den Backend-Pool. Ein API-Gateway kann zusätzlich Authentisierung, Quoten, Transformationen oder Richtlinien übernehmen.

Wann reicht L4-Loadbalancing aus?

Wenn alle Verbindungen gleich behandelt werden und die Anwendung selbst über weitere Verteilung entscheidet. Das ist oft einfacher, bietet aber weniger zentrale Steuerung nach HTTP-Merkmalen.

Müssen APIs für L7-Routing versionierte Pfade verwenden?

Nein. Auch Hostnames, Methoden oder Header können Kriterien sein. Versionierte Pfade sind jedoch meist besonders transparent und für Betrieb sowie Fehlersuche gut nachvollziehbar.

Fazit

L7 Loadbalancing macht den HTTP-Kontext zu einer Architekturentscheidung. Dadurch lassen sich API-Versionen, Dienste und Betriebszustände gezielt voneinander trennen, während L4 bei port- und verbindungsbasierter Verteilung einfacher bleibt. Die gewonnene Kontrolle verlangt jedoch klare Backend-Verträge, konsistente Regeln und aussagekräftiges Monitoring. Eine Edge-Plattform wie die ayedo Edge Cloud kann diese Entscheidungen providerunabhängig vor unterschiedlichen Compute-Umgebungen umsetzen und dabei Routing, Schutz und Erreichbarkeit an einem öffentlichen Eingang bündeln.