Asincronía, colas y back pressure

Las colas convierten los picos en trabajo acumulado

La carga nunca llega de forma uniforme. Los pedidos del almuerzo se concentran a las 12:30, los compradores de entradas pulsan todos el botón a las 10:00:00, y un trabajo por lotes vuelca un millón de eventos a medianoche. Un servicio síncrono debe tener capacidad para el pico más alto o fallar durante él. Poner una cola entre quien produce el trabajo y el servicio que lo realiza cambia la aritmética: durante un pico, el trabajo sobrante espera en la cola, y los consumidores lo procesan a su propio ritmo constante, y se ponen al día cuando el pico ha pasado. El catálogo de patrones de nube de Microsoft llama a esto nivelación de carga basada en colas (queue-based load levelling). La Sección 2.4 mostró por qué se forman colas siempre que las llegadas se concentran; esta sección trata de usarlas de forma deliberada.

El beneficio es real: los consumidores pueden dimensionarse para la media en lugar de para el pico, un consumidor lento o que se reinicia no pierde trabajo, y el productor ya no está acoplado temporalmente al consumidor (Sección 6.5). El precio es que el trabajo ahora se hace más tarde. Una cola convierte un pico en un trabajo acumulado (backlog), y un backlog es simplemente un retraso que sufrirá cada elemento que quede detrás. Eso está bien para enviar correos electrónicos de confirmación o actualizar un índice de búsqueda, es discutible para asignar un repartidor a un pedido, e inaceptable para un pago cuya confirmación espera ver el cliente. Por eso, la primera pregunta de diseño para cualquier cola es: ¿cuánto tiempo puede esperar un elemento y qué ocurre con los elementos que esperarían más?

Colas de trabajo y consumidores competidores

El uso más habitual es una cola de trabajo con consumidores competidores: varios workers idénticos leen de una misma cola, cada mensaje va solo a uno de ellos, y el rendimiento (throughput) crece añadiendo workers. Es el eje X del cubo de escalado aplicado al trabajo en segundo plano, y escala de forma natural con la señal adecuada: el backlog por worker o la antigüedad del mensaje más antiguo.

La mecánica importa para la corrección. Un worker toma un mensaje, lo procesa y después confirma su recepción; si el worker se cae antes, el intermediario vuelve a hacer visible el mensaje tras un timeout (SQS lo llama visibility timeout, timeout de visibilidad) y otro worker lo procesa. Por tanto, la entrega es al menos una vez, así que los consumidores deben ser idempotentes (Sección 6.4). Un timeout de visibilidad más corto que el tiempo real de procesamiento hace que el mismo mensaje se procese dos veces en paralelo. El orden se pierde en cuanto hay más de un consumidor, salvo que los mensajes se particionen por clave, en cuyo caso el número de particiones limita el número de consumidores útiles. Y el prefetch (que un worker tome varios mensajes a la vez para ahorrarse viajes de ida y vuelta) debe mantenerse bajo para las tareas lentas, o un worker acaparará mensajes que podrían haber procesado otros workers ociosos.

Una cola no crea capacidad

Una cola absorbe un exceso temporal; no puede absorber uno permanente. Si el trabajo llega más rápido de lo que se completa durante el tiempo suficiente, el backlog crece sin límite, y la ley de Little (L = λ × W) dice que el tiempo de espera crece con él. Una cola en memoria sin límite acaba agotando la memoria y haciendo caer el proceso, con lo que se pierde todo lo que contiene; una cola duradera sin límite llena su disco o conserva trabajo durante horas después de que a nadie le importe. Peor aún, la cola oculta el problema: los productores reciben confirmaciones rápidas, las tasas de error se quedan en cero, y el único síntoma es que los resultados llegan cada vez más tarde. Los ingenieros de Amazon describen estos backlogs como potencialmente insuperables, porque un servicio que se queda lo bastante atrás puede gastar toda su capacidad en procesar trabajo que sus clientes abandonaron hace tiempo.

De ahí se siguen dos prácticas. Primero, mide la antigüedad del mensaje más antiguo además de la longitud de la cola: la antigüedad es lo que experimentan los usuarios, y reacciona de inmediato cuando los consumidores se atascan. Segundo, da a cada cola un límite derivado del tiempo de espera que estás dispuesto a aceptar, usando la ley de Little, y decide de antemano qué ocurre cuando se alcanza el límite. Esa decisión es el tema de las tres partes siguientes de esta sección.

Back pressure: hacer que los productores vayan más despacio

