Examinei muitas configurações de back-end no Amazon Web Services, especialmente no Instagram. Em seusBlog de engenharia do Instagrameles mencionaram como têm um Elastic Load Balancer na frente de seus três servidores NGINX, que fica na frente de seus servidores de aplicativos que executam Django/Gunicorn, por que isso (é para buffer? Armazenamento em cache?)
Se for esse o caso, como conectar esses servidores NGINX aos servidores de aplicativos Django/gunicorn?
Responder1
Olhando para a postagem do Instagram, não acredito que eles estejam usando o Nginx para buffer ou cache (embora eu possa estar errado). Eu uso algo semelhante, mas com HAProxy em vez de Nginx.
Algumas das razões pelas quais adotamos essa abordagem:
- Nginx e HAProxy operam na camada 7, enquanto o ELB é posterior à 4. Se você precisar de serviços da camada 7, o ELB não poderá fornecê-los
- Encerramento normal da conexão quando as verificações de integridade falham. O ELB pode continuar passando o tráfego para o HAProxy/Nginx enquanto o tráfego é eliminado da instância fora de serviço. Verhttps://forums.aws.amazon.com/message.jspa?messageID=231571
- Você pode expandir a camada de balanceamento de carga ao vivo, se necessário
- Melhores métricas sobre tráfego e desempenho de cada instância por trás da camada HAProxy/Nginx
- ELB pode detectar quando uma instância HAProxy falhou e parar de enviar tráfego para ela
Responder2
Alguns pontos em que consigo pensar:
- Ele distribui solicitações e monitora a integridade dos servidores, portanto, se um de seus servidores nginx travar, o site continuará funcionando perfeitamente.
- A Amazon faz alguma mitigação de negação de serviço. Se você mesmo cuidar do balanceamento de carga, pagará por todo o tráfego que os atinge. Se a Amazon bloquear alguns ataques direcionados ao seu ELB, você não pagará por essa parte.
- Permite bloquear os grupos de segurança dos servidores nginx apenas para o ELB, tornando-os mais seguros do que mantê-los abertos à Internet pública.