Kontext
Webanwendung mit Anwendungsserver, z. B. Ruby on Rails mit Puma. Wird in einem Container auf AWS ECS mit Fargate ausgeführt. Der Datenverkehr wird vom AWS Application Load Balancer direkt an den im Container ausgeführten Anwendungsserver weitergeleitet.
Frage
Ist zwischen ALB und der Anwendung selbst, also als Sidecar-Container, noch ein Reverse-Proxy erforderlich? Was wäre der Vorteil?
Antwort1
Ein Reverse-Proxy ist nicht erforderlich, aber die mit Rails gelieferten Webserver verfügen nur über eine minimale Funktionalität. Daher ist es für jede Anwendung, die öffentlich zugänglich ist und potenziell wachsen kann, eine gute Idee, frühzeitig einen Reverse-Proxy (z. B. Nginx) zu integrieren.
Dies würde Ihnen beispielsweise erweiterte Ratenbegrenzungsfunktionen, Caching und die Möglichkeit bieten, eine End-to-End-SSL-Terminierung mit viel weniger Aufwand durchzuführen als bei anderen Webserverimplementierungen. Auch die Protokollierung wird viel einfacher, und Dinge wie TCP-Wiederholungen können lebensrettend sein, wenn Ihre Anwendung überlastet ist.
Sie benötigen keinen Sidecar. Sie können Nginx auf derselben Maschine wie Ihre Anwendung installieren. Es ist äußerst effizient und hat keinen Einfluss auf die Leistung Ihrer Anwendung.
Wir verwenden mehrere Nginx-Proxys vor Rails und bedienen täglich Milliarden von HTTP-Anfragen.
Auch massive Reverse-Proxy-Implementierungen wie Cloudflare basieren auf Nginx.
Antwort2
Ein Load Balancer ist eine Art Reverse-Proxy. Er bietet unter anderem die Möglichkeit, Datenverkehr über bestimmte Ports zu akzeptieren, als eine Art Firewall zu fungieren und zu verhindern, dass bestimmte Arten von Angriffen den Server erreichen.
Im Normalfall einer Webanwendung sehe ich keinen nennenswerten Vorteil darin, sowohl einen Load Balancer als auch einen zweiten Reverse-Proxy zu haben.