Resumo Executivo

Gustavo Jose Gomes Meilus; Marcos Jardel Henriques

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

O cenário contemporâneo da rede mundial de computadores caracteriza-se por uma transição acelerada de páginas estáticas para ecossistemas digitais altamente dinâmicos e complexos. Essa evolução é impulsionada pela necessidade de oferecer interfaces mais impactantes e de rápido consumo, utilizando ferramentas avançadas que priorizam a performance visual e a interatividade em tempo real (Udapure et al., 2014). Nesse contexto, a predominância de conteúdos que se transformam instantaneamente, como redes sociais, portais de notícias de última hora e, especialmente, mapas de ameaças de segurança cibernética, impõe desafios significativos para a coleta automatizada de dados. A captura de informações em tais ambientes exige que os sistemas de extração não apenas acessem o código-fonte, mas interpretem o comportamento da página de maneira similar a um usuário humano, garantindo que a frequência de aquisição esteja em perfeita sintonia com a volatilidade dos dados apresentados (Kim et al., 2012).

A necessidade de obter e processar informações de páginas com conteúdo dinâmico demanda o emprego de técnicas sofisticadas de web crawling. Diferente dos rastreadores tradicionais, que muitas vezes falham ao lidar com elementos renderizados via JavaScript, as soluções modernas precisam simular ações humanas, como cliques e rolagens, para disparar eventos que carregam os dados desejados. O uso de ferramentas capazes de ler e navegar por essas estruturas permite que o sistema receba feedback em tempo real, tornando a aquisição de dados um processo fluido e escalável (Cachão, 2024). A justificativa para o desenvolvimento de arquiteturas robustas reside na importância estratégica desses dados para a tomada de decisão, onde a eficiência na captura e o processamento assíncrono tornam-se pilares para a sustentação de aplicações de monitoramento contínuo. O objetivo central reside na criação de uma aplicação que execute a navegação, a busca e a aquisição de dados dinâmicos disponibilizados em tempo real, focando especificamente em plataformas que exibem informações críticas sobre ameaças de segurança e ataques cibernéticos globais.

Para fundamentar a construção de tal sistema, é imperativo compreender a modularidade proporcionada pela arquitetura de microsserviços. Esse modelo permite que diferentes componentes da aplicação operem de forma independente, facilitando a manutenção e a escalabilidade horizontal. A escolha de uma estrutura baseada no padrão produtor-consumidor, utilizando filas de tarefas, garante que a carga de trabalho seja distribuída de maneira equilibrada, evitando gargalos que poderiam comprometer a integridade da coleta em ambientes de alto fluxo de informações. A integração de tecnologias de ponta para a automação de navegadores e o gerenciamento de tarefas assíncronas constitui a base teórica e prática para enfrentar a instabilidade inerente às páginas web modernas, onde a latência da rede e as atualizações constantes de conteúdo exigem uma resposta ágil e resiliente do sistema de crawling.

A metodologia aplicada para a construção da arquitetura de coleta contínua fundamenta-se em um ecossistema de ferramentas integradas sob a linguagem de programação Python. O núcleo da aplicação é estruturado em torno do FastAPI, selecionado por sua alta performance e capacidade de gerar documentação interativa de forma automática, além de oferecer validação rigorosa de dados e integração nativa com bancos de dados modernos (Santos et al., 2024). O FastAPI atua como a interface de controle, permitindo interações via protocolo HTTP através de métodos padronizados. Foram implementadas rotas específicas para o controle do ciclo de vida do crawler, incluindo o método POST para iniciar a extração, GET para verificar o status e os resultados, e DELETE para interromper os processos. Adicionalmente, uma rota denominada tarefas concentra as ferramentas de gerenciamento global, permitindo a alteração da execução de todos os processos de forma centralizada.

O processamento das tarefas de extração é delegado ao Celery, que gerencia a execução assíncrona e a distribuição dos processos em segundo plano. Essa escolha técnica permite que a aplicação suporte tarefas de longa duração sem bloquear a interface principal, garantindo a extensibilidade necessária para operações paralelas (Andrade, 2024). Como agente de mensagens para o Celery, utiliza-se o Redis, que armazena as mensagens em fila e facilita a comunicação eficiente entre os diversos microsserviços. A automação do navegador, etapa crítica para a interação com o conteúdo dinâmico, é realizada pelo Playwright. Esta ferramenta destaca-se pela capacidade de interagir com páginas que dependem fortemente de Javascript para renderização, oferecendo suporte a múltiplos navegadores e funções que mimetizam com precisão o comportamento de um usuário real (Brito et al., s.d.). O Playwright instancia o navegador Chromium através do padrão de projeto Método Fábrica, o que confere uma camada de abstração necessária para a criação de objetos e a atribuição de responsabilidades dentro das tarefas gerenciadas pelo Celery (Sturm e Silva, 2014).

