Im August 2016 führte Amazon Web Services (AWS) den Application Load Balancer ein – für den Layer-7-Lastausgleich von HTTP- und HTTPS-Datenverkehr. Das neue Produkt ergänzte mehrere Funktionen, die dem bestehenden Layer-4- und Layer-7-Load-Balancer von AWS, dem Elastic Load Balancer, fehlten. Dieser wurde offiziell in Classic Load Balancer umbenannt.
Ein Jahr später führte AWS den Network Load Balancer ein und verbesserte damit den Lastenausgleich auf Layer 4. Für Benutzer, die hochverfügbare, skalierbare Anwendungen auf AWS ausführen, stehen somit folgende Optionen zur Auswahl:
- NGINX Open Source und NGINX Plus
- Klassischer Load Balancer
- Application Load Balancer (ALB)
- Netzwerk-Load-Balancer (NLB)
In diesem Beitrag betrachten wir die Funktionen von ALB und vergleichen dessen Preise und Funktionen mit NGINX Open Source und NGINX Plus.
Hinweise –
Die Informationen zu den unterstützten Funktionen entsprechen dem Stand von Juli 2020, können sich jedoch ändern. Einen direkten Vergleich zwischen NGINX Plus und Classic Load Balancer (ehemals Elastic Load Balancer oder ELB) sowie Informationen zu deren gemeinsamer Verwendung finden Sie in unserem früheren Blogbeitrag. Informationen zur Verwendung von NLB für eine hochverfügbare NGINX Plus-Bereitstellung finden Sie in unserem früheren Blogbeitrag.
Funktionen des Application Load Balancers
ALB ist wie der Classic Load Balancer oder NLB eng in AWS integriert. Amazon bezeichnet ihn als Layer-7-Load-Balancer – allerdings bietet er nicht den vollen Funktionsumfang, die Optimierungsmöglichkeiten und die direkte Kontrolle, die ein eigenständiger Layer-7-Reverse-Proxy und -Load-Balancer bieten kann.
ALB bietet die folgenden Funktionen, die beim Classic Load Balancer fehlen:
- Inhaltsbasiertes Routing. ALB unterstützt inhaltsbasiertes Routing auf Grundlage der Anfrage-URL, des
Host-Headers sowie von Feldern in der Anfrage, darunter standardmäßige und benutzerdefinierte HTTP-Header und -Methoden, Abfrageparameter und die Quell-IP-Adresse. (Siehe „Vorteile der Migration von einem Classic Load Balancer“ in der ALB-Dokumentation.) - Unterstützung für containerbasierte Anwendungen. ALB verbessert die bestehende Unterstützung für Container, die auf dem Amazon EC2 Container Service (ECS) gehostet werden.
- Mehr Metriken. Sie können Metriken für jeden einzelnen Microservice erfassen.
- WebSocket-Unterstützung. ALB unterstützt persistente TCP-Verbindungen zwischen einem Client und einem Server.
- HTTP/2-Unterstützung. ALB unterstützt HTTP/2, eine überlegene Alternative für die Bereitstellung von Inhalten, die durch SSL/TLS geschützt sind.
(Einen vollständigen Funktionsvergleich zwischen ALB und Classic Load Balancer finden Sie unter „Produktvergleiche“ in der AWS-Dokumentation.)
ALB war eine bedeutende Neuerung für AWS-Benutzer, die mit dem eingeschränkten Funktionsumfang des Classic Load Balancer zu kämpfen hatten, und erfüllte zumindest teilweise die Anforderungen anspruchsvoller Benutzer, die den Datenverkehr zu ihren Webanwendungen absichern, optimieren und steuern müssen. Dennoch bietet ALB nach wie vor nicht alle Funktionen dedizierter Reverse-Proxys (wie NGINX) und Load Balancer (wie NGINX Plus).
Ein besserer Ansatz zur Steuerung des Datenverkehrs auf AWS
Anstatt Amazon ALB zu verwenden, können Benutzer NGINX Open Source oder NGINX Plus auf AWS bereitstellen, um den Datenverkehr zu steuern und die Last zu verteilen. Sie können außerdem einen Classic Load Balancer oder Network Load Balancer als Frontend bereitstellen, um eine hohe Verfügbarkeit über mehrere Availability Zones hinweg zu erreichen. Die Tabelle vergleicht die von ALB, NGINX und NGINX Plus unterstützten Funktionen.
Hinweis: Die Angaben in der folgenden Tabelle entsprechen dem Stand von Juli 2020, können sich jedoch ändern.
| Amazon ALB | NGINX Open Source | NGINX Plus | |
|---|---|---|---|
| Load-Balancing- Methoden und -Funktionen | Methoden Round_robin und least_outstanding_requests mit Cookie-basierter Sitzungspersistenz, gewichteten Zielgruppen und langsamem Anlauf | Mehrere Load-Balancing-Methoden (darunter Round Robin, Least Connections, Hash, IP Hash und Random) mit gewichteten Upstream-Servern | Wie NGINX Open Source, zusätzlich die Methode Least Time, weitere Methoden zur Sitzungspersistenz und langsamer Anlauf |
| Caching | ❌ Caching im Load Balancer wird nicht unterstützt | ✅ Caching statischer Dateien und dynamisches Caching (von Anwendungen) | ✅ Statisches und dynamisches Caching sowie erweiterte Funktionen |
| Systemzustandsprüfungen | Aktiv (erkennt ausgefallene Server anhand des bei asynchronen Prüfungen zurückgegebenen Statuscodes) | Passiv (erkennt ausgefallene Server anhand der Antworten auf Clientanfragen) | Sowohl aktiv als auch passiv – aktive Prüfungen sind umfangreicher und flexibler konfigurierbar als bei ALB |
| Hochverfügbarkeit | ALB-Instanzen können für Hochverfügbarkeit in mehreren Availability Zones bereitgestellt werden, jedoch nicht regionsübergreifend | Aktiv-Aktiv-Hochverfügbarkeit mit NLB und Aktiv-Passiv-Hochverfügbarkeit mit Elastic-IP-Adressen | Wie NGINX Open Source, zusätzlich integrierte Freigabe des Clusterzustands für nahtlose Hochverfügbarkeit über alle NGINX Plus-Instanzen hinweg |
| Unterstützung aller Protokolle der IP-Protokollfamilie | ❌ Nur HTTP und HTTPS | ✅ Auch TCP und UDP, mit passiven Systemzustandsprüfungen | ✅ Auch TCP und UDP, mit aktiven und passiven Systemzustandsprüfungen |
| Mehrere Anwendungen pro Load-Balancer-Instanz | ✅ | ✅ | |
| Inhaltsbasiertes Routing | ✅ Basierend auf Anfrage-URL, Host-Header und Anfragefeldern, darunter standardmäßige und benutzerdefinierte HTTP-Header, Methoden, Abfrageparameter und Quell-IP-Adresse | ✅ Basierend auf denselben Faktoren wie ALB, zusätzlich Cookies und dynamische Berechnungen mit dem NGINX-JavaScript-Modul als eingebetteter JavaScript-Engine | ✅ Basierend auf denselben Faktoren wie NGINX Open Source, zusätzlich JWT-Claims und Werte im Schlüssel-Wert-Speicher |
| Containerisierte Anwendungen | Kann den Datenverkehr auf Amazon-IDs, ECS-Containerinstanzen, Auto-Scaling-Gruppen und AWS-Lambda-Funktionen verteilen | Erfordert eine manuelle Konfiguration oder Konfigurationsvorlagen | Automatisierte Konfiguration über DNS, einschließlich SRV-Einträgen; kompatibel mit führenden Registry-Diensten |
| Portabilität | ❌ Alle Umgebungen (Entwicklung, Test und Produktion) müssen sich auf AWS befinden | ✅ Jede Umgebung kann auf einer beliebigen Bereitstellungsplattform ausgeführt werden | |
| SSL/TLS | ✅ Mehrere SSL/TLS-Zertifikate mit SNI-Unterstützung ❌ Validierung von SSL/TLS-Upstreams wird nicht unterstützt | ✅ Mehrere SSL/TLS-Zertifikate mit SNI-Unterstützung ✅ Freie Auswahl an SSL/TLS-Chiffren ✅ Vollständige Validierung von SSL/TLS-Upstreams | |
| HTTP/2 und WebSocket | ✅ | ✅ | |
| Authentifizierungsfunktionen | – Authentifizierungsoptionen für OIDC, SAML, LDAP und AD IdP – In AWS Cognito und CloudFront integriert | Mehrere Authentifizierungsoptionen | |
| Erweiterte Funktionen | ❌ Rudimentäre API | ✅ Bereitstellung von Ursprungsinhalten, Priorisierung, Ratenbegrenzung und mehr | ✅ Wie NGINX Open Source, zusätzlich RESTful API und Schlüssel-Wert-Speicher |
| Protokollierung und Debugging | ✅ Binäres Amazon-Protokollformat | ✅ Anpassbare Protokolldateien und mehrere Debugging-Schnittstellen | ✅ Vollständig anpassbare Protokolldateien und mehrere Debugging-Schnittstellen, mit umfassendem Support durch NGINX |
| Monitoring-Tools | ✅ In Amazon CloudWatch integriert | ✅ NGINX Controller* und weitere Tools von Drittanbietern | ✅ NGINX Controller und weitere Tools von Drittanbietern; erweiterter Umfang gemeldeter Statistiken |
| Offizieller technischer Support | ✅ Gegen Aufpreis | ❌ Nur Community-Support | ✅ Im Preis inbegriffen und direkt von NGINX |
| Kostenloses Kontingent | ✅ Die ersten 750 Stunden | ✅ Dauerhaft kostenlos | ✅ 30-tägiges Testabonnement |
* NGINX Controller heißt jetzt F5 NGINX Management Suite.
Natürlich sollten Sie Ihre Wahl der Load-Balancing-Lösung nicht anhand einer Funktionscheckliste bewerten, sondern danach, ob sie die erforderlichen Funktionen bietet, um Ihre Anwendungen reibungslos, mit hoher Sicherheit, maximaler Verfügbarkeit und vollständiger Kontrolle bereitzustellen.
Bewältigung von Lastspitzen
Amazons Classic Load Balancer (ehemals ELB) reagierte nur unzureichend auf Lastspitzen. Die Größe der Load-Balancer-Instanzen wurde automatisch an das aktuelle Datenverkehrsaufkommen angepasst. Bei Lastspitzen konnte es jedoch mehrere Minuten dauern, bis ELB reagierte und zusätzliche Kapazitäten bereitstellte. Benutzer mussten daher vor erwarteten Lastspitzen zusätzliche Ressourcen über einen manuellen, formularbasierten Prozess anfordern (das sogenannte „Pre-Warming“). Da ALB auf NGINX basiert, können ALB-Instanzen ein wesentlich höheres Datenverkehrsaufkommen bewältigen. Dennoch kann es bei Lastspitzen weiterhin zu Skalierungsvorgängen kommen. Darüber hinaus führt eine Lastspitze automatisch zu einem höheren Verbrauch von Load Balancer Capacity Units (LCUs) und damit zu höheren Kosten.
Sie erhalten die vollständige Kontrolle über Kapazität und Kosten, wenn Sie Ihre Load-Balancing-Proxys selbst bereitstellen und skalieren. NGINX und NGINX Plus werden auf standardmäßigen Amazon-Instanzen bereitgestellt. Unser Leitfaden zur Dimensionierung gibt Aufschluss über die potenzielle Spitzenleistung von Instanztypen mit unterschiedlichen Kapazitäten. Die Preise für NGINX Plus sind für alle Instanzgrößen gleich. Daher ist es kosteneffizient, zusätzliche Kapazitäten zur Bewältigung von Lastspitzen bereitzustellen. Wenn mehr Kapazität benötigt wird, lassen sich zudem schnell weitere Instanzen bereitstellen – ganz ohne Formulare.
Ausgefallene Server mit Zustandsprüfungen erkennen
Unsere Tests von Amazon ALB deuten darauf hin, dass es keine „passiven“ Zustandsprüfungen durchführt. Der Ausfall eines Servers wird erst erkannt, wenn ein asynchroner Test bestätigt, dass der Server nicht den erwarteten Statuscode zurückgibt.
Wir fanden dies heraus, indem wir eine ALB-Instanz erstellten, um die Last auf einen Cluster von Instanzen zu verteilen. Wir konfigurierten eine Zustandsprüfung mit dem Mindestintervall von 5 Sekunden und dem Mindestschwellenwert von 2 fehlgeschlagenen Prüfungen und sendeten kontinuierlich Anfragen an den ALB. Als wir eine der Instanzen stoppten, gab der ALB bei einigen Anfragen mehrere Sekunden lang den Fehler 502 Bad Gateway zurück, bis die Zustandsprüfung erkannte, dass die Instanz ausgefallen war. Passive Zustandsprüfungen (die sowohl von NGINX als auch von NGINX Plus unterstützt werden) verhindern, dass Endbenutzer solche Fehler sehen.
Die Zustandsprüfungen von ALB können den Zustand einer Instanz nur anhand des HTTP-Statuscodes ermitteln (z. B. 200 OK oder 404 Not Found). Solche Zustandsprüfungen sind unzuverlässig. Einige Webanwendungen ersetzen beispielsweise vom Server erzeugte Fehlermeldungen durch benutzerfreundliche Seiten, und manche Fehler werden nur im Inhalt einer Webseite gemeldet.
NGINX Plus unterstützt sowohl passive als auch aktive Zustandsprüfungen, wobei Letztere leistungsfähiger als die von ALB sind, da sie sowohl den Inhalt einer Antwort als auch den Statuscode abgleichen können.
Preisgestaltung
Letztendlich sind die Kosten die wichtigste Frage, mit der Sie sich bei der Bereitstellung von ALB auseinandersetzen müssen. Der Lastenausgleich kann einen erheblichen Teil Ihrer Amazon-Rechnung ausmachen.
AWS verwendet einen komplizierten Algorithmus zur Preisberechnung. Wenn Sie nicht genau wissen, wie viele neue und gleichzeitige Verbindungen Sie haben werden und wie viele Daten Sie jeden Monat verarbeiten werden – was nur sehr schwer vorherzusagen ist – und die LCU-Berechnung nicht genauso wie Amazon durchführen können, werden Sie Ihrer monatlichen Amazon-Rechnung mit Sorge entgegensehen.
NGINX Plus auf AWS bietet Ihnen vollständige Kostenplanbarkeit. Für einen festen Stundentarif zuzüglich der AWS-Hostinggebühren erhalten Sie eine deutlich leistungsfähigere Load-Balancing-Lösung mit umfassendem Support.
Fazit
NGINX Plus ist eine bewährte Lösung für den Lastenausgleich auf Layer 7 und bietet zudem Funktionen für den Lastenausgleich auf Layer 4. Es lässt sich gut mit Amazons eigenem Classic Load Balancer oder NLB kombinieren.
Wir begrüßen den anhaltenden und zunehmenden Einsatz von NGINX und NGINX Plus in der AWS-Umgebung, wo sie bereits sehr beliebt sind. Wenn Sie NGINX Plus noch nicht nutzen, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.