Iremos apresentar sobre a migração entre arquiteturas de dados, de um modelo mais antigo baseado em Postgres e scripts PLSQL, para um modelo escalável e que visa redução de custos na AWS. Esta arquitetura é baseada em MongoDB e RabbitMQ, utilizando a linguagem Golang. Iremos explicar os motivos da migração e da escolha de tais ferramentas, bem como quais os problemas enfrentados e como foram resolvidos.
2. Kamila Hinckel
Desenvolvedora na Neoway
Graduada em Sistemas
Eletrônicos (IF-SC)
5 anos de experiência na área de
desenvolvimento de software
Desenvolvedor na Neoway
Graduado em Sistemas de
Informação (UFSC)
6 anos de experiência na área
de desenvolvimento de software
Olá!
Matheus Vill
8. O que fazemos?
Serviços de tratamento e enriquecimento de dados
Exemplos:
Apresentação do TDC -> APRESENTACAO DO TDC
DILMA VANA ROUSSEFF -> 133.267.246-91
9. O que fazemos?
Integração e disponibilização de dados
Exemplo:
Informações das empresas da Receita Federal
+
Informações dos sócios das Juntas Comerciais
10. O que fazemos?
Geração de histórico das fontes capturadas
Exemplos:
Dia 1: Nome da empresa -> Neoway
Dia 2: Nome da empresa -> Neoway Business
11. O que fazemos?
Criação de modelos estatísticos para qualificação e
predição
Exemplos:
- Nível de atividade de uma empresa
- Faturamento Presumido
13. ➔ Custo elevado e dificuldades para escalar;
➔ Atraso na disponibilização dos dados para as aplicações;
➔ Dificuldades para simular o ambiente existente;
➔ Dificuldade de mapear os impactos de alterações.
Problemas
16. Go, Rabbit e Mongo
Go
- Simples e leve
- Concorrência/paralelismo
- É demais!!!! :)
Rabbit
- Servidor de mensageria
- Filas e tópicos
- Persistência de mensagens
Mongo
- NoSQL
- Orientado à documento
- Não possui schema definido
- JSON como protocolo
21. O que ganhamos?
Tempo: Disponibilização dos dados de forma
contínua e integrada entre todas as aplicações.
Escalabilidade: Necessidade de escalar
horizontalmente devido ao aumento do número de
fontes capturadas.
Infraestrutura imutável: Scripts automatizados,
evitando máquinas “flocos de neve”.
Qualidade: Arquitetura orientada à testes
automatizados.
Custo: Possibilidade de redução de custos de infra.
23. Testes Unitários
Vantagens:
- Executam em poucos segundos
- Segurança para implementar
novas features
- Teste de erros e exceções
Desvantagens:
- Alguns problemas com Mongo
e Rabbit não eram percebidos e
só foram descobertos nos
primeiros deploys
25. Testes end-to-end
Vantagens:
- Garante que todos os serviços
funcionem de forma integrada
- Ideia futura de integrar os bots
nesses testes também
Desvantagens:
- Mais lento
- Mais díficil de encontrar onde
está o problema
26. Testes de integração
Vantagens:
- Necessidade de ter uma meio
termo entre os testes unitários e
os testes end-to-end
- Permitiram testes integrados com
o Mongo e o Rabbit, porém com
cases específicos de cada serviço
Desvantagens:
- Setup desses testes são mais
complexos que os testes
unitários
- Mais difícil garantir o
isolamento dos testes
27. Testes de carga
Características:
- Possível verificar se novas
features não impactaram na
performace do stream de dados
- Verificar qual dos microserviços
pode estar dimuindo a velocidade
do fluxo de dados
Ferramentas:
- rabbit-mq-stress-tester:
https://github.com/backstop/rabbit-
mq-stress-tester
- boom:
https://github.com/rakyll/boom