¿Cómo el patrón de orquestador dual previene los single points of failure en la infraestructura de streaming RTSP?

MicrocosmWorks implementó un diseño de orquestador dual activo-activo donde ambos orquestadores mantienen un estado sincronizado sobre las asignaciones de stream y el estado de los workers, con automatic failover que transfiere la gestión del stream al orquestador superviviente en segundos si uno falla. Esto elimina el single point of failure que sufren los diseños tradicionales de orquestador único, asegurando zero packet drop durante el mantenimiento del orquestador o los fallos inesperados.

¿Cómo logra la arquitectura de autoescalado cero pérdida de paquetes al añadir o eliminar trabajadores de streaming?

MicrocosmWorks diseñó un mecanismo de drenaje elegante donde los trabajadores que se retiran continúan sirviendo sus flujos asignados hasta que todas las conexiones sean migradas limpiamente a nuevos trabajadores a través de secuencias RTSP TEARDOWN y re-SETUP. Los nuevos trabajadores se inicializan completamente y se les verifica el estado de salud antes de recibir asignaciones de flujo, y la transición utiliza ventanas superpuestas donde tanto los trabajadores antiguos como los nuevos sirven brevemente el mismo flujo para evitar cualquier interrupción.

¿Por qué usar MediaMTX como el servidor de streaming central en lugar de alternativas como Wowza o Ant Media?

MicrocosmWorks seleccionó MediaMTX para este proyecto porque es ligero, de código abierto y diseñado específicamente para la retransmisión RTSP con una sobrecarga mínima de recursos por stream en comparación con servidores de medios completos. Soporta la creación dinámica de streams a través de la API, se ejecuta eficientemente en contenedores para autoescalado basado en Kubernetes, y evita los costos de licencia por stream de alternativas comerciales como Wowza que pueden volverse prohibitivos a escala.

¿Qué monitorización y alertas se necesitan para mantener la fiabilidad en una plataforma de streaming RTSP de autoescalado?

MicrocosmWorks implementó una pila de observabilidad completa que rastrea métricas por stream, incluyendo la tasa de pérdida de paquetes, jitter, el recuento de reconexiones y la latencia de extremo a extremo, con alertas que se activan antes de que la degradación sea visible para los usuarios finales. El sistema de monitorización también rastrea métricas de toma de decisiones del orquestador, como eventos de escalado, duraciones de migración de streams y tendencias de utilización de workers, para permitir una planificación proactiva de la capacidad.

¿Puede esta arquitectura RTSP autoescalable manejar tanto las cargas de trabajo de visualización en vivo como de grabación simultánea?

Sí, MicrocosmWorks diseñó los nodos de trabajo para soportar salida RTSP concurrente para espectadores en vivo y grabación segmentada a almacenamiento de objetos, con asignación de recursos independiente para cada carga de trabajo. La grabación utiliza una ruta de escritura separada que almacena segmentos en búfer localmente antes de subirlos, por lo que los picos de E/S de almacenamiento nunca afectan la entrega de transmisiones en vivo, y el autoescalador tiene en cuenta la demanda combinada de recursos de ambas cargas de trabajo al tomar decisiones de escalado.

Auto-Scaling RTSP Streaming Architecture with Dual Orches...

La infraestructura de streaming fija no podía manejar las demandas variables de una plataforma de vigilancia en crecimiento:

Variabilidad de la Escala — El número de cámaras y la demanda de espectadores fluctuaban drásticamente a lo largo del día (relación de 10x entre pico y valle)
Costo por Sobreaprovisionamiento — Aprovisionar para la carga máxima significaba más del 70% de recursos ociosos durante las horas de menor actividad
Pérdida de Paquetes Durante el Escalado — Añadir o eliminar servidores de streaming causaba interrupciones en la transmisión, perdiendo frames para los trabajadores de procesamiento de AI
Inestabilidad de URLs — Las cámaras y espectadores configurados con IPs de servidor específicas necesitaban reconfiguración cuando la infraestructura cambiaba
Diferentes Necesidades de Escalado — La ingesta de cámaras y la distribución a espectadores tenían patrones de carga fundamentalmente diferentes que requerían escalado independiente
Interrupción de Trabajadores de AI — Las tuberías de procesamiento de AI colapsaban cuando su servidor de stream de origen se reducía

Diseñamos una arquitectura de streaming con autoescalado y doble orquestador con clusters de ingesta y distribución separados, un apagado controlado de 5 fases para cero pérdida de paquetes, URLs estables basadas en DNS y reconexión automatizada de trabajadores de AI.

Arquitectura

Servidor de Streaming: MediaMTX para soporte de protocolo RTSP/WebRTC/HLS
Cluster de Ingesta: 1-10 servidores que reciben streams RTSP de cámaras
Cluster de Distribución: 2-20 servidores que atienden a espectadores (WebRTC/HLS) y trabajadores de AI (RTSP)
Orquestadores Duales: Controladores de escalado independientes para ingesta y distribución
Load Balancers: Load Balancers separados por cluster con algoritmos apropiados para el protocolo
Registro de Servicio: Redis para el estado del servidor, mapeo de streams y coordinación
Monitorización de Salud: Chequeos de salud activos con recuperación automatizada
Capa DNS: Nombres de dominio estables que apuntan a Load Balancers (las URLs nunca cambian)

Diseño de Doble Orquestador

Por qué Dos Orquestadores

La ingesta y la distribución tienen características de escalado fundamentalmente diferentes:

Ingesta escala con el número de cámaras y el ancho de banda entrante (predecible, crece constantemente)
Distribución escala con el número de espectadores y la demanda de trabajadores de AI (irregular, impredecible)

Orquestadores separados permiten que cada uno escale independientemente con políticas, métricas y umbrales especializados, sin que las decisiones de escalado de un cluster afecten al otro.

