Arquitectura de Streaming RTSP Autoescalable con Orquestadores Duales y Cero Pérdida de Paquetes
Una plataforma de vigilancia necesitaba escalar su infraestructura de streaming de video de forma dinámica — manejando entre 10 y más de 200 cámaras IP con cientos de espectadores concurrentes y trabajadores de procesamiento de AI — mientras garantizaba cero pérdida de paquetes durante las operaciones de escalado y mantenía URLs de stream estables que nunca cambiaran.
Discuta Su Proyecto
El Desafío
La infraestructura de streaming fija no podía manejar las demandas variables de una plataforma de vigilancia en crecimiento:
- Variabilidad de Escala — El número de cámaras y la demanda de espectadores fluctuaban drásticamente a lo largo del día (ratio de 10x entre pico y valle)
- Costo de 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 el stream, perdiendo frames para los trabajadores de procesamiento de AI
- Inestabilidad de URL — Las cámaras y los espectadores configurados con IPs de servidor específicas necesitaban reconfiguración cuando cambiaba la infraestructura
- Necesidades de Escalado Diferentes — 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 pipelines de procesamiento de AI colapsaban cuando se reducía la escala de su servidor de stream de origen
Nuestra Solución
Diseñamos una arquitectura de streaming autoescalable con orquestadores duales, 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 protocolos 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
- Balanceadores de Carga: Balanceadores de carga separados por cluster con algoritmos apropiados para el protocolo
- Registro de Servicios: Redis para estado del servidor, mapeo de streams y coordinación
- Monitoreo de Salud: Chequeos de salud activos con recuperación automatizada
- Capa DNS: Nombres de dominio estables que apuntan a los balanceadores de carga (las URLs nunca cambian)
Diseño de Orquestador Dual
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 de forma constante)
- Distribución escala con el número de espectadores y la demanda de trabajadores de AI (irregular, impredecible)
Los 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 Principal: Conexiones de cámara por servidor
- Métrica Secundaria: Utilización de ancho de banda entrante
- Escalar Arriba: Cuando la CPU excede 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 Principal: Conexiones de espectadores + trabajadores de AI por servidor
- Métrica Secundaria: Utilización de ancho de banda saliente
- Escalar Arriba: Cuando la CPU excede 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 de 5 Fases
Cuando un servidor de distribución es programado para ser eliminado, un proceso de 5 fases asegura que no se pierdan frames:
Fase 1: Pre-NotificaciónEl servidor se marca como "DRAINING" (Drenando) en el registro de servicios. El peso del balanceador de carga se reduce para que las nuevas conexiones se dirijan a otro lugar. Las notificaciones pub/sub de Redis y los webhooks alertan a los trabajadores de AI para que se preparen para la migración.
Fase 2: Actualización del Balanceador de CargaEl servidor se elimina del pool de backends del balanceador de carga. Ninguna nueva conexión puede llegar al servidor que se está drenando. Las conexiones existentes continúan sin interrupciones.
Fase 3: Migración de Trabajadores de AILos trabajadores de AI se desconectan del servidor que se está drenando y se reconectan a servidores de distribución saludables. La preservación del estado basada en checkpoints 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 EspectadoresLas 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 se dirige a servidores saludables. La mayoría de los espectadores no experimentan interrupciones.
Fase 5: LimpiezaVerificar que todas las conexiones se hayan cerrado. Eliminar el servidor del registro de servicios. Destruir la instancia de cloud. 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 espectadores/AI: Un nombre de dominio de distribución estable
- Los registros DNS apuntan a las IPs del balanceador de carga (que son permanentes)
- Los balanceadores de carga 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 Servicios (Redis)
Una instancia centralizada de Redis coordina todo el sistema:
- Seguimiento del estado del servidor (activo, drenando, fuera de línea)
- 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 de Clientes de AI
Una biblioteca de clientes de AI proporciona una reconexión sin interrupciones:
- Escucha las notificaciones de eliminación de servidores 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
Monitoreo de Salud
- Chequeos de salud activos en cada servidor a intervalos regulares
- Actualizaciones automáticas del balanceador de carga ante fallos del servidor
- Disparadores de auto-recuperación para servidores que no responden
- Seguimiento de uptime y reporte de disponibilidad
Características Clave
- Orquestadores Duales — Escalado independiente para clusters de ingesta y distribución
- Cero Pérdida de Paquetes — Apagado controlado de 5 fases con migración de trabajadores de AI
- URLs Estables — El enrutamiento basado en DNS asegura que las URLs nunca cambian durante el escalado
- Reconexión de Trabajadores de AI — Migración basada en checkpoints con una brecha de ~3 segundos y cero pérdida de frames
- Escalado Independiente — La ingesta y la distribución escalan basándose en sus propias métricas
- Registro de Servicios — Coordinación basada en Redis para el estado del servidor y el mapeo de streams
- Monitoreo de Salud — Chequeos activos con recuperación automática
- Optimización de Costos — Reducción automática de escala durante períodos de baja demanda
Resultados
Stack Tecnológico
caseStudyDetail.more Casos de Estudio
Explore más de nuestras implementaciones técnicas
Procesamiento de Facturas Potenciado por AI con OCR e Integración con QuickBooks
Una empresa de tamaño mediano que procesa cientos de facturas de proveedores mensualmente necesitaba eliminar la entrada de datos manual extrayendo automáticamente los datos de las facturas usando AI/OCR y sincronizándolos directamente en QuickBooks para la contabilidad y el seguimiento de pagos.
Inserción de Anuncios en el Lado del Cliente (CSAI) con Análisis de Marcadores SCTE-35 e Integración de Reproductor Multiplataforma
Una plataforma de streaming de video necesitaba implementar la Inserción de Anuncios en el Lado del Cliente (CSAI) en sus aplicaciones web, móviles y de TV conectada, lo que permitiría experiencias publicitarias personalizadas a nivel de dispositivo con soporte completo para la interacción con anuncios (superposiciones clicables, banners complementarios, botones para omitir) que la inserción del lado del servidor no puede proporcionar.
¿Listo para Transformar su Negocio?
Hablemos sobre cómo podemos aplicar soluciones similares a sus desafíos.