Slides da apresentação no guru-sp 22/07/2023

1. O (duro) caminho para
a confiabilidade de
longo prazo no RoR

2. Victor Felix
2
Qulture.Rocks
Investir
em
desempenho
muda
tudo_
Backend engineer e SRE @qulture.rocks
@victorfgs
Quem sou eu?

3. Agenda
1. Premissas desse talk
2.Dynos e o scaling manual
3.Um loop de causa e efeito
4.Considerações finais
3
Qulture.Rocks
Investir
em
desempenho
muda
tudo_

4. Premissas desse talk
Sobre o que vamos falar e baseado em
quais tecnologias?
Investir
em
desempenho
muda
tudo_

5. 5
Premissas desse talk
Sobre o que vamos
falar?
●Público alvo: pessoas desenvolvedoras
com mais experiência no backend, SREs,
pessoas operadoras de infraestrutura
● Aplicação longeva com base de usuários
constantemente crescente e com
múltiplos releases diários
● Escalabilidade horizontal dinâmica no
processo web e nos background workers
Investir
em
desempenho
muda
tudo_

6. 6
Premissas desse talk
Sobre o que vamos
falar?
●Monolito rails multi-tenant
●Heroku como provedor de cloud
●Puma como servidor web
●Sidekiq para processar jobs
assíncronos
● Redis de apoio para o Sidekiq e para
o actioncable
● Modo rest API e graphql
Aplicaçõescujos
recursos são
compartilhadospor
todos os clientes. Não
há deploy on-prem
Multi-tenancy?
Investir
em
desempenho
muda
tudo_

7. Dynos e o scaling manual
Os efeitos de uma base de usuário
crescente em uma infra estática
Investir
em
desempenho
muda
tudo_

8. Antes de tudo, o
vocabulário
8
Qulture.Rocks
Dynos e o scalingmanual
Investir
em
desempenho
muda
tudo_
Nome da compute unit
básica do heroku. AKA
“máquina” (ou
container) em que roda
a aplicação
Dyno
Quantidade(e tipos) de
uma dada compute unit
que compõe a
aplicação
Scaling(ou scalingformation)
Qualquer procedimento
que faça a aplicação
rodar com a mesma
qualidade para mais (ou
menos) usuários
“Escalar” uma aplicação

9. 9
Dynos e o scaling manual
Visualizando o ciclo de
vida de um request
De maneira simples:
1. Request é feito para o DNS é é
redirecionado para o router
2.Router decide para qual dyno
vai o request
3.Dyno processa o request e
responde ao cliente
Investir
em
desempenho
muda
tudo_

10. 10
Dynos e o scaling manual
Congestionamento.
Congestionamento é o que
acontece.
Nesse primeiro incidente, temos:
1. Usuário final notando tempos
de load maiores e erros de
timeout na aplicação
2.Alertas variados de erros da
aplicação nos intrumentos
configurados
Investir
em
desempenho
muda
tudo_
O número de usuários
dobrou. O que acontece?
A relação entre
requests, router e
compute units pode ser
interpretado como uma
fila. A fila não andar no
passo esperado é um
congestionamento
Por que congestionamento?

11. A fila está cheia de clientes
insatisfeitos. E agora?
11
Qulture.Rocks
Dynos e o scalingmanual
Investir
em
desempenho
muda
tudo_
A resposta nesse caso é bem simples: mais dynos
(compute) para atender o excesso da fila.
Mais compute significa mais requests sendo
respondidos em um mesmo intervalo de tempo o
que, por sua vez, leva ao esvaziamento da fila
atual.
Na solução de longo prazo, utilizamos um addon
que monitora o queue time da aplicação para
então decidir se um up-scaling (ou down scaling)
automático deve ocorrer
Tempo que um dado
request espera antes
de ser processado por
um compute unit
Queue time

12. O que aprendemos com
esse incidente?
12
Qulture.Rocks
Dynos e o scalingmanual
1. Acompanhar métricas como queue time e tempo médio
de resposta é útil para notar incidentes antes do
usuário final
2. Durante um incidente devemos separar os esforços em
duas partes:
a. Esforços de curto prazo. Esforços menos complexos
que podem ser implementados de imediato e que
vão mitigar uma boa parte dos problemas
b. Esforços de longo prazo
3. Processos e tecnologias que nos permitem mais
proatividade são sempre prioritários
Investir
em
desempenho
muda
tudo_

13. Um loop de causa e
efeito
Como agir quando a causa de um dado incidente
não está clara sem piorar a vida do usuário
Investir
em
desempenho
muda
tudo_

