La transformación de Central: de ‘Push’ a ‘Pull’
En este artículo, nos embarcaremos en una exploración de la revisión de la arquitectura del sistema de videovigilancia Watcher. Hemos ejecutado un cambio de paradigma, pasando de una metodología orientada a ‘push’ para gestionar configuraciones y eventos a la adopción de un enfoque centrado en ‘pull’. Esta transformación no solo simplificó nuestro código sino que también alivió la carga operativa asociada con la supervisión del sistema de videovigilancia. Además, mejoró sustancialmente su rendimiento e introdujo una capa adicional de estabilidad al repositorio, especialmente en escenarios que involucran múltiples servidores.
La configuración original de Watcher y su evolución
Retrocedamos el reloj y profundicemos en los orígenes del marco arquitectónico de Watcher. En la época pasada, Watcher constaba de dos componentes de software principales: el núcleo de Watcher en sí y el confiable Flussonic Media Server. Watcher, el centro cognitivo de operaciones, jugó un papel indispensable en la orquestación de los intrincados fundamentos del sistema. Protegió datos críticos sobre cámaras, perfiles de usuario y permisos. Además, Watcher tenía la responsabilidad fundamental de enviar configuraciones y ajustes a Flussonic Media Server, que, a su vez, funcionaba como un servidor de transmisión, capturando transmisiones de cámaras, administrando archivos de video y tomando determinaciones con respecto a la retención o eliminación de segmentos de video.
Figura 1. Anterior Arquitectura de Watcher sin Central
La arquitectura de Watcher para gestionar configuraciones y eventos se basó en una metodología de “push”. Bajo este marco, una entidad central inició la transmisión de configuraciones a un sistema de prestación de servicios. En nuestro escenario específico, Flussonic Media Server actuó como proveedor de servicios, mientras que Watcher asumió el papel de director de orquesta.
Watcher asumió la responsabilidad de la gestión de transmisiones en el servidor de medios, supervisando tareas como la creación, eliminación y transmisión de transmisiones a través de llamadas API. Se aplicó un enfoque similar a la gestión de archivos. Para proteger eventos cruciales contra un borrado prematuro, Watcher empleó comandos API para establecer y eliminar “bloqueos” dentro del archivo. Estos candados sirvieron como marcadores, extendiendo la vida útil de almacenamiento de segmentos de archivo particulares mucho más allá de la duración convencional. Esta función jugó un papel fundamental a la hora de reducir sustancialmente el uso del disco, lo que a menudo resultó en reducciones de magnitud.
A medida que el número de cámaras y sus correspondientes servidores de medios seguía aumentando, la necesidad de sincronizar los estados entre los nodos dentro de un clúster pasó a primer plano. Esta situación es un desafío común que se encuentra en los sistemas distribuidos. Garantizar la ejecución exitosa de los comandos, ya sea enviando una transmisión o protegiendo el contenido del archivo para que no se elimine, se volvió primordial. Además, considerando el potencial de fallas dentro del servidor de transmisión y su posterior restauración a partir de copias de seguridad, se volvió imperativo garantizar su alineación con las configuraciones más actuales.
En un esfuerzo por abordar estos desafíos, la arquitectura comenzó a tomar una trayectoria complicada, requiriendo sacrificios en términos de eficiencia y elegancia. Watcher comenzó a ejecutar a gran escala operaciones centradas en la sincronización de estados, incluida la transferencia de configuraciones y la gestión de estados mediante comandos como “bloquear este segmento en el archivo” (DVR_LOCK). Esto se hizo necesario para fortalecer el sistema contra una fragilidad indebida, lo que provocó la introducción de la indispensable funcionalidad de “restablecer caché”. La consecuencia fue un impacto notable en el rendimiento tanto del Flussonic Media Server como de todo el sistema como entidad cohesiva.
Figura 2. Gráfico de telemetría: llamadas API y tiempos de ejecución de llamadas API del cliente Watcher. Desafíos de llamadas API en junio
El gráfico superior, que representa la frecuencia de las llamadas, ilustra un patrón oscilatorio discernible del 09/06 al 29/06. Durante este período, el cliente se encontró en un estado de agitación debido a una afluencia no regulada de solicitudes de API. En particular, las solicitudes destinadas a bloquear segmentos de archivos (“stream_dvr_lock_save”) contribuyeron de manera importante a esta afluencia.
Este aumento en las solicitudes tuvo una relación directa con la eficiencia de la API de Flussonic Media Server, lo que resultó en un rendimiento subóptimo. El gráfico inferior acentúa aún más esta preocupación, ya que muestra un aumento notable en la cantidad de solicitudes de API que tardan más de un segundo en procesarse. Esta lentitud tuvo un efecto dominó en todo el sistema, traduciéndose en una marcada desaceleración de las operaciones.
Esfuerzos y desafíos de optimización dentro del enfoque push
En respuesta a las aprensiones del cliente, presentamos una nueva versión en julio, con el objetivo de ajustar el volumen de solicitudes de API al Flussonic Media Server a través de Watcher dentro del marco push.
Figura 3. Gráfico de telemetría: llamadas API y tiempos de ejecución de llamadas API del cliente Watcher. Optimización de llamadas API dentro del modelo PUSH
El gráfico ilustra un pronunciado “suavizamiento” de las tendencias en julio. El recuento de solicitudes experimentó una reducción, al igual que sus tiempos de procesamiento. Sin embargo, esta mejora, aunque notable, no supuso un alivio significativo de la desaceleración del rendimiento del sistema.
A través de nuestra investigación en profundidad, llegamos a la conclusión de que extender el modelo push para la gestión de la configuración tenía limitaciones inherentes. Para ser precisos, exigió una mayor asignación de recursos y una mayor inversión de tiempo para el desarrollo y el ajuste. Esto se debió principalmente al requisito del enfoque push de almacenar un volumen significativo de datos estatales, lo que los hacía inherentemente frágiles.
Un nuevo orquestador y un cambio de paradigma: PUSH versus PULL en configuración y gestión de eventos
Reconociendo la naturaleza intensiva en recursos de nuestros esfuerzos para optimizar el modelo push, tomamos una decisión trascendental para renovar nuestro enfoque de gestión de configuración. Esta transformación fue doble. En primer lugar, extrajimos las funciones de orquestación y las consolidamos dentro de un sistema central distinto. En segundo lugar, pasamos de la metodología tradicional “push” a un modelo “pull” más innovador.
Figura 4. La nueva arquitectura de Watcher que adopta Central
Deconstruyamos esta transformación. Central ha asumido la responsabilidad de conservar un conocimiento exhaustivo del estado de los streamers o Flussonic Media Servers. Se ha obviado la necesidad de gestionar este estado a nivel de servidor de medios individual. Central sirve ahora como epicentro donde el conocimiento estatal y los detalles exhaustivos de la configuración encuentran su morada.
En el paradigma actual, Flussonic Media Server “extrae” configuraciones actualizadas de Central, que ahora sirve como depósito de conocimiento estatal. Esto marca un cambio fundamental en la espera pasiva de actualizaciones “push” externas. Este enfoque establece un repositorio unificado de almacenamiento de información estatal, lo que permite que múltiples instancias de Flussonic Media Servers obtengan esta información según sea necesario. La cuestión está en la transición del complejo e intrincado sistema de empuje a un proceso constante de extracción regular del estado deseado.
En el pasado, actualizar (pushing) el estado en cada nodo dentro de un clúster de servidores de medios requería intervención física, lo que requería visitas a cada nodo para la migración y sincronización de la configuración. Una estrecha supervisión era indispensable no sólo para los intentos fallidos de acceder al servidor de medios sino también para los servidores que sufrían reversiones repentinas o reconfiguraciones manuales. Actualmente, en lugar de atravesar varios nodos para alinear el estado, la información del estado está centralizada en Central. Todos los nodos recuperan esta información de Central tan pronto como estén preparados. En consecuencia, la última configuración llega al servidor de streaming en cuestión de segundos.
PUSH versus PULL en la gestión de archivos
De manera similar, pasamos de ‘push’ a ‘pull’ en la gestión de archivos. Inicialmente, hicimos la transición al mecanismo de almacenar episodios en lugar de segmentos individuales. Anteriormente, el bloqueo de segmentos en el archivo (DVR_LOCK) se administraba a través de Watcher, donde cada segmento en el sistema de archivos se marcaba como “bloqueado”. Ahora, Flussonic solicita (extrae) información de Central sobre qué episodios deben conservarse.
Ahora, cuando Watcher intenta guardar o bloquear un episodio, interactúa con Central. Central simplemente registra los detalles en la base de datos. Este proceso consume muchos menos recursos en comparación con las operaciones que involucran discos físicos.
La base de datos de Central alberga información completa sobre cada episodio, incluido su comienzo y conclusión, y potencialmente abarca elementos adicionales como vistas previas, capturas de pantalla y otros detalles variados. El contenido real de vídeo y audio encuentra su repositorio en el nodo más adecuado dentro del clúster. El propio grupo determina la ubicación óptima.
Además, esta metodología resulta notablemente más rentable en comparación con la práctica anterior de “bloquear” segmentos en tres o más discos de servidor Flussonic. Para aclararlo, antes de esta transformación, nos vimos obligados a navegar a través de tres servidores de medios distintos, buscar el segmento apropiado dentro de uno de los discos y manipular el sistema de archivos para aplicar el bloqueo. Sin embargo, con la llegada de Flussonic Media Server, todo lo que se requiere es una única entrada en la base de datos central. Posteriormente, cada Flussonic Media Server, incluso si su número llega a mil, recibe la directiva de la Central. Central les informa qué segmentos necesitan bloquearse y deja el resto para su eliminación.
La transición del cliente a la nueva configuración de Watcher con Central y el paradigma Pull
En agosto, nuestro cliente adoptó una nueva configuración de Watcher, incorporando el orquestador central junto con un nuevo enfoque basado en extracción para supervisar configuraciones (estados), transmisores y archivos.
Figura 5. Llamadas API y gráfico de tiempo de llamadas API: cambio significativo después de la transición a Central en agosto
En la parte superior del gráfico, podrás observar cómo el recuento de solicitudes de API ha asumido un patrón casi “lineal” y predecible, particularmente con respecto a las solicitudes relacionadas con el bloqueo de archivos. Al mismo tiempo, el siguiente gráfico muestra la “suavidad” del tiempo de ejecución de estas solicitudes de API.
En resumen, con la participación de Central y la adopción del enfoque basado en extracción, nuestro cliente ahora obtiene los beneficios de un flujo previsible y bien regulado de solicitudes de API y sus tiempos de procesamiento. Esta transformación ha llevado a una reducción en el consumo de recursos de la red, reduciendo a la mitad la memoria y las cargas de trabajo de la CPU. Además, gracias a la metodología ‘pull-based’, se ha conseguido un mayor grado de estabilidad en las operaciones de archivo.
Conclusiones:
-
Para aquellos entre la clientela de Watcher que albergan reservas sobre la transición a Central, tal vez se pregunten: “¿Por qué cambiar lo que funciona eficazmente?” - Permítanos asegurarles que tal vacilación puede no estar justificada. Los ejemplos del mundo real de nuestros clientes sirven como testimonio tangible de las notables mejoras en el rendimiento, especialmente para configuraciones amplias que abarcan múltiples cámaras y transmisores.
-
La adopción del enfoque centrado en la extracción, junto con el mecanismo centrado en episodios integrado en Central, no solo reduce los costos asociados con la gestión de archivos sino que también fortalece el archivo contra contratiempos imprevistos. Esta resiliencia se basa en el hecho de que los metadatos del archivo ahora residen dentro de una base de datos central dedicada, mientras que el contenido del archivo real se almacena en el nodo más adecuado dentro del clúster.
-
Además, este cambio de paradigma allana el camino para alojar un mayor número de cámaras en un único servidor de medios.
-
Como guinda del pastel, el enfoque orientado a la extracción de Central hace que la infraestructura del transmisor (servidores de medios) sea sin estado. Esto, a su vez, se traduce en un funcionamiento más fluido del sistema de videovigilancia, particularmente dentro de un entorno en contenedores basado en la nube, similar a los que se encuentran en Kubernetes.