nginx - der reverse Proxy

Von: Valentin Brückel
Datum: 26. Mai 2021

1. Architektur

Zunächst wurde Nginx als reiner Webserver entwickelt mit dem Ziel, Webseiten mit viel Traffic schneller und ressourcenschonender auszuliefern, als es mit dem damals weit verbreiteten Apache Webserver möglich war. Während Apache für jede Verbindung einen eigenen Prozess nutzte, setzt Nginx auf einen Prozess pro CPU, der eine Vielzahl von Verbindungen in einer Event-basierten Architektur bearbeitet.

Dieses Prozess-Modell minimiert den Overhead durch Prozess- oder Thread-Wechsel und skaliert automatisch mit zusätzlicher oder leistungsfähigerer Hardware. Die Event-gestützte Verarbeitung führt dazu, dass Verbindungen nur dann Prozessorleistung benötigen, wenn tatsächlich Aufgaben zu erledigen sind. Wartezeiten auf I/O oder Netzwerk-Ressourcen können zur Behandlung anderer Verbindungen genutzt werden. Diese Eigenschaft macht Nginx zu einem effizienten Proxy-Server.

Die Verwendung als Proxy-Server entwickelte sich zum Alleinstellungsmerkmal, das Nginx zu schneller Verbreitung verhalf, oft auch als Reverse Proxy vor Apache Webservern.

Auch nach fast 20 Jahren ist diese Architektur noch Stand der Technik. Die Performance von Nginx kann sich bis heute mit den Konkurrenzprodukten messen lassen, selbst wenn diese um einiges jünger sind.

1.1. Event-basiertes Prozessmodell

Bei der klassischen Prozess-Architektur belegt eine Verbindung einen Prozess so lange, bis die Anfrage beantwortet ist. Um Wartezeiten zu verkürzen, werden weitere Prozesse benötigt. Zudem ist schnelles I/O und effizientes Caching wichtig für die Systemleistung.

Abbildung : Klassische Prozess-Architektur

In der Event-basierten Prozess-Architektur resultiert eine Anfrage in mehreren Ereignissen. Ereignisse mehrerer Verbindungen können verschachtelt werden. Der Prozess ist ausgelastet, der Durchsatz steigt.

Abbildung : Event-basierte Prozess-Architektur

2. Konfiguration

Eine Installation von Nginx ist auf gängigen Plattformen nativ oder als Container möglich. Die Konfiguration wurde in bewusstem Gegensatz zum damals dominierenden Apache Webserver rein statisch ausgelegt, sie erfolgt durch Konfigurationsdateien, die Nginx beim Start verarbeitet. Anpassungen zur Laufzeit über Mechanismen wie .htaccess-Dateien sind nicht vorgesehen.

Die Konfigurationsdateien folgen einem einfachen Schema, das für jeden Host-Namen einen server-Block definiert, innerhalb dessen Regeln für Pfade auf diesem Host angegeben sind, die der Reihe nach geprüft werden.

server {
	listen 80;
	server_name api.predic8.de;

	location / {
		proxy_pass http://server7.predic8.de/
	}
}

server {
	listen 80;
	server_name predic8.de;

	location /grafana/ {  # Match auf predic8.de/grafana und alle Pfade darunter
		proxy_pass http://localhost:3000/;
	}

	location / {  # Match auf alle anderen Pfade
		root /usr/share/nginx/html;  # liefert statische Webseite aus dem Dateisystem
		index index.html;
	}
}
				

3. Vorteile

Als Open-Source-Projekt, das seit fast 20 Jahren millionenfach im Einsatz ist, kann Nginx als vollständig analysiert und optimiert betrachtet werden. Es gibt nur wenige Programme, die noch schärfer auf Sicherheitslücken und Performance-Probleme untersucht wurden.

Für viele Anwendungen, die einen einfachen Proxy oder Webserver benötigen, ist Nginx die erste Wahl. Ein einmal konfigurierter Nginx wird seinen Dienst mit minimalem Wartungsaufwand zuverlässig und unauffällig verrichten. Zudem ist er leistungsfähig genug, dass Umgebungskomponenten sehr wahrscheinlich früher an ihre Lastgrenze geraten werden als Nginx.

4. Nachteile

Die Architektur von Nginx ist auf Performance und Stabilität optimiert. Die Entwicklung von Modulen und Erweiterungen ist dadurch deutlich anspruchsvoller als beispielsweise für den Apache-Server. Entsprechend gibt es verhältnismäßig wenig Möglichkeiten, Nginx über seine Kernfunktionen hinaus anzupassen.

Als Schwachpunkt kann sich in komplexeren Umgebungen die Konfiguration über Dateien erweisen. Werden in einem Netzwerk mehrere Nginx-Instanzen eingesetzt und ändert sich die Konfiguration häufig, dann kann der Verwaltungsaufwand zum Verteilen und Anwenden der Konfigurationsdateien eine relevante Größe werden.

5. Produkte auf Basis von Nginx

Seine Leistungsfähigkeit und Zuverlässigkeit machen Nginx zu einer beliebten Basiskomponente für Produkte, die im weiteren Sinne mit dem Netzwerk oder seiner Konfiguration arbeiten.

5.1. OpenResty®

OpenResty® erlaubt es, in nginx-Konfigurationsdateien Lua-Scripte zu integrieren und verwandelt den Proxy und Webserver so zu einem Application-Server. Durch die Just-In-Time-Kompilierung mit LuaJIT können die Performance-Auswirkungen der Skripte minimiert werden.

5.2. API-Gateways

Aus technischer Sicht sind (Reverse) Proxy-Server und API-Gateways sehr ähnlich. Prinzipiell kann auch ein manuell konfigurierter Nginx als API-Gateway betrachtet werden. Eine Reihe von spezialisierten API-Gateway-Produkten wie Kong oder 3scale erweitern Nginx auf Basis von OpenResty® um automatisierte Konfigurationsmechanismen mit benutzerfreundlichen Oberflächen.

5.3. Kubernetes Ingress

Für die Orchestrierungsplattform Kubernetes haben die Netzwerkverbindungen von außen und zwischen den Diensten Kontrollfunktionen, die bei monolithischen Programmen Teil der Programmlogik sind. Zur Kontrolle der Netzwerkverbindungen werden Proxy-Server eingesetzt. Nginx oder davon abgeleitete Produkte können diese Funktion als Ingress Controller übernehmen und werden in vielen Dokumentationen und Anleitungen als Standard verwendet.

6. Fazit

Nginx ist für viele Proxy-Aufgabenstellungen die erste Wahl. Die fast 20 Jahre alte Architektur war damals revolutionär und skaliert bis heute effizient mit steigenden Anforderungen und leistungsfähigerer Hardware. Für erfahrene Administratoren ist ein Nginx in kürzester Zeit aufgesetzt und konfiguriert. Beim Einsatz als API-Gateway und in Cloud-Umgebungen können allerdings häufige Konfigurationsänderungen notwendig werden, die über APIs konfigurierbare Produkte wie Envoy attraktiv machen können.

7. Links

• Offizielle Seite
• Github