El back pressure (contrapresión) es cualquier mecanismo por el que una etapa posterior más lenta hace que una etapa anterior más rápida vaya más despacio, en lugar de dejar que el trabajo se amontone entre ambas. El término viene de los fluidos en tuberías, y la idea apareció en tuberías y filtros (Sección 5.4). Está integrado en muchas capas de la pila que ya usas. El control de flujo de TCP detiene a un emisor cuando el búfer del receptor está lleno. Una cola bloqueante acotada hace que el put del productor espere a que haya espacio. Los consumidores basados en pull, como en Kafka, toman trabajo solo cuando están listos, de modo que es el log del broker, y no la memoria del consumidor, lo que guarda el backlog, y un productor de Kafka se bloquea o falla cuando su propio búfer de envío está lleno. La especificación Reactive Streams permite que un suscriptor solicite un número concreto de elementos, de modo que un flujo nunca entrega más de lo que el suscriptor ha pedido.

El back pressure funciona bien dentro de un proceso o a lo largo de un pipeline. A través de una frontera de solicitud-respuesta con usuarios humanos, normalmente se convierte en rechazo: un servicio HTTP sobrecargado no puede hacer que un teléfono espere educadamente, así que responde 429 Too Many Requests o 503 Service Unavailable, idealmente con una cabecera Retry-After, y confía en que el cliente reduzca el ritmo. Cuando una cola acotada está llena solo hay tres opciones: bloquear al productor, rechazar el trabajo nuevo o descartar algo ya aceptado. Cada una es la correcta en algún caso; el error es no elegir.

Descarte de carga y priorización

Un servidor con más carga de la que puede gestionar lo hace peor que si atendiera su capacidad y rechazara el resto. Lo acepta todo, cada solicitud espera en sus colas internas, los tiempos de respuesta superan los timeouts de los clientes, y acaba gastando toda su capacidad en solicitudes cuyos clientes ya se han rendido. El rendimiento (throughput) se mantiene alto mientras que el goodput, la tasa de solicitudes completadas a tiempo para ser útiles, se desploma hacia cero. El descarte de carga (load shedding) lo evita rechazando algunas solicitudes de forma deliberada para que el resto tenga éxito.

Un buen descarte tiene tres propiedades. Es temprano y barato: rechazar una solicitud debe costar mucho menos que atenderla, así que se hace en la puerta de entrada, antes de la autenticación costosa o del trabajo con la base de datos, a partir de una señal barata como las solicitudes en curso o la antigüedad de la cola. Está priorizado: el libro de SRE de Google describe cómo etiquetar cada solicitud con una criticidad (de CRITICAL_PLUS a SHEDDABLE) para que el tráfico por lotes y de precarga se descarte antes que el tráfico de cara al usuario. En la plataforma de reparto de comida, los pagos y las actualizaciones de ubicación de los repartidores tienen prioridad sobre las recomendaciones, que a su vez la tienen sobre los eventos de analítica. Y es consciente del tiempo: una solicitud que ya ha esperado más que el timeout de quien la llama debe descartarse en lugar de procesarse. Los ingenieros de Facebook han descrito dos refinamientos: una cola de retardo controlado que solo permite una espera corta cuando una cola no se ha vaciado recientemente, y pasar a último en entrar, primero en salir (LIFO) bajo carga, para que se atiendan primero las solicitudes más recientes, cuyos usuarios todavía están esperando.

Un paso más es adaptar el propio límite. Los límites de concurrencia fijos son o demasiado bajos en un buen día o demasiado altos en uno malo; los limitadores de concurrencia adaptativos aumentan el número permitido de solicitudes en curso mientras la latencia se mantiene baja y lo reducen cuando la latencia sube, tomando la idea del control de congestión de TCP. En el extremo frontal de un sistema, el control de admisión puede adoptar la forma de una sala de espera virtual, como en la venta de entradas anterior: los usuarios se retienen en una cola en el borde y se admiten al ritmo que el núcleo puede atender, lo cual es descarte de carga presentado como equidad.

Algoritmos de limitación de tasa

La limitación de tasa (rate limiting) restringe cuánto trabajo puede enviar en un periodo un cliente, una clave de API, un inquilino (tenant) o una dirección IP concretos. Se diferencia del descarte de carga en su propósito: el descarte protege al servidor de una sobrecarga total, la cause quien la cause, mientras que la limitación de tasa reparte la capacidad de forma equitativa y protege frente a cualquier cliente concreto, ya tenga errores o sea malicioso. Ambos responden de la misma manera, normalmente con HTTP 429. Predominan cuatro algoritmos.

