Timeouts, reintentos, circuit breakers, bulkheads y degradación elegante

El fallo es normal; propagarlo es opcional

En un sistema distribuido siempre hay alguna dependencia lenta o fallando: un proveedor de pagos tiene un mal minuto, una base de datos hace failover, un enlace de red pierde paquetes, un despliegue sale mal. La Sección 6.1 mostró por qué estos fallos parciales no se pueden evitar y por qué a menudo quien llama ni siquiera puede saber qué ha ocurrido. Por tanto, la pregunta arquitectónica no es cómo evitar el fallo, sino cómo impedir que un fallo local se convierta en uno global. Un fallo en cascada es la forma típica en que mueren los sistemas: una dependencia lenta vuelve lentos a quienes la llaman, sus recursos se llenan de solicitudes en espera, ellos a su vez se vuelven lentos para quienes los llaman, y en cuestión de segundos un problema en un componente menor ha tumbado toda la plataforma.

Michael Nygard catalogó los patrones que interrumpen estas cadenas en Release It! (2007; segunda edición, 2018), a partir de las caídas que había investigado. Su observación central es que los puntos de integración, todos los lugares en que un sistema llama a otro, son la principal fuente de inestabilidad, y que cada uno necesita una protección deliberada. Los patrones de esta sección (timeouts, plazos, reintentos con backoff, circuit breakers (disyuntores), bulkheads (mamparos), alternativas, idempotencia y solicitudes de cobertura) son el conjunto de herramientas estándar. Son tácticas en el sentido de la Sección 2.5: cada una es una única decisión orientada a la disponibilidad, y cada una tiene un costo.

Timeouts: el primer patrón y el más importante

Un timeout limita cuánto tiempo espera quien llama. Sin él, una llamada a una dependencia que nunca responde retiene un hilo, una conexión y memoria mientras el sistema operativo mantenga abierta la conexión, lo que pueden ser muchos minutos. Muchas bibliotecas cliente no tienen timeout por defecto (la popular biblioteca requests de Python espera indefinidamente salvo que se le indique lo contrario), así que la ausencia de un timeout es una decisión de diseño tomada por omisión. El ejemplo práctico de más abajo muestra la consecuencia.

Normalmente importan dos timeouts. El timeout de conexión limita el establecimiento de una conexión y puede ser corto, unos cientos de milisegundos dentro de un centro de datos, porque un servidor sano acepta conexiones casi de inmediato. El timeout de solicitud limita todo el intercambio y debe salir de la medición: un poco por encima de la latencia de percentil alto de la dependencia (p99 o p99.9) con carga normal, para que corte las esperas patológicas sin hacer fallar las solicitudes lentas corrientes. También debe caber dentro del presupuesto de quien llama. Si el gateway se rinde a los 2 segundos pero el servicio de pedidos espera 10 segundos al de precios, el servicio de pedidos sigue trabajando durante 8 segundos en una solicitud que nadie está esperando. Por tanto, los timeouts deben acortarse a medida que se baja por una cadena de llamadas, que es la idea en la que se basan los plazos.

Los plazos y su propagación

Un plazo (deadline) es un momento absoluto en el tiempo para el que debe haber terminado toda la solicitud. La propagación de plazos (deadline propagation) pasa el tiempo restante a cada llamada posterior, para que cada servicio sepa cuánto presupuesto queda en lugar de aplicar un timeout fijo propio. gRPC lo incorpora: un cliente fija un plazo, el tiempo restante viaja con la llamada, y un servidor puede comprobar si el plazo ha vencido y detener el trabajo. Sobre HTTP, los equipos propagan una cabecera con los milisegundos restantes o con el plazo absoluto, idealmente mediante el mismo middleware que propaga el contexto de trazado (Sección 9.6).

La propagación aporta dos beneficios. Un servicio puede fallar rápido cuando el tiempo que queda es claramente demasiado corto para el trabajo, en lugar de iniciar una consulta a la base de datos que no puede terminar a tiempo. Y cuando el usuario se rinde, el trabajo de los niveles inferiores también se detiene, en lugar de seguir consumiendo capacidad justo durante la sobrecarga que causó el retraso. Esto es descarte de carga de solicitudes muertas, una de las protecciones más eficaces que puede tener un sistema sometido a estrés.

