ID da causa in-cascade · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
Quando um serviço fica lento, os servidores que o chamam ficam presos esperando a resposta, e até funções sem relação com ele param.
Por quê Um serviço, como o BD ou a autenticação, fica lento → Efeito As threads e conexões dos servidores que o chamam ficam presas esperando, e os retries das requisições que falharam aumentam a carga → Na tela Até funções que parecem não ter relação ficam lentas ou param
Quando junta muita gente, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Timeout em todas as chamadas, circuit breaker, isolamento por função (bulkhead), retries com intervalo crescente e número limitado, resposta do health check separada do trabalho pesado.
O que fazer (Equipe de infraestrutura)
Dar folga no número de falhas e no intervalo do health check do load balancer para que um servidor lento por um instante não seja retirado na hora, limitar quantos servidores podem sair de uma vez.
No gráfico
Achata ao bater no limite · Tempo de resposta e taxa de erros por serviço, threads e conexões em uso
Onde olhar
Tempo de resposta, taxa de erros e número de retries de cada serviço na mesma tela, com o eixo de tempo alinhado, para achar o primeiro que ficou lento. Atrás de um load balancer: tempo de resposta dos destinos (no AWS ALB, TargetResponseTime), número de 5xx dos destinos (HTTPCode_Target_5XX_Count) e número de destinos retirados por não estarem íntegros (UnHealthyHostCount)
Confirma se
A latência de um serviço sobe primeiro, depois as threads e conexões de quem o chama encostam no limite, os erros se espalham para outros serviços, e o número de retries e de destinos retirados sobe junto
Descarta se
Vários serviços ficaram lentos no mesmo instante: verificar primeiro falha em recurso compartilhado (BD, rede, host)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O health check (verificação de que o servidor está vivo) também amplia a cascata. Quando um servidor ocupado responde tarde à verificação, o load balancer retira um servidor que estava funcionando, o tráfego dele vai para os que sobraram, e o próximo servidor também começa a atrasar.
Site Reliability Engineering, Chapter 22: Addressing Cascading FailuresGoogle Quando um servidor sobrecarregado falha no health check e sai, a carga se concentra nos que sobram e os retries aumentam a carga; recomenda-se limitar os retries, usar backoff exponencial com jitter e deadlines
Circuit Breaker PatternMicrosoft Azure Requisições presas até o timeout ocupam threads e conexões com o BD e derrubam funções sem relação; quando as falhas se acumulam dentro de um tempo definido, as chamadas passam a ser recusadas na hora
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Com 5 níveis de chamadas e 3 retries em cada nível, a carga no BD é multiplicada por 243; fazer retry em um só lugar e limitar com token bucket
CloudWatch metrics for your Application Load BalancerAWS TargetResponseTime (tempo entre a requisição sair do load balancer e o destino começar a responder), HTTPCode_Target_5XX_Count (número de 5xx gerados pelos destinos), UnHealthyHostCount (número de destinos não íntegros)
Veja também
Mesma camada: L13 Arquitetura e operação de servidores