Para a manipulação das páginas e organização do código, aplica-se o padrão Page Object Model, que modela as páginas web em classes específicas. Essa abordagem promove a reusabilidade do código e facilita a manutenção, uma vez que as alterações na estrutura da página alvo exigem modificações apenas na classe correspondente. A tarefa de captura envolve a navegação até o endereço eletrônico alvo, a extração do conteúdo dinâmico e a gravação dos dados em formato JSON. O armazenamento é realizado no MongoDB, um sistema de banco de dados NoSQL de esquema flexível. A escolha do MongoDB justifica-se pela sua capacidade de adaptar-se a diferentes estruturas de dados sem a necessidade de migrações complexas, permitindo que a aplicação evolua conforme novas informações são incorporadas ao processo de extração (Souza e Oliveira, 2019). Os documentos salvos incluem a descrição do ataque, o tipo de ameaça, a localização de origem e destino, o tempo exibido na página e a marca temporal da extração.

A infraestrutura do sistema é complementada por um gateway configurado no Nginx, que desempenha as funções de balanceador de carga e proxy reverso. Essa configuração assegura que as requisições sejam encaminhadas corretamente para as múltiplas instâncias dos serviços, promovendo a observabilidade e a segurança na comunicação entre agentes internos e externos. Todo o ecossistema é conteinerizado utilizando Docker, o que garante o isolamento das dependências, a paridade entre ambientes de desenvolvimento e produção e a facilidade de implantação. Os serviços interconectados, como FastAPI, Celery, Redis e MongoDB, operam em redes internas seguras, com volumes de dados persistentes para garantir a integridade das informações armazenadas (Serra Junior e Lima, n.d.). Para o monitoramento e a visualização dos serviços, utilizam-se as ferramentas Flower, Kibana e Elasticsearch, que permitem a análise detalhada dos logs estruturados e das métricas de desempenho em tempo real.

A validação da arquitetura exigiu a criação de um ambiente de testes controlado, uma vez que páginas públicas possuem fluxos inconstantes e são suscetíveis a falhas externas. Para isso, desenvolveu-se uma página local utilizando o framework Flask, projetada para emular o comportamento de um mapa de ameaças real. O Flask, por ser um framework leve e flexível, permitiu a implementação de uma lógica que gera dados aleatórios em intervalos variados, simulando períodos de inatividade e picos de até quatro novas informações simultâneas (Ghimire, 2020). A página de teste gera entradas contendo o tipo de ameaça, o nome do ataque, o tempo de ocorrência e as localizações geográficas, com intervalos de atualização variando entre 0,5 segundo e 3,0 segundos. Esse ambiente permitiu comparar os dados capturados pelo crawler com um arquivo de log contendo todas as entradas geradas, possibilitando o cálculo preciso da eficiência da captura.

A estratégia de captura adotada consiste na aquisição de dados em pacotes durante intervalos de tempo pré-definidos. O sistema captura todas as entradas presentes na tela no momento da execução, o que aumenta a probabilidade de obter todos os dados, mas gera uma quantidade significativa de duplicatas. Para resolver esse problema, implementou-se uma lógica de comparação que verifica se o dado extraído já existe no banco de dados antes de realizar a inserção. Essa abordagem garantiu a consistência das informações mesmo em cenários de alta frequência de atualização. Para medir o desempenho, foram estabelecidas métricas fundamentais: a taxa de captura, definida pela razão entre novas entradas inseridas e o total de entradas geradas; a taxa de duplicatas, que mede a quantidade de dados repetidos ignorados; a taxa de erros, que identifica entradas perdidas; e a taxa de captura pelo tempo, que relaciona o volume de dados únicos ao intervalo total da operação.

Os resultados obtidos através dos testes de performance revelam um comportamento dinâmico da arquitetura frente a diferentes configurações de intervalo de captura. Foram realizados 10 ensaios distintos, cada um com duração de 10 minutos, variando o intervalo entre as coletas de 50 milissegundos até 1000 milissegundos. No primeiro ensaio, com um intervalo de 50 milissegundos, a aplicação atingiu uma taxa de captura de 98,95%, o valor mais alto registrado. Nesse cenário, foram processadas 847 entradas únicas, com uma taxa de duplicatas de 96,82% e uma taxa de erros de apenas 1,05%. O uso de CPU durante esse processo foi de 24,7%, refletindo a alta carga de processamento necessária para manter a frequência intensa de verificações. Esses dados demonstram que, para garantir a quase totalidade da captura em ambientes de altíssima volatilidade, o sistema precisa operar com redundância elevada, processando repetidamente as mesmas informações para assegurar que nenhuma atualização seja perdida entre os ciclos.