Reintentos con backoff exponencial y jitter

Muchos fallos son transitorios: un paquete perdido, una conexión reiniciada durante un failover, un breve 503 de una instancia sobrecargada. Reintentar los convierte en éxitos que el usuario nunca ve. Pero los reintentos también son carga, y los reintentos mal diseñados están entre las causas más comunes de las caídas. Cuatro reglas los hacen seguros. Reintenta solo los errores transitorios (timeouts, fallos de conexión, 502, 503, 504, y 429 después del retraso indicado), nunca errores que se repetirán, como 400 o 404. Reintenta solo operaciones idempotentes o que lleven una clave de idempotencia, porque una solicitud que agotó su timeout puede haber tenido éxito. Reintenta un número pequeño de veces, normalmente dos o tres. Y espera entre intentos, con backoff exponencial: un retraso que se duplica en cada intento, hasta un tope.

El backoff por sí solo no basta. Si mil clientes fallan en el mismo momento, como ocurre cuando una dependencia tiene un fallo momentáneo, todos reintentan al cabo de 100 ms, después todos al cabo de 200 ms, y llegan en oleadas sincronizadas que pueden mantener caída la dependencia. El artículo de Marc Brooker Exponential Backoff And Jitter (AWS Architecture Blog, 2015) lo simuló y mostró que añadir aleatoriedad, jitter (fluctuación aleatoria), reduce mucho tanto el trabajo total como el tiempo hasta completarlo. Su jitter completo (full jitter) recomendado espera un tiempo aleatorio entre cero y la cota exponencial: sleep = random(0, min(cap, base × 2attempt)). El jitter debe aplicarse a todo lo que muchos clientes hacen a la vez: reintentos, reconexiones, tiempos de caducidad de la caché y trabajos programados.

import random, time

class TransientError(Exception):
    """Timeouts, connection resets, 502, 503 and 504 responses."""

def call_with_retries(fn, attempts=3, base=0.1, cap=2.0):
    for attempt in range(attempts):
        try:
            return fn()
        except TransientError:
            if attempt == attempts - 1:
                raise                      # give up: let the caller decide
            ceiling = min(cap, base * 2 ** attempt)
            time.sleep(random.uniform(0, ceiling))   # full jitter

Tormentas de reintentos y presupuestos de reintentos

Los reintentos se multiplican entre capas. Supón que un toque en la app móvil pasa por el API gateway, el servicio de pedidos y el cliente de pagos, y que cada uno de los tres hace hasta tres intentos. Si el proveedor de pagos está caído, una sola acción del usuario produce 3 × 3 × 3 = 27 llamadas a él, y una caída que debería haber supuesto una tasa de errores constante se convierte en una tormenta de reintentos de 27 veces la carga normal, que mantiene caído al proveedor incluso después de corregida la causa original. Los usuarios que vuelven a tocar añaden una cuarta capa.

Tres defensas funcionan juntas. Primera, reintenta en una sola capa, normalmente la más cercana a la dependencia que falla, y haz que las demás capas pasen el error hacia arriba; el libro de SRE de Google recomienda que un servidor sobrecargado lo diga explícitamente, para que los llamantes de niveles superiores no reintenten. Segunda, usa un presupuesto de reintentos: el libro de SRE describe permitir reintentos solo mientras estén por debajo del 10% de las solicitudes de un cliente, lo que limita la carga adicional de los reintentos a unas 1.1 veces la normal en lugar de hasta tres veces. Los SDK de AWS implementan una cuota similar de tokens de reintento, y la política de reintentos de gRPC incluye una limitación (throttling) con el mismo fin. Tercera, combina los reintentos con un circuit breaker, para que no se reintente en absoluto una dependencia de la que se sabe que está caída.

Circuit breakers

