ID de la causa in-cascade · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de red (Equipo de infraestructura)
Cuando un servicio se vuelve lento, los servidores que lo llaman se quedan bloqueados esperando su respuesta y hasta funciones sin relación se detienen.
Por qué Un servicio, como la BD o la autenticación, se vuelve lento → Efecto Los hilos y conexiones de los servidores que lo llaman quedan retenidos esperando respuesta, y los reintentos de las solicitudes fallidas suman carga → En pantalla Hasta funciones que parecen no tener relación se vuelven lentas o se detienen
Cuando se junta mucha gente, De vez en cuando, al azar
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de red (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Poner timeout a todas las llamadas, usar circuit breakers y aislamiento por función (bulkheads), reintentar con intervalos crecientes y un número limitado de veces, separar las respuestas de health check del trabajo pesado.
Tareas (Equipo de infraestructura)
Dar margen en el número de fallos y el intervalo de los health checks del balanceador de carga para que no saque de inmediato a un servidor que va lento un momento, limitar cuántos servidores pueden salir a la vez.
En el gráfico
Topa con el límite · Tiempo de respuesta y tasa de errores por servicio, hilos y conexiones en uso
Dónde mirar
Poner en una sola pantalla, con el eje de tiempo alineado, el tiempo de respuesta, la tasa de errores y los reintentos de cada servicio, y buscar cuál se volvió lento primero. Detrás de un balanceador de carga, tiempo de respuesta de los destinos (TargetResponseTime en AWS ALB), número de 5xx de los destinos (HTTPCode_Target_5XX_Count) y número de destinos retirados por no estar sanos (UnHealthyHostCount)
Se confirma si
Primero sube la latencia de un servicio; después, los hilos y conexiones en uso de quienes lo llaman tocan el límite, los errores se extienden a otros servicios y crecen a la vez los reintentos y los destinos retirados
Se descarta si
Si varios servicios se volvieron lentos en el mismo instante, revisar primero un fallo de un recurso compartido (BD, red, host)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Los health checks (comprobaciones de que un servidor sigue vivo) también agravan la cascada. Si un servidor ocupado responde tarde al health check, el balanceador de carga saca a un servidor que funciona bien, su tráfico se concentra en los que quedan y el siguiente también empieza a responder tarde.
Site Reliability Engineering, Chapter 22: Addressing Cascading FailuresGoogle Si un servidor sobrecargado falla el health check y sale, la carga se concentra en los que quedan y los reintentos la agravan; se recomienda limitar los reintentos, usar backoff exponencial aleatorio y fijar plazos (deadlines)
Circuit Breaker PatternMicrosoft Azure Las solicitudes bloqueadas hasta el timeout retienen hilos y conexiones a la BD y hacen fallar funciones sin relación; si se acumulan fallos en un tiempo dado, rechazar las llamadas de inmediato
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Con 5 niveles de llamadas y 3 reintentos en cada nivel, la carga sobre la BD se multiplica por 243; reintentar en un solo punto y limitarlo con un token bucket
CloudWatch metrics for your Application Load BalancerAWS TargetResponseTime (tiempo desde que la solicitud sale del balanceador de carga hasta que el destino empieza a responder), HTTPCode_Target_5XX_Count (número de 5xx generados por los destinos), UnHealthyHostCount (número de destinos no sanos)
Ver también
Misma capa: L13 Arquitectura y operación de servidores