SOS Monólito

Como tunar e recuperar um sistema monolítico

Sobre mim

Salve Devs, blza!?

​

Sou CTO na Full Cycle

MVP Microsoft

Docker Captain

​

Redes sociais @argentinaluiz

Luiz Carlos

CILADAS AO LIDAR COM MONÓLITO

​

Cilada 1 - Vamos criar microsserviços!

Cilada 2 - Vamos criar do zero!

Cilada 3 - Só escalar

vertical e horizontal!

Cilada 4 - Só usar cache!

Minha aplicação está lenta, como resolver?

“Não há nada de errado em ter monólitos”

​

“Arquitetura monolítica

continuará existindo!”

O que é um monólito?

“In software engineering, a monolithic application is a single unified software application which is self-contained and independent from other applications, but typically lacks flexibility”

wikipedia

Guia para salvar seu monolito

Guia para salvar seu monolito

00 - Case monolítico da Full Cycle

“MONOLITÃO” DA FULL CYCLE

Detalhes sobre o

“Monolitão” da Full Cycle

👉11 anos de existência (criado em meados de 2013).

👉Gerencia toda parte de ensino e financeiro: faculdade, cursos, provas, vendas, financeiro, área do aluno, certificados, etc, etc.

👉Área administrativa e API + Área do Aluno.

👉Atende +200.000 alunos para dezenas de cursos.

01- Como identificar problemas no monólito

Como identificar problemas no monólito

A chave é aplicar observabilidade,

sem ela não sabemos o que está acontecendo.

​

A Full Cycle usa New Relic/Uptime para observabilidade.

​

​

• Erros
• Eventos
• Etc

Logs

​

• CPU
• Memória
• Queries mais lenta
• Tempo de resposta

Métricas

​

• Cada linha da chamada
• Toda rota de sistemas envolvidos

​

Tracing

​

• Lentidão
• Métricas
• Indisponibilidade

Alertas

02 - Testes

Testes

Problemas

👉Testes no início, mas não no CI/CD.

​

👉Criou incentivo para fazer qualquer coisa sem testes. Sempre a desculpa do tempo.

​

👉Todo novo deploy tinha um problema a ser corrigido.

​

👉Testes quebravam pelo file description.

​

👉Problema de performance nos testes 33 min só para rodar o conjunto de testes. Gasto de memória de 5GB para rodar os testes

​

Soluções

👉Melhoria da CI/CD. Testes sempre precisam passar.

​

👉Regra do escoteiro.

​

👉Reescrita da base de testes com PHPUnit e do Kernel do Symfony.

​

👉Docker tmpfs.

​

👉Execução de testes em paralelo.

​

👉Atualmente testes rodam em 4min. Gasto de memória de 500MB.

​

​

03 - Linguagem de programação e Framework

Linguagem de programação e framework

​

• PHP 5 -> PHP 7.1

​

• Projetar migração para para PHP 7.2 e depois 7.4.

​

• Symfony 2 para Symfony 2.8-dev.

Atualizar

linguagem de programação e framework

​

• A versão atual em 7.1 é um problema porque é antiga.

​

• Novas versões corrigem problemas.

​

• Forks podem ser uma solução quando não se podem atualizar.

​

Atualizar configurações, bibliotecas e dependências

04 - Banco de dados, Cache e Http

“A performance de uma aplicação é medida pelo seu elo mais fraco”

Banco de dados

​

Problemas comuns com bancos de dados, especialmente em arquiteturas monolíticas.

​

Normalização

Excessiva

(join enorme)

Tipos de dados

inadequados

Mal uso de índices

Mal uso de Locking e Concurrency

Mal uso das conexões

“Jogue no cache”

Usar NoSQL como resposta imediata

Uso demasiado de ORM

Query raw para performance

Não utilizar estratégias de sincronização de dados

Sobe um cache aí!

“Usar cache logo de cara virou santo graal da resolução de problemas”

Cache

👉Quanto você de cache você precisa?

100MB, 1GB, 5GB, etc. (cache não tem memória infinita!)

👉Qual cache você vai utilizar?

Redis (sempre o mais falado!), memcached, banco de dados, disco, etc.

👉Quais tipos de caches você precisar implementar?

Memória, disco, no browser, no servidor web, etc.

👉Quais tipos de invalidação de cache você precisa?

Time based, Event based, Least Recently Used (LRU), Most Recently Used (MRU), Least Frequently Used (LFU), Write-through invalidation, Write-back invalidation

Problemas com nosso Redis

Mapeamento objeto relacional

PHP antiga 1

PHP antiga 2

PHP nova 1

PHP nova 2

Redis

Mapping V10

Mapping V20

…

Soluções

👉Não conseguia apagar mapeamentos antigos. Cada réplica criava nova versão do mapeamento