Un circuit breaker, llamado así por Nygard en referencia al dispositivo eléctrico (el disyuntor), envuelve las llamadas a una dependencia y vigila sus resultados. Mientras la dependencia está sana, el breaker está cerrado (closed) y las llamadas pasan, mientras se cuentan los fallos y los timeouts. Cuando los fallos superan un umbral, por ejemplo la mitad de las 20 últimas llamadas, el breaker se abre (open): durante un periodo determinado todas las llamadas fallan de inmediato sin tocar la red, lo que protege los hilos de quien llama y da margen a la dependencia para recuperarse. Cuando vence el periodo, el breaker pasa a semiabierto (half-open) y deja pasar unas pocas llamadas de prueba. Si tienen éxito, se cierra; si una falla, vuelve a abrirse durante otro periodo. La descripción de Martin Fowler de 2014 dio a conocer ampliamente el patrón, y la biblioteca Hystrix de Netflix (ahora en modo de mantenimiento) lo popularizó en los microservicios; Resilience4j para Java y Polly para .NET son hoy las bibliotecas habituales, y las service meshes ofrecen protecciones relacionadas, como límites de concurrencia y detección de valores atípicos (outlier detection) (en Envoy se llaman circuit breaking, aunque funcionan de otra manera).

Los ajustes merecen reflexión. ¿Qué cuenta como fallo? Los timeouts y las respuestas 5xx, sí; las respuestas 4xx normalmente no, porque reflejan la solicitud de quien llama y no la salud de la dependencia. Los éxitos lentos también pueden contar, para que una dependencia que responde en 5 segundos se trate como fallida. La ventana debe ser lo bastante grande para no dispararse por un par de llamadas desafortunadas (las bibliotecas exigen un número mínimo de llamadas), y el periodo abierto lo bastante largo para la recuperación pero lo bastante corto para no prolongar una caída. Los breakers deben ser por dependencia, y a veces por endpoint, para que un endpoint de informes que falla no corte los pedidos. Los reintentos deben tratar un breaker abierto como una respuesta definitiva y no como algo que reintentar. Y cada cambio de estado debe registrarse y representarse en gráficos, porque un breaker abierto es un síntoma que alguien necesita ver.

import time

class CircuitOpen(Exception):
    pass

class CircuitBreaker:
    def __init__(self, failure_threshold=5, reset_after=30.0):
        self.failure_threshold = failure_threshold  # failures in a row that trip it
        self.reset_after = reset_after              # seconds to stay open
        self.failures, self.state, self.opened_at = 0, "closed", 0.0

    def call(self, fn, *args, **kwargs):
        if self.state == "open":
            if time.monotonic() - self.opened_at < self.reset_after:
                raise CircuitOpen("failing fast")   # no remote call at all
            self.state = "half-open"                # let a trial call through
        try:
            result = fn(*args, **kwargs)
        except Exception:
            self.failures += 1
            if self.state == "half-open" or self.failures >= self.failure_threshold:
                self.state, self.opened_at = "open", time.monotonic()
            raise
        self.failures, self.state = 0, "closed"    # success closes the circuit
        return result

payments = CircuitBreaker()
# payments.call(provider.authorise, order_id, amount, timeout=2.0)

Bulkheads

El casco de un barco está dividido por mamparos (bulkheads) en compartimentos estancos, para que una vía de agua inunde un compartimento en lugar de hundir el barco. En software, un bulkhead reparte los recursos para que una parte que falla o está sobrecargada no pueda consumirlo todo. La forma más común da a cada dependencia su propio pool de hilos, pool de conexiones o semáforo acotado: los pagos pueden usar como máximo 40 llamadas concurrentes por instancia, las consultas de restaurantes 40 y la asignación de repartidores 40. Cuando los pagos se ralentizan, su pool se llena y las siguientes llamadas de pago se rechazan de inmediato, pero las llamadas de restaurantes y repartidores continúan. Un timeout limita cuánto tiempo puede retener recursos cada llamada; un bulkhead limita cuántas pueden retenerlos a la vez, así que protege incluso cuando los timeouts son demasiado largos.

Los bulkheads también funcionan a mayor escala. Despliegues separados del mismo servicio para distintos llamantes (un grupo de instancias del servicio de pedidos para la app de clientes y otro para la API de restaurantes asociados) impiden que una integración de socio que se comporta mal deje sin recursos a los clientes. Las arquitecturas basadas en células, el eje Z del cubo de escalado, convierten cada célula en un bulkhead para una parte de los clientes, y el shuffle sharding, descrito por ingenieros de AWS, asigna a cada cliente una pequeña combinación aleatoria de instancias para que el tráfico venenoso de un cliente afecte a muy pocos otros. El costo de todo bulkhead es la utilización: la capacidad reservada para un compartimento no se puede prestar a otro, así que los pools deben dimensionarse a partir de la demanda medida.

