Arreglar el worker antes de escalar la flota
Un despliegue de autoscaling basado en colas expuso workers de navegador atascados; escalar solo fue útil tras contener la fuga de recursos.
KEDA estuvo activo en cuatro entornos. El tope de 50 réplicas en producción es configuración, no capacidad de throughput demostrada.
Contribución de un vistazo
- Mi responsabilidad
- Análisis de la señal de demanda, configuración de KEDA y diagnóstico y reparación del ciclo de vida del worker.
- Alcance
- Un worker impulsado por Pub/Sub desplegado en cuatro entornos.
- Colaboración y límites
- Trabajé entre el comportamiento de los procesos de la aplicación y el escalado de infraestructura; el despliegue expuso un defecto del worker que había que reparar primero.
- Resultado
- KEDA quedó activo en cuatro entornos tras contener los procesos hijos atascados. Un límite de 50 réplicas es configuración, no capacidad demostrada.
La señal engañosa
El servicio capturaba transmisiones en vivo usando procesos hijos del navegador. Un pod podía ocupar todos sus slots de concurrencia usando poca CPU. Una vez lleno, dejaba de tomar mensajes, de modo que la demanda adicional se acumulaba en Pub/Sub en lugar de hacer reaccionar al autoscaler basado en CPU.
Mi contribución
Evalué la señal de demanda real del workload, implementé un trigger de KEDA para Pub/Sub e investigué las fallas que surgieron durante el despliegue. Esa investigación cambió la tarea: un incidente activo en producción necesitaba una corrección del ciclo de vida del worker antes de que escalar pudiera ayudar.
El defecto de la aplicación detrás del backlog
Las transmisiones sin ningún participante dejaban procesos hijos esperando indefinidamente un elemento de video. Cada hijo retenía un navegador y un slot de concurrencia hasta que los pods se quedaban sin memoria. Más réplicas solo distribuirían esos procesos atascados entre más máquinas.
Verifiqué el comportamiento dentro del propio navegador del pod y corregí el ciclo de vida del health-check del lado del padre. La evidencia de producción descartó una hipótesis inicial de timeout del lado del navegador: la ruta del lado del padre era la que realmente se disparaba.
Elegir una señal que el workload realmente produzca
Usé el backlog de la suscripción que consume esta aplicación. El conteo de transmisiones activas de un servicio hermano representaba un flujo de captura distinto, y su métrica de escalado no podía reutilizarse con seguridad. Un trigger de Prometheus tampoco era adecuado porque la infraestructura de scrape necesaria no estaba presente en los clusters de desarrollo y staging.
El HPA anterior se eliminó cuando KEDA tomó el control. Desarrollo, staging y sandbox usaron workload identity para el scaler; producción usó una ruta de credenciales verificada por separado.
Resultados y medición
El cierre registró KEDA Ready en cuatro entornos y las aplicaciones de GitOps relacionadas en Synced/Healthy. La instantánea posterior al despliegue reportó cero reinicios, frente a los repetidos OOM kills durante el incidente. Se trata de una observación del despliegue, no de una afirmación de disponibilidad a largo plazo.
El máximo de producción se configuró en 50 réplicas. Eso es un límite de seguridad que hay que monitorear, no una prueba de capacidad sostenida a ese tamaño.
Límites y decisiones operativas
La promoción a producción fue una excepción explícita por el incidente, antes de la validación habitual de QA. Quedó trabajo de seguimiento en torno a las transmisiones sin participantes, el origen de su pico de tráfico y la presión de capacidad con un número mayor de réplicas. El cambio contuvo la falla del ciclo de vida de los recursos; no estableció una tasa de éxito de captura de extremo a extremo.
La lección
El autoscaling controla cuántos workers existen. No puede hacer que cada worker libere los recursos correctamente. Diagnostica el mecanismo de saturación antes de aumentar la flota.
Decisiones y próximos pasos
Una mirada retrospectiva al enfoque y sus límites. La próxima mejora es una propuesta, no un resultado entregado.
Alternativa y justificación
Los triggers de CPU y memoria no detectan un worker cuyos slots están ocupados por procesos de navegador atascados. El backlog representa mejor el trabajo pendiente.
Contrapartida
Escalar un worker con fugas multiplica el defecto. El escalado basado en demanda aún necesita acotar el ciclo de vida de los procesos hijos y la concurrencia.
Lo que mejoraría a continuación
Próxima mejora: hacer pruebas de carga del throughput y la recuperación con fallas realistas de transmisión antes de tratar los límites de réplicas como garantías de capacidad.