Incidente en US-East por agotamiento de conexiones de Redis

Kevin van Zonneveld

Cofundador · Ámsterdam, Países Bajos · Mostrar bio

El 3 de septiembre de 2025 (US-East), experimentamos tiempos de cola elevados y, por momentos, procesamiento de Jobs detenido debido al agotamiento de conexiones de Redis. El problema se estabilizó el mismo día mediante un hotpatch y cambios de configuración. Esta publicación explica qué ocurrió, cómo lo mitigamos y qué estamos haciendo para evitar que se repita.

Resumen

Un endpoint de servicio interno filtraba conexiones de Redis cuando recibía una carga intensa. Un cliente generó una ráfaga de solicitudes inusualmente grande hacia ese endpoint. Aunque nuestro traffic shaper aisló la ráfaga en una cola de respaldo, la fuga de conexiones propagó la presión por los servidores de Redis compartidos. Una vez que los servidores alcanzaron sus límites de conexión, los workers y las rutas de API legítimas de la región quedaron sin recursos, lo que provocó colas lentas y bloqueos intermitentes de Jobs. Desplegamos un hotpatch para cerrar las conexiones filtradas y ajustamos los límites; después de eso, el procesamiento volvió a la normalidad.

Impacto

• Periodo: 3 de septiembre de 2025
  • 12:00 UTC: encoding lento en US-East con muchas colas
  • 19:50 UTC: se observaron tiempos de cola elevados y demasiadas conexiones en cola
  • 21:24 UTC: sistemas estabilizados; continuó la investigación de la causa raíz
  • 23:06 UTC: se identificó la fuga de conexiones y se desplegó el hotpatch; recuperación confirmada
• Región: us-east-1
• Impacto para el usuario:
  • Tiempos de cola más altos de lo normal para las Assemblies
  • En algunos casos, Jobs detenidos cuando los servidores de Redis rechazaron conexiones adicionales
  • Los webhooks y las notificaciones, así como algunas interacciones con la API en la región, se retrasaron

Causa raíz

• Una ruta de código en un endpoint interno de alto tráfico no cerraba de forma confiable las conexiones de Redis bajo condiciones de error específicas.
• La carga de trabajo de un solo cliente exigió en exceso este endpoint de forma involuntaria, lo que aumentó la rotación de conexiones y expuso la fuga.
• Con el tiempo se agotaron los límites de conexión de los servidores de Redis, lo que bloqueó nuevas conexiones de workers y nodos de API legítimos.

Factores contribuyentes:

• Los pools de Redis compartidos aumentaron el radio de impacto una vez que se alcanzaron los límites de conexión.
• Los dashboards existentes no revelaron la fuga de conexiones, porque las métricas de la ruta de éxito estaban sanas mientras que el conteo de conexiones de la ruta de error no lo estaba.

Detección

Detectamos el problema mediante alertas de latencia de colas y anomalías en los heartbeats de los workers. Los ingenieros correlacionaron picos en el connected_clients de Redis, el aumento de la rotación de conexiones y errores ECONNREFUSED/max clients reached en los servidores afectados.

Mitigación y recuperación

• El tráfico de la carga de trabajo problemática ya se estaba derivando poco a poco a una cola de respaldo aislada, lo que limitaba el impacto sin eliminarlo.
• Aumentamos temporalmente los límites de conexión de Redis para crear margen durante el diagnóstico.
• Desplegamos un hotpatch para garantizar que las conexiones siempre se liberen tanto en la ruta de éxito como en la de error del endpoint en cuestión.
• Reciclamos los procesos afectados para drenar las conexiones filtradas y verificamos el funcionamiento normal.

A las 21:24 UTC, los sistemas se estabilizaron. A las 23:06 UTC, se confirmó la fuga y el hotpatch se desplegó en toda la flota. Desde entonces, los sistemas se han mantenido sanos.

Comunicación con los clientes

Publicamos actualizaciones en nuestra página de estado durante todo el incidente y nos comunicamos con los clientes afectados. Tras la mitigación, recomendamos intentar la reejecución de Assemblies para recuperar resultados que de otro modo se habrían perdido, cuando los archivos de entrada seguían disponibles.

Qué haremos a continuación

• Agregar SLO y dashboards de fugas de conexión que hagan seguimiento del ciclo de vida de las conexiones en las rutas de éxito y de error.
• Introducir presupuestos de conexión por endpoint y circuit breakers para contener las fugas.
• Reforzar el pooling de clientes de Redis con timeouts estrictos y bloques finally verificables por el linter alrededor de la adquisición.
• Separar los roles críticos de Redis (colas, bloqueos, metadatos) en pools distintos con límites independientes.
• Endurecer el rate limiting en el endpoint afectado, con backpressure que degrade de forma controlada.
• Agregar pruebas de caos para simular caídas parciales de Redis e inundaciones de conexiones.

Si te viste afectado

Vuelve a ejecutar los Jobs críticos cuando sea posible. Si tus archivos de entrada siguen disponibles, puedes reejecutar una Assembly fallida a través de nuestra API; consulta Reejecutar una Assembly. Si necesitas ayuda para identificar los Jobs afectados, por favor comunícate con soporte y te ayudaremos.

Actualización del 4 de septiembre de 2025

Un día después, tuvimos otro incidente. Aunque logramos tapar una fuente de fugas, resultó que había otra. Esta vez pudimos detectarla antes y mitigar el problema en menos de una hora.

Completamos un endurecimiento adicional para reducir la probabilidad de que se repita. Agregamos rate limits específicos al endpoint implicado, mejoramos la higiene de conexiones en las rutas de código que manejan errores y separamos algunas responsabilidades de Redis en pools independientes con límites más claros. En conjunto, estos cambios reducen el radio de impacto y hacen que el sistema sea más resiliente ante cargas de trabajo con ráfagas.

También ampliamos el monitoreo y las alertas para centrarnos en señales tempranas, como la rotación anormal de conexiones y la presión en las colas, de modo que podamos reaccionar más rápido si surgen patrones similares. Estas mejoras ya están activas en US-East y se desplegarán en otras regiones como precaución.

Cierre

Lamentamos sinceramente la interrupción. La confiabilidad es nuestra máxima prioridad y no cumplimos con nuestros propios estándares en US-East el 3 de septiembre. Las correcciones enumeradas arriba ya están en marcha y volveremos a informar si hay más cambios importantes.