14. Nem sempre que um usuário final abre uma reclamação de
requests lentos/timeouts devemos rever o scaling da
aplicação.
Depois de alguns bons meses rodando os compute units em
auto-scaling, outro incidente foi aberto com base em
reclamações dos usuários finais de tempo médio de
respostas e timeouts em requests.
Dessa vez, no entanto, o queue time não estava alto. O que
pode estar causando isso então? Instanciar mais dynos é
uma boa medida de curto prazo nesse caso?
Mesmo problema, causa
diferente
14
Qulture.Rocks
Um loop de causa e efeito
Investir
em
desempenho
muda
tudo_

15. Item básico de monitoramento em produção, APMs
(application performance management) são capazes de
destrinchar uma dada aplicação trazendo insights do que
pode estar causando problemas para a operação
Entra no chat o APM
15
Qulture.Rocks
Um loop de causa e efeito
Investir
em
desempenho
muda
tudo_
Um print de um gráfico
que demonstra quais
operações compõe os
requests web de uma
aplicação. Nele, vemos
que uma boa parte do
request médio é gasto
em `Middleware`e
`Ruby`
O que estou vendo?

16. 16
Um loop de causa e efeito
De volta ao problema original
Ao analisar as informações da APM notamos
que:
1. O tempo gasto no banco de dados
(postgres) estava mais alto que o normal
2.O queue time estava relativamente
normal
3.Transações não web (jobs async)
também apresentavam tempos altos de
banco de dados
Investir
em
desempenho
muda
tudo_

17. 17
Um loop de causa e efeito
Muito tempo no banco de
dados. E agora?
O ideal parece ser listar coisas que poderiam causar esse aumento de
tempo:
1. Alguma query (nova ou alterada) com problemas de performance?
Analisando os dados da APM, a degradação de performance aparecia
em queries variadas não relacioanadas com releases recentes
2. Existe algum incidente entre os dynos e o postgres que possa estar
degradando a conexão? Não. O Heroku estava livre de incidentes
nesse dia
3. O postgres em questão está saudável? Não sabíamos responder essa
pergunta. Nunca tínhamos observado bancos de dados nesse
detalhe
Investir
em
desempenho
muda
tudo_
Bingo!

18. Observando as métricas do servidor postgres notamos um pico de uso de
CPU acima do plano contratado. O que poderia ter causado isso?
O up-scaling automático causou isso. Na verdade, um pico de usuários ativos
causou alguns up-scalings em sequência que, por sua vez fizeram com que o
banco de dados respondesse a um número excessivo de queries ao mesmo
tempo.
O limite máximo de up-scaling era mais do que o banco de dados atual
conseguia atender. Como lidar com isso?
Analisando métricas e
aplicando medidas imediatas
18
Qulture.Rocks
Um loop de causa e efeito
Investir
em
desempenho
muda
tudo_

19. Como planos de imediato, adotamos:
1. Diminuir o número máximo de dynos. Isso faz com que mais usuários
recebam erros de timeout mas faz com que a maioria que conseguiu
realizar um request seja respondido com sucesso
2. Atualizar a CPU do postgres atual. Isso pode ser feito de imediato no
heroku com um clique de um botão então foi feito durante o incidente
Como planos de médio prazo:
1. Monitoramento e alertas para uso excessivo de recursos
2. Playbook de como lidar com esse tipo de incidente
3. Reconfiguração do auto scaler
Planos de imediato & planos de
médio prazo
19
Qulture.Rocks
Um loop de causa e efeito
Investir
em
desempenho
muda
tudo_

20. Está quase acabando. Eu prometo
Considerações finais
Investir
em
desempenho
muda
tudo_

21. ● Subiu uma aplicação? Instrumente!
○ APM e persistência de logs são o básico. Ferramentas
que transformam em alertas podem vir depois
● Nem sempre o mesmo problema é causado pela mesma
coisa e tem a mesma solução
○ Antes de tomar qualquer medida é uma ótima prática
revisar o cenário atual para então compará-lo aos
conhecidos
● Documentar configurações ajuda o seu time no futuro
○ É muito fácil esquecer o motivo de `tal configuração
ser 7 e não 10`. Documente suas escolhas.
Comentários ou ADRs servem o mesmo propósito aqui
O que aprendemos com
esses últimos anos?
21
Qulture.Rocks
Considerações finais
Investir
em
desempenho
muda
tudo_

22. Obrigadx!
Victor Félix
victor.felix@qulture.rocks
@victorfgs