Um sistema distribuído, escalável e resiliente para agendamento e processamento de tarefas genéricas, desenvolvido como Trabalho de Conclusão de Curso (TCC) em Ciência da Computação. Embora o protótipo valide o conceito através do monitoramento de serviços web (health checks), a arquitetura foi projetada para ser uma plataforma flexível, capaz de suportar diversos tipos de trabalhos em um ambiente de alta performance.
No cenário atual de microsserviços, a necessidade de executar tarefas agendadas, que vão desde verificações de disponibilidade até processamento de dados e envio de relatórios, é onipresente. No entanto, a construção de um agendador que seja ao mesmo tempo escalável (capaz de lidar com milhares de tarefas) e resiliente (tolerante a falhas de nós individuais) é um desafio de engenharia complexo.
O SentryWeb foi projetado para resolver esse problema. Utilizando uma arquitetura de microsserviços orquestrada com Kubernetes e desacoplada por um message broker RabbitMQ, o sistema oferece uma plataforma robusta para o agendamento e a execução de qualquer tipo de tarefa. A solução é nativa da nuvem, projetada para ser gerenciada por ferramentas de GitOps como o ArgoCD e monitorada opcionalmente pelo Prometheus, garantindo que, mesmo com o aumento da carga ou a falha de componentes, as tarefas sejam distribuídas e processadas de forma eficiente e confiável.
- Plataforma de Tarefas Genéricas: A arquitetura é extensível, permitindo a criação de diferentes tipos de
workerspara executar qualquer operação, bastando definir umtask_typee umpayloadcorrespondente. - Agendamento Distribuído e Resiliente: Múltiplas instâncias do
Schedulerpodem rodar em paralelo. As tarefas são distribuídas entre eles usando um algoritmo de hash consistente, garantindo que não haja um ponto único de falha. - Processamento Paralelo e Escalável: O
Workeré um serviço stateless que processa tarefas em paralelo usando um pool de threads, permitindo o processamento de um grande volume de mensagens. - Autoescalonamento Inteligente (HPA): O sistema utiliza o Horizontal Pod Autoscaler do Kubernetes com duas estratégias:
- Scheduler: Escala com base em métricas de CPU/Memória, ideal para um serviço stateful.
- Worker: Escala com base em métricas de negócio customizadas (mensagens na fila do RabbitMQ), uma abordagem muito mais eficiente que o simples uso de CPU para cargas de trabalho I/O-bound.
- Comunicação Assíncrona e Desacoplada: O uso do RabbitMQ garante que
SchedulerseWorkersoperem de forma independente, aumentando a resiliência e a flexibilidade do sistema. - Sincronização Dinâmica: Os
Schedulersse mantêm sincronizados em tempo real, detectando novas tarefas e mudanças no número de réplicas sem a necessidade de reinicialização.
O SentryWeb opera com base em uma arquitetura de microsserviços, onde cada componente tem uma responsabilidade clara e se comunica de forma assíncrona.
- Inserção de Tarefas: Um script (
insert_task.py) insere uma nova tarefa no banco de dados PostgreSQL e publica uma notificação em uma exchange do tipofanoutno RabbitMQ. - Sincronização dos Schedulers: Todas as instâncias ativas do Scheduler Service recebem a notificação da nova tarefa. Cada uma aplica um algoritmo de hash (
task_uuid % total_schedulers) para determinar qual delas é a "dona" da tarefa. O Scheduler responsável a adiciona à sua fila de prioridade interna (um min-heap baseado em tempo). - Agendamento: O
Scheduler"dono" da tarefa aguarda o momento certo e publica a tarefa em uma fila de trabalho (tasks) no RabbitMQ. - Processamento pelos Workers: Uma instância disponível do Worker Service consome a mensagem da fila
tasks. O Worker utiliza umThreadPoolExecutorpara processar múltiplas tarefas concorrentemente. - Execução: A thread do Worker executa a operação definida (no caso do protótipo, um health check de URL) e, ao final, envia um
ACKpara o RabbitMQ, confirmando que a tarefa foi concluída com sucesso. - Orquestração e Escalabilidade: Todo o sistema é conteinerizado com Docker e implantado no Kubernetes. O HPA monitora a carga de trabalho (CPU no Scheduler, mensagens na fila para o Worker) e ajusta o número de réplicas de cada serviço automaticamente.
- Backend: Python
- Orquestração: Kubernetes, Docker, Helm
- Mensageria: RabbitMQ
- Banco de Dados: PostgreSQL
- CI/CD: GitHub Actions (CI), ArgoCD (CD)
- Monitoramento: Prometheus, Grafana
- Infraestrutura: Manifests YAML para Kubernetes
Para executar o SentryWeb, é necessário ter um ambiente com Docker e Kubernetes (como Minikube ou Docker Desktop) configurado, além do Helm.
git clone [https://github.com/BrennoKM/SentryWeb.git](https://github.com/BrennoKM/SentryWeb.git)Antes de implantar a aplicação, é necessário criar os segredos e as configurações iniciais do banco de dados no seu cluster.
# Crie os segredos para RabbitMQ e PostgreSQL
kubectl apply -f deploy/secrets/
# Crie o ConfigMap com o script de inicialização do banco
kubectl apply -f deploy/configmap/O projeto utiliza um Helm Chart para gerenciar a implantação de todos os componentes (Scheduler, Worker) e suas dependências (PostgreSQL, RabbitMQ).
# Navegue até o diretório do chart
cd deploy/helm/sentryk8s
# Instale o chart no seu cluster
helm install sentryweb . --namespace sentryk8s --create-namespaceApós a implantação, utilize os scripts na pasta `src/scripts` para popular o banco de dados com tarefas de monitoramento.
# Exemplo de como executar o script (requer conexão com o DB)
python src/scripts/insert_tasks_from_json.py- API de Gerenciamento: Desenvolver um serviço de API (ex: em Flask ou FastAPI) para gerenciar o CRUD de tarefas de forma programática, em vez de usar scripts.
- Dashboard de Visualização: Criar uma interface web (frontend) para visualizar o status dos serviços em tempo real e o histórico de execuções.
- Workers Especializados: Implementar novos tipos de
workerspara executar outras tarefas, como envio de e-mails, processamento de imagens ou ETLs simples. - Métricas Detalhadas: Coletar e expor métricas de tempo de resposta (latência) de cada serviço monitorado.