A transformação da Central: de 'Push' para 'Pull'
Neste artigo, embarcaremos em uma exploração da revisão da arquitetura do sistema de vigilância por vídeo Watcher. Realizamos uma mudança de paradigma, passando de uma metodologia orientada para ‘push’ para gerenciar configurações e eventos para a adoção de uma abordagem centrada em ‘pull’. Essa transformação não apenas simplificou nosso código, mas também aliviou a carga operacional associada à supervisão do sistema de vigilância por vídeo. Além disso, melhorou substancialmente o desempenho e introduziu uma camada adicional de estabilidade ao repositório, especialmente em cenários que envolvem vários servidores.
A configuração original do Watcher e sua evolução
Vamos voltar no tempo e mergulhar nas origens da arquitetura do Watcher. No passado, o Watcher consistia em dois principais componentes de software: o próprio núcleo do Watcher e o confiável Flussonic Media Server. O Watcher, o centro cognitivo das operações, desempenhou um papel indispensável na orquestração dos intricados fundamentos do sistema. Ele protegia dados críticos sobre câmeras, perfis de usuário e permissões. Além disso, o Watcher tinha a responsabilidade fundamental de enviar configurações e ajustes para o Flussonic Media Server, que, por sua vez, atuava como um servidor de transmissão, capturando transmissões de câmeras, gerenciando arquivos de vídeo e tomando decisões sobre a retenção ou exclusão de segmentos de vídeo.
Figura 1. Arquitetura Anterior do Watcher sem a Central
A arquitetura do Watcher para gerenciar configurações e eventos baseava-se em uma metodologia de “push”. Sob esse quadro, uma entidade central iniciava a transmissão de configurações para um sistema de prestação de serviços. Em nosso cenário específico, o Flussonic Media Server atuava como provedor de serviços, enquanto o Watcher desempenhava o papel de maestro.
O Watcher assumia a responsabilidade pela gestão de transmissões no servidor de mídia, supervisionando tarefas como criação, exclusão e transmissão de transmissões por meio de chamadas de API. Um enfoque semelhante era aplicado à gestão de arquivos. Para proteger eventos cruciais contra exclusão prematura, o Watcher usava comandos de API para definir e remover “travas” dentro do arquivo. Essas travas serviam como marcadores, estendendo significativamente a vida útil de segmentos de arquivo específicos muito além da duração convencional. Essa função desempenhou um papel fundamental na redução significativa do uso de disco, frequentemente resultando em reduções significativas.
À medida que o número de câmeras e seus respectivos servidores de mídia continuava a aumentar, a necessidade de sincronizar estados entre os nós em um cluster tornou-se proeminente. Essa situação é um desafio comum em sistemas distribuídos. Garantir a execução bem-sucedida de comandos, seja enviando uma transmissão ou protegendo o conteúdo do arquivo contra exclusão, tornou-se primordial. Além disso, considerando o potencial de falhas no servidor de transmissão e sua posterior restauração a partir de backups, tornou-se imperativo garantir sua sincronização com as configurações mais recentes.
Na tentativa de abordar esses desafios, a arquitetura começou a seguir um caminho complicado, exigindo sacrifícios em termos de eficiência e elegância. O Watcher começou a executar operações em grande escala centradas na sincronização de estados, incluindo a transferência de configurações e a gestão de estados por meio de comandos como “bloquear este segmento no arquivo” (DVR_LOCK). Isso se tornou necessário para fortalecer o sistema contra uma fragilidade indevida, o que levou à introdução da funcionalidade indispensável de “limpar cache”. A consequência foi um impacto notável no desempenho tanto do Flussonic Media Server quanto de todo o sistema como uma entidade coesa.
Figura 2. Gráfico de telemetria: chamadas de API e tempos de execução de chamadas de API do cliente Watcher. Desafios de chamadas de API em junho
O gráfico superior, que representa a frequência das chamadas, ilustra um padrão oscilatório discernível de 09/06 a 29/06. Durante esse período, o cliente estava em um estado de agitação devido a um influxo não regulado de solicitações de API. Em particular, as solicitações destinadas a bloquear segmentos de arquivos (“stream_dvr_lock_save”) contribuíram significativamente para esse influxo.
Esse aumento nas solicitações estava diretamente relacionado à eficiência da API do Flussonic Media Server, resultando em desempenho subótimo. O gráfico inferior enfatiza ainda mais essa preocupação, mostrando um aumento notável no número de solicitações de API que levam mais de um segundo para serem processadas. Essa lentidão teve um efeito cascata em todo o sistema, resultando em uma desaceleração marcante das operações.
Esforços e desafios de otimização dentro da abordagem push
Em resposta às preocupações do cliente, lançamos uma nova versão em julho, com o objetivo de ajustar o volume de solicitações de API para o Flussonic Media Server por meio do Watcher dentro do modelo push.
Figura 3. Gráfico de telemetria: chamadas de API e tempos de execução de chamadas de API do cliente Watcher. Otimização de chamadas de API no modelo PUSH
O gráfico ilustra uma acentuada “suavização” das tendências em julho. O número de solicitações diminuiu, assim como seus tempos de processamento. No entanto, essa melhoria, embora notável, não proporcionou um alívio significativo no desempenho do sistema.
Por meio de nossa pesquisa aprofundada, chegamos à conclusão de que estender o modelo push para a gestão de configurações tinha limitações inerentes. Para ser preciso, exigia uma alocação maior de recursos e um investimento de tempo maior para desenvolvimento e ajuste. Isso se deveu principalmente ao requisito da abordagem push de armazenar um volume significativo de dados de estado, tornando-os intrinsecamente frágeis.
Um novo orquestrador e uma mudança de paradigma: PUSH versus PULL em configuração e gerenciamento de eventos
Reconhecendo a intensidade de recursos de nossos esforços para otimizar o modelo push, tomamos uma decisão transcendental de renovar nossa abordagem de gerenciamento de configuração. Essa transformação foi dupla. Em primeiro lugar, extraímos as funções de orquestração e as consolidamos em um sistema central separado. Em segundo lugar, mudamos da metodologia tradicional “push” para um modelo “pull” mais inovador.
Figura 4. A Nova Arquitetura do Watcher Adotando a Central
Vamos desmontar essa transformação. A Central assumiu a responsabilidade de manter um conhecimento abrangente do estado dos streamers ou Flussonic Media Servers. A necessidade de gerenciar esse estado no nível individual do servidor de mídia foi eliminada. A Central agora serve como epicentro onde o conhecimento do estado e os detalhes abrangentes da configuração encontram seu lugar.
No paradigma atual, o Flussonic Media Server “extrai” configurações atualizadas da Central, que agora atua como repositório de conhecimento do estado. Isso marca uma mudança fundamental na expectativa passiva de atualizações “push” externas. Essa abordagem estabelece um repositório unificado de armazenamento de informações do estado, permitindo que várias instâncias do Flussonic Media Servers obtenham essas informações conforme necessário. A questão está na transição do complexo e intrincado sistema de push para um processo constante de extração regular do estado desejado.
No passado, atualizar (pushing) o estado em cada nó dentro de um cluster de servidores de mídia exigia intervenção física, com visitas a cada nó para migração e sincronização de configurações. Monitoramento rigoroso era essencial não apenas para tentativas fracassadas de acessar o servidor de mídia, mas também para servidores que sofriam reversões repentinas ou reconfigurações manuais. Atualmente, em vez de percorrer vários nós para alinhar o estado, as informações de estado estão centralizadas na Central. Todos os nós recuperam essas informações da Central assim que estiverem prontos. Como resultado, a última configuração chega ao servidor de streaming em questão de segundos.
PUSH versus PULL na gestão de arquivos
Da mesma forma, mudamos de ‘push’ para ‘pull’ na gestão de arquivos. Inicialmente, fizemos a transição para o mecanismo de armazenar episódios em vez de segmentos individuais. Anteriormente, o bloqueio de segmentos no arquivo (DVR_LOCK) era gerenciado pelo Watcher, onde cada segmento no sistema de arquivos era marcado como “bloqueado”. Agora, o Flussonic solicita (extrai) informações da Central sobre quais episódios devem ser mantidos.
Agora, quando o Watcher tenta salvar ou bloquear um episódio, ele interage com a Central. A Central simplesmente registra os detalhes no banco de dados. Esse processo consome muito menos recursos em comparação com as operações que envolvem discos físicos.
O banco de dados da Central abriga informações completas sobre cada episódio, incluindo o início e o fim, e potencialmente inclui elementos adicionais como visualizações prévias, capturas de tela e outros detalhes variados. O conteúdo real de vídeo e áudio encontra seu repositório no nó mais adequado dentro do cluster. O próprio grupo determina a localização ideal.
Além disso, essa metodologia é consideravelmente mais econômica em comparação com a prática anterior de “bloquear” segmentos em três ou mais discos de servidor Flussonic. Para esclarecer, antes dessa transformação, éramos obrigados a navegar por três servidores de mídia diferentes, procurar o segmento apropriado em um dos discos e manipular o sistema de arquivos para aplicar o bloqueio. No entanto, com a chegada do Flussonic Media Server, tudo o que é necessário é uma única entrada no banco de dados central. Posteriormente, cada Flussonic Media Server, mesmo que seu número chegue a mil, recebe a diretiva da Central. A Central informa quais segmentos precisam ser bloqueados e deixa o restante para ser excluído.
Em agosto, nosso cliente adotou uma nova configuração do Watcher, incorporando o orquestrador central junto com uma nova abordagem baseada em extração para monitorar configurações (estados), transmissores e arquivos.
Figura 5. Chamadas de API e gráfico de tempo de chamadas de API: grande mudança após a transição para a Central em agosto
Na parte superior do gráfico, você poderá observar como o número de solicitações de API assumiu um padrão quase “linear” e previsível, especialmente em relação às solicitações relacionadas ao bloqueio de arquivos. Ao mesmo tempo, o gráfico a seguir mostra a “suavidade” do tempo de execução dessas solicitações de API.
Em resumo, com a participação da Central e a adoção da abordagem baseada em extração, nosso cliente agora desfruta dos benefícios de um fluxo previsível e bem regulamentado de solicitações de API e seus tempos de processamento. Essa transformação levou a uma redução no consumo de recursos de rede, reduzindo pela metade a memória e as cargas de trabalho da CPU. Além disso, graças à metodologia ‘baseada em extração’, um maior grau de estabilidade nas operações de arquivo foi alcançado.
Conclusões:
-
Para aqueles entre os clientes do Watcher que têm reservas sobre a transição para a Central, talvez se perguntem: “Por que mudar o que está funcionando efetivamente?” - Permita-nos assegurar-lhes que tal hesitação pode não estar justificada. Exemplos do mundo real de nossos clientes servem como testemunho tangível das notáveis melhorias no desempenho, especialmente para configurações abrangentes que envolvem várias câmeras e transmissores.
-
A adoção da abordagem centrada em extração, juntamente com o mecanismo centrado em episódios integrado na Central, não apenas reduz os custos associados à gestão de arquivos, mas também fortalece os arquivos contra contratempos imprevistos. Essa resiliência é baseada no fato de que os metadados do arquivo agora residem em um banco de dados central dedicado, enquanto o conteúdo real do arquivo é armazenado no nó mais adequado dentro do cluster.
-
Além disso, essa mudança de paradigma abre caminho para hospedar um maior número de câmeras em um único servidor de mídia.
-
Como cereja do bolo, a abordagem baseada em extração da Central torna a infraestrutura do transmissor (servidores de mídia) sem estado. Isso, por sua vez, se traduz em um funcionamento mais suave do sistema de vigilância por vídeo, especialmente em um ambiente baseado em contêineres na nuvem, semelhante aos encontrados no Kubernetes.