Ao aumentar o intervalo de captura para 100 milissegundos no segundo ensaio, observou-se uma leve redução na taxa de captura para 97,35%, enquanto a taxa de duplicatas caiu para 91,23% e a taxa de erros subiu para 2,65%. O consumo de CPU reduziu para 22,8%. Essa tendência de declínio na eficiência da captura e aumento nos erros prosseguiu conforme os intervalos se tornaram maiores. No quinto ensaio, com intervalo de 300 milissegundos, a taxa de captura situou-se em 91,70%, com 48,56% de duplicatas e 8,30% de erros, utilizando 14,5% da CPU. Nota-se que, mesmo com um intervalo seis vezes maior que o inicial, a aplicação ainda conseguiu capturar mais de 90% dos dados, sugerindo uma resiliência considerável da arquitetura. Entretanto, o aumento na taxa de erros indica que informações começaram a ser perdidas, pois o tempo de permanência de alguns dados na página de teste era inferior ao intervalo de varredura do crawler.

A degradação do desempenho tornou-se mais evidente nos ensaios finais. No oitavo ensaio, com intervalo de 600 milissegundos, a taxa de captura caiu drasticamente para 72,79%, e a taxa de erros saltou para 27,21%. O volume de duplicatas reduziu para 11,45%, e o uso de CPU estabilizou em 11,2%. O ponto crítico foi atingido no décimo ensaio, com um intervalo de 1000 milissegundos (um segundo). Nesse cenário, a taxa de captura foi de apenas 45,86%, o que significa que mais da metade das informações geradas pela página alvo não foram registradas pelo sistema. A taxa de erros atingiu 54,14%, enquanto as duplicatas caíram para 10,73% e o uso de CPU para 9,6%. Esses resultados evidenciam um trade-off claro entre a carga aplicada ao sistema e a integridade dos dados coletados. Para páginas onde a informação é efêmera e atualizada em frações de segundo, intervalos superiores a 500 milissegundos mostram-se inadequados, resultando em perdas de dados inaceitáveis para sistemas de monitoramento crítico.

A análise comparativa dos dados permite inferir que a eficiência da arquitetura está intrinsecamente ligada à sua capacidade de processar grandes volumes de dados repetidos para garantir a captura de novos registros. A alta taxa de duplicatas observada nos intervalos menores (acima de 90% nos dois primeiros ensaios) não deve ser vista como uma ineficiência do sistema, mas como uma margem de segurança necessária para a operação em tempo real. A lógica de comparação implementada no MongoDB mostrou-se eficaz ao filtrar essas duplicatas sem comprometer a performance global, mantendo a consistência do banco de dados. A utilização do Kibana para a visualização dessas métricas permitiu identificar que o tempo de resposta da API e o tempo de processamento das tarefas permaneceram estáveis, mesmo sob a carga máxima do intervalo de 50 milissegundos, o que valida a escolha do FastAPI e do Celery como componentes centrais da solução.

A discussão dos resultados aponta para a necessidade de otimização contínua em trabalhos futuros. Embora a taxa de captura de 98,95% seja excelente, a dependência de intervalos tão curtos eleva o consumo de recursos. Uma alternativa viável seria a implementação de múltiplas instâncias da tarefa de captura rodando em paralelo, mas com pequenos deslocamentos temporais entre elas. Isso poderia permitir que o sistema cobrisse os intervalos de tempo de forma mais granular sem sobrecarregar uma única instância do navegador. Além disso, a observação de que intervalos maiores reduzem drasticamente a eficácia sugere que o sistema poderia se beneficiar de algoritmos de detecção de fluxo, que ajustariam o intervalo de captura dinamicamente com base na velocidade de atualização detectada na página alvo. Essa adaptabilidade tornaria a arquitetura mais robusta para diferentes cenários, desde portais de notícias com atualizações moderadas até mercados financeiros e mapas de ameaças com fluxos intensos.

