He analizado muchas configuraciones de back-end en los servicios web de Amazon, especialmente la de Instagram. En suBlog de ingeniería de Instagrammencionaron que tienen un Elastic Load Balancer frente a sus tres servidores NGINX, que está frente a sus servidores de aplicaciones que ejecutan django/Gunicorn, ¿por qué? (¿es para almacenamiento en búfer? ¿almacenamiento en caché?)
Si ese es el caso, ¿cómo se pueden conectar esos servidores NGINX a los servidores de aplicaciones django/gunicorn?
Respuesta1
Al mirar la publicación de Instagram, no creo que estén usando Nginx para el almacenamiento en búfer o en caché (aunque podría estar equivocado). Yo uso algo similar pero con HAProxy en lugar de Nginx.
Algunas de las razones por las que adoptamos este enfoque:
- Nginx y HAProxy operan en la capa 7, mientras que ELB es posterior a la 4. Si necesita servicios de capa 7, ELB no puede proporcionárselos.
- Terminación elegante de la conexión cuando fallan las comprobaciones de estado. El ELB puede continuar pasando tráfico a HAProxy/Nginx mientras el tráfico se elimina de la instancia fuera de servicio. Verhttps://forums.aws.amazon.com/message.jspa?messageID=231571
- Puede ampliar la capa de equilibrio de carga en vivo si es necesario
- Mejores métricas sobre el tráfico y el rendimiento de cada instancia detrás de la capa HAProxy/Nginx
- ELB puede detectar cuándo una instancia de HAProxy ha fallado y dejar de enviarle tráfico
Respuesta2
Algunos puntos que se me ocurren:
- Distribuye solicitudes y monitorea el estado de los servidores, por lo que si uno de sus servidores nginx falla, el sitio continúa funcionando sin problemas.
- Amazon mitiga un poco la denegación de servicio por su parte. Si maneja el equilibrio de carga usted mismo, pagará por todo el tráfico que les llegue. Si Amazon bloquea algunos ataques dirigidos a su ELB, no pagará por esa parte.
- Le permite bloquear los grupos de seguridad de los servidores nginx solo en el ELB, haciéndolos más seguros que tenerlos abiertos a la Internet pública.