El token bucket (cubeta de tokens) merece un examen más detenido porque es la opción predeterminada habitual. La cubeta contiene hasta b tokens y gana r tokens por segundo. Cada solicitud toma un token; si no queda ninguno, se rechaza (o, en la variante de conformación, se retrasa). Por tanto, un cliente que ha estado inactivo puede enviar una ráfaga de b solicitudes a la vez, lo que se adapta a clientes reales como una app móvil que abre una pantalla, mientras que en cualquier periodo más largo no puede superar r de media. El leaky bucket (cubeta con fugas) es su imagen especular: suaviza la salida hasta una tasa constante, lo que resulta útil para proteger un sistema posterior que no admite ráfagas en absoluto.

import math, time

class TokenBucket:
    def __init__(self, rate, capacity):
        self.rate = rate              # tokens added per second
        self.capacity = capacity      # largest burst allowed
        self.tokens = capacity        # start full
        self.updated = time.monotonic()

    def allow(self, cost=1):
        now = time.monotonic()
        elapsed = now - self.updated
        self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
        self.updated = now
        if self.tokens >= cost:
            self.tokens -= cost
            return True, 0
        wait = (cost - self.tokens) / self.rate   # seconds until enough tokens
        return False, max(1, math.ceil(wait))      # for the Retry-After header

bucket = TokenBucket(rate=5, capacity=20)        # one bucket per API key
allowed, retry_after = bucket.allow()

HTTP 429, Retry-After y dónde aplicar los límites

HTTP tiene señales estándar para ambas situaciones. 429 Too Many Requests, definido en el RFC 6585 (2012), indica a un cliente que ha enviado demasiadas solicitudes en un tiempo determinado. 503 Service Unavailable dice que el servidor en su conjunto está sobrecargado temporalmente o en mantenimiento. Cualquiera de los dos puede llevar una cabecera Retry-After (RFC 9110), que da un número de segundos o una fecha a partir de la cual tiene sentido reintentar. Muchas API también devuelven cabeceras que anuncian el límite, la cuota restante y el momento del reinicio, tradicionalmente X-RateLimit-*; un borrador del IETF está estandarizando los campos RateLimit y RateLimit-Policy. Los clientes que se comportan bien respetan Retry-After, añaden jitter para que los clientes rechazados no vuelvan todos en el mismo instante, y tratan los 429 repetidos como un motivo para ir más despacio y no para reintentar con más fuerza (Sección 9.4).

Los límites se pueden aplicar en varias capas, y los sistemas maduros usan más de una: en el borde o en el API gateway, por dirección IP y clave de API, para detener el abuso y los clientes descontrolados antes de que cuesten nada; por inquilino, para que un cliente grande no deje sin recursos a los demás; y dentro de cada servicio, para proteger su propia capacidad y sus dependencias. Un límite global entre muchas instancias del gateway necesita estado compartido, normalmente contadores atómicos en Redis, lo que añade una llamada de red por solicitud; un compromiso habitual es dar a cada una de las N instancias un límite local de aproximadamente 1 ÷ N del total y aceptar cierta imprecisión. Los límites deben fijarse a partir de la capacidad medida y publicarse, para que los socios puedan diseñar teniéndolos en cuenta, y el número de rechazos debe monitorizarse, porque un aumento repentino es o un ataque, o un error en un cliente, o un límite que ya no se ajusta a la realidad.

Colas de mensajes fallidos

Algunos mensajes fallan siempre: un payload mal formado, un pedido para un restaurante que ya no existe, un bug que desencadena una entrada concreta. Si se reintenta indefinidamente, un mensaje así, un mensaje venenoso (poison message), bloquea una partición o desperdicia un worker para siempre. Una cola de mensajes fallidos (dead-letter queue) (presentada en la Sección 6.4) recibe los mensajes que han fallado un número determinado de veces (SQS lo llama número máximo de recepciones, maximum receive count, en una redrive policy), para que el resto del trabajo pueda continuar.

Una cola de mensajes fallidos es una herramienta para los defectos, no para la sobrecarga: si los mensajes acaban en ella porque los consumidores son demasiado lentos, la solución es la capacidad o el back pressure, no una segunda cola. Cada mensaje de una DLQ significa que algo que el negocio esperaba no ocurrió, así que la DLQ necesita un responsable, una alerta sobre su profundidad o antigüedad, herramientas para inspeccionar los mensajes con su error y su número de intentos, y una forma de volver a procesarlos una vez corregida la causa. Decide de antemano qué significa reprocesar con retraso para el orden y para los mensajes cuyo momento de negocio ya ha pasado: un reembolso puede reprocesarse con un día de retraso; una asignación de repartidor, no.