As limitações encontradas durante o estudo residem principalmente na natureza da página de teste, que, embora emule o comportamento real, opera em um ambiente de rede local sem as latências e instabilidades típicas da internet pública. Em um cenário real, fatores como bloqueios de IP, mudanças súbitas na estrutura do Document Object Model (DOM) e variações na velocidade de carregamento de scripts externos poderiam impactar as taxas de captura. No entanto, a base tecnológica escolhida, especialmente o uso do Playwright com o padrão Page Object Model, oferece as ferramentas necessárias para mitigar esses problemas através de técnicas de espera inteligente e tratamento de exceções. A modularidade da arquitetura permite que novos componentes de segurança e anonimização sejam adicionados sem a necessidade de reestruturar todo o sistema, reforçando o caráter escalável da solução proposta.

A integração de ferramentas de observabilidade como o Flower e o Elastic Stack provou ser fundamental para a compreensão do comportamento do sistema. Através dos dashboards, foi possível visualizar a correlação direta entre o intervalo de captura e o uso de CPU, bem como identificar o momento exato em que a taxa de erros começava a superar a taxa de captura. Essa visibilidade é crucial para a operação de sistemas em produção, onde a detecção precoce de falhas na coleta pode evitar a perda de dados estratégicos. A arquitetura demonstrou que é possível construir um sistema de web crawling capaz de lidar com a volatilidade da web moderna, desde que se utilize uma abordagem baseada em processamento assíncrono, microsserviços e ferramentas de automação de navegador de alto nível.

Conclui-se que o objetivo foi atingido, uma vez que a arquitetura desenvolvida demonstrou capacidade técnica para realizar a captura contínua de dados em páginas dinâmicas com alta eficiência. A experimentação comprovou que, com um intervalo de 50 milissegundos, o sistema alcança uma taxa de captura próxima a 100%, validando a eficácia do padrão produtor-consumidor e do uso de microsserviços para garantir a escalabilidade e a modularidade. Apesar da alta taxa de duplicatas inerente ao processo de alta frequência, a lógica de filtragem e o armazenamento em banco de dados NoSQL garantiram a integridade das informações. O estudo identificou um trade-off crítico entre a frequência de coleta e a carga de processamento, fornecendo parâmetros claros para o ajuste do sistema em diferentes cenários de monitoramento em tempo real. Pesquisas futuras poderão explorar o ajuste dinâmico de intervalos e a execução paralela de instâncias para otimizar ainda mais o consumo de recursos sem comprometer a precisão da coleta.

Referências Bibliográficas:

Andrade, G.A. 2024. Implementação de uma Ferramenta Web para a Automação de Redes IP Utilizando Python. Trabalho de Conclusão de Curso. Universidade Federal de Uberlândia, Uberlândia, MG, Brasil.

Brito, A.B.; Santos, R.M.; Medeiros, S.N. 2025. Ferramentas de Testes: Um Estudo Comparativo entre Cypress, Playwright e Selenium Webdriver. Instituto Federal de Pernambuco.

Cachão, A.F. 2024. System redevelopment for competition results. Dissertação de Mestrado em Engenharia Informática. Universidade de Lisboa, Lisboa, Portugal.

Ghimire, D. 2020. Comparative study on Python web frameworks: Flask and Django. Bachelor’s Thesis in Media Engineering. Metropolia University of Applied Sciences.

Kim, K.S.; Kim, K.Y.; Lee, K.H.; Kim, T.K.; Cho, W.S. 2012. Design and implementation of web crawler based on dynamic web collection cycle. In: International Conference on Information Networking (ICOIN), 2012, Bali, Indonésia. Anais… p. 562-566.

Santos, B.C.; Rocha, G.S.; Cardoso, F.S.; Lima, K.L.; Sobrinho, A.F.G.A.; Torné, I.G.; Ono, I.M.F.; Cisneros, E.A.G. 2024. Desenvolvimento de uma arquitetura de software para um sistema de armário inteligente. Revista de Gestão e Secretariado – GeSec, 15(6), 01-20.

Serra Junior, F.C.; Lima, B.S.N.M. 2020. Tecnologia Docker: otimizando tempo e recursos no ambiente de desenvolvimento abordagem introdutória. (Artigo de conclusão de curso de MBA em Gestão de Projetos). Faculdade ISL Wyden.

Souza, E.C.; Oliveira, M.R. 2019. Comparativo entre os bancos de dados MySQL e MongoDB: quando o MongoDB é indicado para o desenvolvimento de uma aplicação. Interface Tecnológica, 16(2).

Sturm, J.; Silva, M.P. 2014. Aplicação de padrões de projeto no desenvolvimento de software para a melhoria da qualidade e da manutenibilidade. ResearchGate.

Udapure, T.V.; Kale, R.D.; Dharmik, R.C. 2014. Study of web crawler and its different types. IOSR Journal of Computer Engineering 16(1): 1-5.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy