Uma empresa executa um aplicativo em instâncias EC2 em um grupo do Auto Scaling atrás de um Application Load Balancer (ALB). Na inicialização, as instâncias executam scripts de dados do usuário para baixar conteúdo crítico do aplicativo de um bucket S3. As instâncias são iniciadas, mas, depois de algum tempo, são encerradas com a mensagem: “An instance was taken out of service in response to an ELB system health check failure.” O Auto Scaling inicia e encerra instâncias repetidamente em um loop. A única alteração recente foi a adição de uma grande quantidade de conteúdo crítico ao bucket S3. A empresa não quer modificar os scripts de dados do usuário em produção. O que um arquiteto de soluções deve fazer para que o ambiente de produção possa ser implantado com sucesso?

Aumentar o período de carência do health check do grupo do Auto Scaling é a solução correta. Este período define quanto tempo o Auto Scaling deve esperar após uma instância ser iniciada antes de começar a verificar sua saúde. Como o novo conteúdo no S3 aumentou o tempo de inicialização do aplicativo, as instâncias estão sendo encerradas pelo ALB antes de estarem prontas para responder às verificações de saúde. Estender o período de carência dá tempo suficiente para que o script de dados do usuário seja concluído e o aplicativo inicie completamente. Aumentar o tamanho das instâncias EC2 pode não resolver o problema se o gargalo for o tempo de download e processamento do conteúdo. Aumentar o tempo limite do health check do ALB não é suficiente, pois o problema é que a instância ainda não está pronta para responder, não que a resposta esteja lenta. Alterar o caminho do health check do ALB para um URL diferente não aborda a causa raiz do problema, que é o tempo de inicialização prolongado.