Orquestador de Ingesta

Métrica Primaria: Conexiones de cámara por servidor
Métrica Secundaria: Utilización del ancho de banda entrante
Escalar Arriba: Cuando el CPU supera el umbral o las cámaras por servidor exceden la capacidad
Escalar Abajo: Cuando la utilización cae por debajo del umbral durante un período de estabilización sostenido
Rango de Servidores: 1 a 10 servidores

Orquestador de Distribución

Métrica Primaria: Conexiones de espectadores + trabajadores de AI por servidor
Métrica Secundaria: Utilización del ancho de banda saliente
Escalar Arriba: Cuando el CPU supera el umbral o las conexiones por servidor exceden la capacidad
Escalar Abajo: Cuando la utilización cae por debajo del umbral durante un período sostenido (estabilización más larga que la ingesta)
Rango de Servidores: 2 a 20 servidores (mínimo 2 para alta disponibilidad)

Cero Pérdida de Paquetes: Apagado Controlado en 5 Fases

Cuando un servidor de distribución está programado para ser eliminado, un proceso de 5 fases asegura que no se pierda ningún frame:

Fase 1: Pre-Notificación

El servidor se marca como "DRAINING" en el registro de servicio. El peso del Load Balancer se reduce para que las nuevas conexiones se dirijan a otro lugar. Las notificaciones de Redis pub/sub y webhooks alertan a los trabajadores de AI para que se preparen para la migración.

Fase 2: Actualización del Load Balancer

El servidor se elimina del pool de backend del Load Balancer. Ninguna nueva conexión puede llegar al servidor en drenaje. Las conexiones existentes continúan sin interrupción.

Fase 3: Migración de Trabajadores de AI

Los trabajadores de AI se desconectan del servidor en drenaje y se reconectan a servidores de distribución saludables. La preservación del estado basada en checkpoint asegura que el procesamiento se reanude desde el frame exacto donde se detuvo. Brecha total: aproximadamente 3 segundos con cero frames perdidos.

Fase 4: Drenaje de Espectadores

Las conexiones de espectadores restantes se drenan naturalmente durante una ventana configurable. Los reproductores de video modernos se reconectan automáticamente a la misma URL estable, que enruta a servidores saludables. La mayoría de los espectadores no experimentan interrupción.

Fase 5: Limpieza

Verificar que todas las conexiones se hayan cerrado. Eliminar el servidor del registro de servicio. Destruir la instancia en la nube. Registrar métricas de escalado.

URLs Estables

La arquitectura de URL asegura que las cámaras y los clientes nunca necesiten reconfiguración:

Objetivo de publicación de cámara: Un nombre de dominio de ingesta estable
Objetivo de acceso de espectador/AI: Un nombre de dominio de distribución estable
Los registros DNS apuntan a las IPs del Load Balancer (que son permanentes)
Los Load Balancers manejan el enrutamiento a los servidores backend de forma transparente
Los servidores backend pueden ser añadidos, eliminados o reemplazados sin cambios de URL

Registro de Servicio (Redis)

Una instancia centralizada de Redis coordina todo el sistema:

Seguimiento del estado del servidor (activo, drenando, offline)
Mapeo de stream a servidor (qué cámara está en qué servidor de ingesta)
Estado del trabajador de AI y datos de checkpoint
Métricas de carga por servidor para decisiones de escalado
Canales pub/sub para eventos de coordinación en tiempo real

Reconexión del Cliente AI

Una biblioteca de cliente de AI proporciona reconexión sin interrupciones:

Escucha notificaciones de eliminación de servidor a través de Redis pub/sub
Checkpointing automático de frames a intervalos regulares
Reconexión a un servidor de distribución saludable tras la notificación
Reanudar el procesamiento desde el checkpoint con una brecha mínima
Reporte de métricas para eventos de reconexión

Monitorización de Salud

Chequeos de salud activos en cada servidor a intervalos regulares
Actualizaciones automáticas del Load Balancer en caso de fallos del servidor
Disparadores de recuperación automática para servidores que no responden
Seguimiento de tiempo de actividad e informes de disponibilidad

Características Clave

Orquestadores Duales — Escalado independiente para clusters de ingesta y distribución
Cero Pérdida de Paquetes — Apagado controlado en 5 fases con migración de trabajadores de AI
URLs Estables — El enrutamiento basado en DNS asegura que las URLs nunca cambien durante el escalado
Reconexión de Trabajadores de AI — Migración basada en checkpoint con una brecha de ~3 segundos y cero pérdida de frames
Escalado Independiente — Ingesta y distribución escalan basándose en sus propias métricas
Registro de Servicio — Coordinación basada en Redis para el estado del servidor y mapeo de streams
Monitorización de Salud — Chequeos activos con recuperación automática
Optimización de Costos — Reducción automática de la escala durante períodos de baja demanda

Arquitectura de Streaming RTSP con Autoescalado, Doble Orquestador y Cero Pérdida de Paquetes

El Desafío

Nuestra Solución

Arquitectura

Diseño de Doble Orquestador

Por qué Dos Orquestadores

Orquestador de Ingesta

Orquestador de Distribución

Cero Pérdida de Paquetes: Apagado Controlado en 5 Fases

URLs Estables

Registro de Servicio (Redis)

Reconexión del Cliente AI

Monitorización de Salud

Características Clave

Resultados

Stack Tecnológico

caseStudyDetail.more Casos de Estudio

Catant Plataforma de Gestión de RRHH y Fuerza Laboral

Kickly: Plataforma de Proyectos Impulsada por AI para Startups

¿Listo para Transformar su Negocio?

Procesamiento de Facturas Potenciado por AI con OCR e Integración con QuickBooks

Preguntas Frecuentes