Alternativas (fallbacks) y degradación elegante

Cuando una llamada falla o un breaker está abierto, quien llama debe responder de todos modos. Una alternativa (fallback) decide qué devuelve. Las opciones, de mejor a peor para el usuario, son: un valor en caché u obsoleto (la última carta conocida, con los precios confirmados en el proceso de pago); un valor predeterminado razonable (un tiempo de entrega estimado de 30 a 45 minutos en lugar de una estimación en vivo); una función reducida (platos populares en lugar de recomendaciones personalizadas); aplazar el trabajo (aceptar una reseña y publicarla cuando se recupere el servicio de reseñas); y un error claro y rápido que indique al usuario qué hacer. Diseñarlas función por función, con el responsable de producto, es lo que significa en la práctica la degradación elegante: el recorrido principal (explorar, pedir, pagar, seguir el pedido) sigue funcionando mientras las funciones no esenciales se hacen a un lado. El mismo razonamiento guía el descarte de carga (Sección 9.3): saber de antemano qué funciones desactivar primero.

Las decisiones de seguridad son la excepción: si el servicio de autorización no está accesible, la alternativa segura es denegar (fallar de forma cerrada, fail closed), no permitir. Los profesionales también discrepan sobre las alternativas en general. Nygard y los ingenieros de Netflix las defienden ampliamente. Los ingenieros de Amazon han argumentado, en el artículo de la Builders' Library Avoiding fallback in distributed systems, que las rutas alternativas rara vez se ejercitan, son difíciles de probar y pueden provocar ellas mismas caídas al pasar una flota grande a un modo no probado en el peor momento; prefieren hacer más fiable la ruta principal y fallar rápido. Ambas posturas coinciden en la regla práctica: una alternativa debe ser más sencilla que aquello a lo que sustituye, no debe depender del componente que ha fallado y debe ejercitarse con regularidad, por ejemplo en game days (Sección 9.8), o no debería existir.

Idempotencia: lo que hace seguros los reintentos y las solicitudes de cobertura

La idempotencia es la propiedad de que hacer algo dos veces tenga el mismo efecto que hacerlo una vez. Todos los patrones de esta sección que repiten trabajo dependen de ella: los reintentos tras un timeout, las solicitudes de cobertura, la nueva entrega de mensajes tras la caída de un consumidor y los reprocesamientos desde una cola de mensajes fallidos. La Sección 6.5 mostró cómo una clave de idempotencia convierte POST /orders en un reintento seguro, y la Sección 6.4, cómo los consumidores idempotentes eliminan los mensajes duplicados. La regla arquitectónica es sencilla: antes de añadir un reintento, comprueba que la operación es idempotente y, si no lo es, añade primero una clave o una comprobación de duplicados. Una política de reintentos sobre una llamada de pago no idempotente no es un patrón de resiliencia; es un generador de cobros dobles.

Solicitudes de cobertura

Los reintentos se ocupan de los fallos; las solicitudes de cobertura (hedged requests) se ocupan de la lentitud. La Sección 2.4 las presentó a partir de The Tail at Scale (2013), de Dean y Barroso: envía una solicitud a una réplica y, si no ha respondido dentro de, por ejemplo, la latencia del percentil 95, envía una copia a una segunda réplica y usa la respuesta que llegue primero, cancelando la otra. Como solo se duplica el pequeño porcentaje de solicitudes más lentas, la carga adicional es pequeña, mientras que la cola se reduce de forma espectacular, como mostró la prueba de rendimiento citada en la Sección 2.4.

Las solicitudes de cobertura tienen condiciones previas. La operación debe ser idempotente, normalmente una lectura. Debe haber réplicas independientes, para que sea improbable que la segunda copia sea lenta por el mismo motivo. Las solicitudes adicionales deben estar presupuestadas y desactivarse en situaciones de sobrecarga, porque cuando todas las réplicas son lentas, las solicitudes de cobertura duplican la carga de un sistema que ya tiene dificultades, exactamente igual que un reintento sin presupuesto. Usadas con cuidado en rutas con muchas lecturas y fan-out, como la búsqueda y las consultas de la carta, son una de las herramientas más eficaces contra la latencia de cola.