Slides apresentados no 1º meetup da codeminer42 em Guarapuava - Paraná. Apresentado um estudo de caso de escalonamento web na empresa Ponto Gestor.

1. Escalonamento horizontal
de serviços web
Estudo de caso

2. Who’s?
● Mantenedor do projeto OpenSource “SmartRouter PROJECT”;
● >17 anos de experiência com Linux;
● >9 anos de experiência com servidores de alta
disponibilidade;
● ~2 anos de desenvolvimento de projetos com
criptomoedas e blockchain;
● >6 anos de desenvolvimento WEB na
“PontoGestor” e mais 4 startups;
● Palestrante em eventos como FISL, FTSL,
RubyConf e demais eventos acadêmicos;
● Professor por acidente;
● “fabiosammy” googleit!;

3. Ponto Gestor
● Empresa que nasceu em 2013, com base de produtos e know
how da crachá digital(2001);
● Desenvolve sistema de tratamento de ponto conforme MTE;
● Possui mais de 1600 usuários finais atualmente em todo o
país, com foco no estado do Paraná(Leis trabalhistas e
sindicais);
● Utiliza de tecnologías como Rails, Postgres,
Redis e Faye;

4. Sumário
● Serviços web;
● Escalonamento vertical X horizontal e custos;
● Caso Ponto Gestor;
○ Persistência SGBD;
○ Filas e Uploads;
○ Auditoria;
○ Balanceador e proxy reverso;
○ Mensuração;
○ Sessões e realtime;
○ Consistência de dados e conflitos;
○ Cache;

5. Serviços Web
● Servidores;
● Sistemas operacionais;
● Camadas de persistência(banco de dados);
● Camadas de aplicações(linguagem utilizada);
● Camadas de serviços web(apache/nginx...);
● Serviço a ser prestado;
● ...

6. Escalonamentos verticais

7. Escalonamento horizontais

8. Comparativo de custos - DigitalOcean

9. Caso

10. Stack pontogestor

11. 1° caso - SGBD

12. 2º caso - Filas e arquivos

13. 3º Caso - auditoria

14. 4º Caso - LB

15. Estrutura nova até o 4º caso

16. Problemas?

17. 5º Caso - Mensuração - Quando escalonar?

18. 6º Caso - Sessões e REALTIME
● Usuário cai para logar no
servidor web 01;
● É direcionada a próxima
requisição para o servidor web
02;
● Perde referência da sessão e é
deslogado!
● Usuário 01 acessa o servidor
web 02;
● Usuário 02 acessa o servidor
web 03;
● Usuário 01 atualiza dado
qualquer;
● Usuário 02 não visualiza a
alteração de dado;

19. 8º caso - Consistências e conflitos
● Usuário 01, Usuário 02, e processamento background tentam
alterar um mesmo dado em um mesmo momento;
● Cliente 01, cria, ao mesmo tempo que cliente 02, um
usuário com mesmo login e e-mail(validação única);
● ...

20. 9º caso - cache!
=[

21. SGBD?
Uploads?
LOgs?
Redis?
● O SGBD ainda possui um
custo grande de manter
sincronia, mantivemos
vertical;
● Uploads somente
demandam espaço em
disco, somente adiciona
mais espaço;
● Logs mantemos somente
os últimos 90 dias;
● Redis ainda não houve
necessidade de
escalonar;

22. Conclusão
● Escalonamento horizontal é mais econômico que vertical a
longo prazo;
● É necessário ter um bom domínio de infra-estrutura para
interligar os nós;
● Em início de projeto, escalonamento vertical sempre é
mais simples de trabalhar;
● Nem sempre podemos obter escalonamento de todos os
serviços de modo fácil;
● Conflitos entre requisições sempre são difíceis de
tratar;

23. So, rails it scale?
YES MODAFOCKA!

24. Muito obrigado!
Perguntas?
contato: fabiosammy@gmail.com