504s na implementação do aplicativo Elastic Beanstalk (usuário - ELB - Elastic Beanstalk mod_wsgi)

Question

Eu tenho um aplicativo de carga balanceada do Python Elastic Beanstalk. Aqui está o caminho que uma solicitação do usuário segue até o aplicativo Elastic Beanstalk:

user -> Elastic Beanstalk ELB -> Elastic Beanstalk mod_wsgi

O problema:

As primeiras solicitações de ~ 2-4 de user após eb deploy de uma nova versão do aplicativo gerarão 504 erros do ELB.

Após estes pedidos de ~ 2-4 que geram 504s, está tudo bem! 200 em todo o lado.

Quando os 504s acontecem, zero solicitações chegam ao Elastic Beanstalk mod_wsgi app de acordo com /var/httpd/access_log . Eu só vejo os anos 200 depois que o ELB decidiu começar a trabalhar novamente.

Coisas que tentei que não funcionaram:

1. Eu aumentei o tempo limite ocioso de Elastic Beanstalk ELB para 300 segundos
2. Eu aumentei o Elastic Beanstalk mod_wsgi apache KeepAliveTimeout para 300 segundos como sugerido aqui: link

Alguém poderia dizer: "viva com os 504s!"

No entanto, o problema real é que na minha configuração de produção, tenho CloudFlare entre user e Elastic Beanstalk ELB . O CloudFlare está configurado para armazenar de forma agressiva os arquivos .css e .js , já que eu incluo hashes md5 em URLs de arquivos estáticos. Quando as solicitações desses arquivos importantes falham com o 504, o CloudFlare parece armazenar essas falhas como sendo 404s. Mais pedidos para estes arquivos 404, quebrando assim o estilo visual do site em cada implantação.

A implantação do aplicativo Elastic Beanstalk novamente com a mesma versão do aplicativo corrigirá o problema do CloudFlare 404. Esta não é uma ótima solução. Eu quero continuar usando CloudFlare porque faz um excelente CDN transparente, então livrar-se dele também não é uma solução.

É difícil acreditar que estou sozinho com esse problema, mas o Google, o stackoverflow / serverfault e os fóruns da AWS não produziram nenhuma solução ou relatórios de problemas semelhantes. Espero que minha descrição desse comportamento chame a atenção de alguém aqui. Agradecemos antecipadamente.

    

Answer 1

Eu tive exatamente o mesmo problema que realmente acho que é um bug com o implementador do Beanstalk.

Eu estava usando uma política de implantação "Rolling" com 2 instâncias e tamanho de lote 1, o que deve resultar em tempo de inatividade zero na teoria. No entanto, na realidade, durante uma implantação ainda há um período de cerca de 10 - 15 segundos, onde o ELB responde com 504.

Dê uma olhada nas configurações de "Atualização e Implantação" na configuração do seu beanstalk. Descobri que mudar para "Rolando com lote adicional" e usar um tamanho de lote de 100% funciona bem e oferece tempo de inatividade zero durante uma atualização.

Atualização de outubro de 2018 - Não sei há quanto tempo está funcionando, mas as atualizações de rolagem do Elastic Beanstalk agora funcionam corretamente novamente sem tempo de inatividade para mim.