​

👉Acúmulo de memória no Redis. 8GB ou mais

​

👉Redis caia e não conseguia se manter de pé.

​

👉Dificilmente de identificar o problema, muitos teorias incorretas.

​

​

​

​

Soluções para problemas do Redis

👉Redis ficou apenas para cache. Usamos aproximadamente 200MB com 1 master e 3 réplicas.

​

👉Cache do mapeamento fica em filesystem dentro de cada réplica do app.

​

👉Remover campos do banco só pode depois de não estar sendo mais utilizado.

​

👉Reversão por causa de erro de banco ou mapeamento se torna muito simples.

​

Http, Retries e circuit breaker

Retries

​

👉Retries com backoff

👉Limite número de retries

👉Retries condicionais (somente erros que fazem sentido)

​

​

​

Circuit breaker

​

👉Se a rede estiver lenta falhe

👉Implementação própria ou libs

👉API Gateway

​

​

​

Uma certeza é que rede vai falhar, mas pior uma rede que é falha, é uma rede lenta!

​

👉Retentativas podem ajudar a concluir as transações.

​

👉Redes lentas podem tirar sistemas do ar, não importa como você configurou escalonamento.

​

​

​

05 - Cronjob e Event Driven

Cronjob e Event driven

Event driven

​

​

​

​

Cron Job

​

​

​

​

message broker

Producer

Consumer

Process

​

Em vez de processar tudo de forma síncrona, adiar pode ajudar

a desafogar a aplicação processando muito mais transações.

Event driven pode ajudar a criar tabelas flat, entre outras coisas.

👉Notas fiscais

👉Processamento de leads

👉Pagamentos e contratos

👉Estatísticas do aluno

👉IA

06 - Melhorias de arquitetura e design

Melhorias de arquitetura e design

​

• Lei de Conway
• Responsabilidade única baseadas nos atores do sistema
• Agrupar as coisas que mudam pelo mesmo motivo no mesmo lugar

SRP (Single Responsibility Principle)

​

• IoC
• Adapter
• Factory
• Strategy
• Observer
• Builder
• Container service

Design pattern em problemas comuns

​

• Layered Architecture
• MVC
• Application Service
• Clean Architecture
• Domain Model
• Multi-tenancy
• Strangler Pattern

Arquitetura de software

​

• Separar a aplicação em módulos
• Maior independência entre os módulos
• Maior separação dos times de desenvolvimento

Modularização

07 - Front-end

Front-end da Full Cycle

Área administrativa

Área do aluno - SPA

Problemas

​

​

​

​

👉Cache através de version no final da URL.

👉Difícil atualizar libs.

👉JavaScript gigante e lento.

👉Muita memória usada no browser.

👉Front-end quebrava quando se mexia no back-end.

👉Muito trabalho para novas features.

👉Incentivo a “costurar” novas soluções.

👉Se tornou um “monstrão”

👉Twig Template Engine

👉Lib Java para fazer join dos assets

👉Outras libs de CDN

👉AngularJS + jQuery

👉RequireJS + AMD (não tinha webpack)

👉Outras libs locais ou de CDN

👉Apenas sessão e cookies (sem JWT)

Solução do Front-end da Full Cycle

Monólito Code Platform

​

​

​

​

API PHP

Área do aluno - SPA

👉CRA depois migrado para Vite.js.

👉Auth com JWT.

👉CloudFlare Workers

08 - Conteinerização

Docker for development

​

👉Todo ambiente roda com Docker Compose.

​

👉Sobe PHP, MySQL, Redis e RabbitMQ.

​

👉“Menos na minha máquina funciona”

​

👉Progressão de ambiente

​

👉Fácil para qualquer um rodar

​

👉Docker, Dev Container

Docker for production

​

👉Ambiente padronizado para produção.

​

👉Rodar em qualquer lugar.

​

👉Mais simples para escalar.

​

👉Incentivo a ser stateless.

09 - Continuous Integration/

Continuous Deployment

Nosso CI/CD

Boas práticas em CI/CD

​

👉Automatize o máximo possível do CI/CD.

​

👉Rode testes, ferramentas de qualidade de código e etc.

​

👉Versionamento consistente.

​

👉Documentação.

​

👉Feedback rápido.

​

​

Conclusões

Conclusões

• Criar um plano de ações.
• Criar um diagnóstico da aplicação.
• Colocar prioridades, não querer fazer tudo.
• Escolher as partes mais importantes. Performance e testes já é um bom começo.

Obrigado!

​

👉Me siga nas redes sociais @argentinaluiz

​

👉Siga a Full Cycle nas redes sociais @devfullcycle

​

👉Acesse nosso canal no Youtube

​

https://www.youtube.com/@FullCycle

​

​

​

​

​