RubyConf BR 2021 - Uma talk eventualmente consistente

"Eventualmente consistente" é a expressão que usamos para informações que não são atualizadas em tempo real mas que, eventualmente, se tornam consistentes. Essa estratégia de delaying pode ser vital para um sistema, como foi no nosso caso, em que reduzimos o tempo para recalcular relatórios de envio por hora de 4 horas em média para apenas 5 minutos. Esta talk traz um compilado de aprendizados sobre o uso consciente dos recursos disponíveis, tomando por base um ambiente altamente concorrente com processamento diário de mais de 10M de eventos.

Transcript

1. Uma talk eventualmente consistente
2. { “name”: “Gabriel Ferreira”, “github”: “@gleopoldo”, “company”: “Locaweb”, “team”: “SMTP”, }
3. https://ferreiratoons.com.br/
4. Lições extraídas do campo de batalha
5. O problema
7. Foto: Um heroico usuário aguardando eternamente um relatório
8. Foto: Nosso banco de dados, em um dia normal de trabalho...
9. O projeto
10. Foto: Um inocente loop/do para processamento async Pra que message brokers???
11. Foto: Devs em pânico prestes a serem engolidos por um projeto mitológico faminto...
16. O resultado
17. ANTES +4 h de delay para atualizar relatórios 1.5 M de eventos travados NA FILA 1000 queries por segundo 47% IOwait no main DB
18. 5 min de delay para atualizar relatórios 10 M de eventos processados por dia (sem fila) 2000 queries por segundo 8% IOwait no Main DB DEPois
20. Pra que usamos async no dia-a-dia?
21. “Tudo aquilo que demora tempo demais para uma requisição satisfatória de uma app web jogamos para background-jobs”
22. “Call and forget”
23. E o que acontece quando o job demora demais?
24. a) Enfileirar outro job b) Nada… jobs foram feitos pra demorar c) Comprar mais hardware! d) Correr em círculos e) Dar git blame
26. Lições aprendidas ao lidar com async
27. Tenha métricas!!! Lição 1:
28. Evite Otimização prematura
29. “Premature optimization is the root of all evil” Knuth, Donald The Art of Computer Programming author
32. Tenha métricas!
33. O que medir?!
34. - throughput (requests / s) - response time de uma rota / job - consumo de memória - consumo de CPU - tempo gasto em requests
35. Medir trade-offs!
37. - redis local / redis externo - mass inserts / vários inserts - sobrecarga na leitura ou na escrita
38. Crash-driven design Lição 2:
40. https://en.wikipedia.org/wiki/Crash-only_software “Crash-only software refers to computer programs that handle failures by simply restarting, without attempting any sophisticated recovery”
41. Erros vão acontecer, é fato
42. Foraging for the Fallacies of Distributed Computing
43. Understanding the 8 fallacies of Distributed Systems
44. Falácia #1 A rede é confiável
45. Falácia #2 A latência de rede é zero
46. Falácia #3 A largura de banda é infinita
47. Falácia #7 O custo do transporte é zero
48. Mentalidade do dev pessimista
49. “Anything that can go wrong will go wrong” The Murphy law
50. Gerencie melhor o uso de recursos de rede
51. Circuit-breaker pattern
52. mantenha os dados perto de onde são usados
53. escritas Leituras vs 1. inserts simples 2. Inserts em várias tabelas 3. dados pré-computados 4. views, triggers e procedures 1. Leitura simples 2. Joins de tabelas 3. dados computados no momento da leitura 4. Cruzar dados em memória (na app)
54. Garanta o sucesso de transações críticas
56. Garanta flexibilidade de escala
58. Reentrância x Idempotência
59. Wikipedia (Rentrancy computing) “[...] a reentrant procedure can be interrupted in the middle of its execution and then safely be called again (“reentered”) before it’s previous invocations complete execution [...]”
60. “Idempotence is the property of certain operations [...] whereby they can be applied multiple times without changing the result beyond the initial application” Wikipedia (Indempotence)
62. Cuidado com transações distribuídas
63. Encadeando múltiplos jobs Lição 3:
64. Cada nova integração traz mais complexidade
65. “The Big Ball of Mud” anti-pattern
66. “Big Ball of Mud”, aplicada a serviços
67. Microservices Choreography vs Orchestration: The Benefits of Choreography
68. Prós: - Maior controle sobre a ordem de execução; - Paradigma request/response; - Mais intuitiva (da perspectiva do código) - Regra de negócio centralizada; Contras: - Maior acoplamento entre jobs / serviços; - Menos independência dos serviços;
69. Prós: - Serviços e jobs mais independentes; - Controle distribuído / maior resiliência; - Paradigma ES + CQRS; Contras: - Menos intuitiva; - Sem controle sobre a ordem de execução; - Regras de negócio espalhadas;
70. Bottlenecks sempre vão existir Lição 4:
71. O código mais performático é aquele que nunca existiu
72. Tudo tem um custo de processamento
73. Foraging for the Fallacies of Distributed Computing
74. Tudo tem um limite, até mesmo concorrência
75. 20 THREADS PER VM 4 VIRTUAL MACHINES TONS OF UPDATES ON THE SAME RECORD IN THE DATABASE ASYNC JOBS DOING A SINGLE UPDATE EACH LOCKS CAUSES A CHAOS IN THE DATABASE OTHER APPS CRASH SINCE CAN’T ACQUIRE LOCKS THE DATABASE STOPS RESPONDING
77. 3 THREADS PER VM 4 VIRTUAL MACHINES UPDATES STILL OCCUR, BUT NOW IN LESS SCALE OTHER APPS STILL WORKING THE DEFINITIVE FIX GOES TO THE BACKLOG UPDATE PERFORMANCE COULD BE BETTER, BUT IT FITS OUR PURPOSES NOW A DOCUMENTATION ABOUT THE BUG, AND SOLUTION PROPOSALS ASYNC JOBS DOING A SINGLE UPDATE EACH
78. Qual é o seu “aceitável”? Defina requisitos não-funcionais
79. Architectural FITNESS functions
80. Toughtworks Technology Radar
84. Documente bem suas decisões Lição 5:
90. Dúvidas? Github: @gleopoldo Speaker Deck: gleopoldo Linkedin: gabriel-leopoldo Gabriel Ferreira https://ferreiratoons.com.br/