Escalando e otimizando sistemas legados

  • 2,151 views
Uploaded on

Veremos como enfrentar problemas no dia-a-dia e evoluir no longo prazo. A boo-box entrega 80 milhões de requisições por dia utilizando Ruby. Tínhamos 30 milhões de requisições por dia no início do …

Veremos como enfrentar problemas no dia-a-dia e evoluir no longo prazo. A boo-box entrega 80 milhões de requisições por dia utilizando Ruby. Tínhamos 30 milhões de requisições por dia no início do ano. Aguentar esse crescimento, sem aumentar drasticamente a infraestrutura, demanda um trabalho diário de otimização. Precisamos de tempo nessa batalha para produzir um sistema que possa suportar com folga a expansão da empresa e reduzir o custo da área de TI. Desenvolvemos uma estratégia de desenvolvimento e operação para manter o sistema legado e evoluí-lo para uma plataforma mais estável e escalável. Nessa palestra você poderá entender como tem sido esse processo e aprender um pouco mais com nossa experiência.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,151
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
0
Comments
0
Likes
11

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Escalando e Otimizando sistemas Legados 11/09/2011 #QCONSP
  • 2. Quem sou Eu?
  • 3. Nelson Haraguchi - @nelsonmhjrDesenvolvedor Ninja da boo-box desde outubrode 2010.Rubysta desde 2008.Programador Web desde 2006.Tenho cabelo comprido desde os8 anos de idade.
  • 4. Objetivo da PalestraTransmitir a experiência de escalabilidade e performance quetemos de um sistema que cresceu 10x em um ano. Performance vs Escalabilidade Sistemas Legados O sistema boo-box Evolução do sistema boo-box e dicas de otimizações Novo sistema boo-box
  • 5. Performance vs Escalabilidade
  • 6. Performance vs EscalabilidadeSistema que é rápido e Sistema que,potente. independente doMas tem a limitação do crescimento do“motor” do sistema. “trabalho”, entregaPara aguentar o com a mesmacrescimento temos que performance, seja elatrocar o “motor”. boa ou ruim.
  • 7. Performance vs EscalabilidadeNormalmente desenvolvemos pensando na performance, e isso está correto!Escalabilidade é trabalho de Arquitetura de Sistemas.
  • 8. Sistemas Legados
  • 9. Sistemas LegadosTodo sistema legado é diferenteMas todos têm algo em comum Estão em produção Funcionam São Confiáveis São Lucrativos
  • 10. Sistemas Legados Qual é o problema então? Nenhum!Até que comece a incomodar...
  • 11. Sistemas LegadosAdicionar uma Feature pequena aqui... Corrigir um bug alí... Integrar com outro sistema...
  • 12. Sistemas Legados Mas isso só incomoda VOCÊ!Para a maioria das pessoas o legado do sistema é TRANSPARENTE Cabe a nós medir, estudar e convencer de que o sistema é Legado o suficiente para valer ($$$) mais a pena desenvolver algo novo.
  • 13. Sistema LegadoQual é o Legado que vou falar?
  • 14. O quÊ é a ?
  • 15. O quÊ faz a ?
  • 16. A boo-box trabalha paragerar valor aos 150 mil sitesconteúdos produzidos e blogsna internet brasileira,fazendo a 28 milintermediação entre Publishersgrandes anunciantes eos Publishers, osformadores de opinião 65 milhões de pessoas atingidasda web.
  • 17. Mas o quê isso significa para TI?
  • 18. 20 10 - 02 20000000 40000000 60000000 80000000 0 100000000 120000000 -0 120 10 - 04 -0 520 10 - 07 -0 820 10 - 08 -1 420 10 - 09 -2 020 10 - 10 12.948.142 -2 7 2010-09-0120 10 - 12 -0 320 11 - 01 -0 920 11 - 02 -1 520 11 - 03 -2 420 11 - 04 -3 020 11 - 2011-08-31 06 100.265.652 -0 620 11 - 07 -1 3 Visualizações de Vitrines por dia20 11 - 08 -1 9
  • 19. 20 08 -1 0 50000 100000 150000 200000 250000 300000 350000 400000 450000 0- 1020 08 -1 2- 1520 09 -0 2- 1220 09 -0 4- 0220 09 -0 5- 2720 09 -0 7- 2420 09 -0 9- 2220 09 -1 1- 1820 10 -0 1- 2720 10 -0 3- 3020 10 -0 5- 2620 10 -0 7- 2220 10 -0 9- 1720 10 -1 1- 1720 11 -0 1- 1320 11 Evolução de Linhas de código -0 3- 1220 11 -0 5- 06 Mês que vem o sistema fará 3 anos!!!20 11 -0 7- 0520 11 -0 8- 31
  • 20. Situação atual do sistema
  • 21. Requests no LB por segundo Pico de 8k req/s
  • 22. 300GB de Log gerados por dia Pico de 6k inserts/s
  • 23. 1.2TB de Estatística Processada
  • 24. Agora que sabemos o quê é o sistema , Como ele evoluiu até o quê é hoje?
  • 25. Vamos aos Problemas...
  • 26. Evolução do sistema Primeiro Problema: Estatística DiáriaO LOG era processado num batch diárioChegou a demorar 8 horas para processarum diaConsequência: Campanhas comotimização atrasadaSolução:
  • 27. Evolução do sistema Primeiro Problema: Estatística DiáriaTriggers do MySQL processam as inserts egeram estatística em tempo real.Mas isso gerou outro problema: Inserçõesdemoradas
  • 28. Evolução do sistema Segundo Problema: Inserções DemoradasCom as triggers as Inserts estavamdemorando e atrasando a requestConsequência: Aumento no tempo derespostaSolução: Separar a camada de log darequest
  • 29. Evolução do sistema Segundo Problema: Inserções DemoradasInstalamos Beanstalkd nos servidores de aplicação, e eles são consumidos separados da request.
  • 30. Evolução do sistema Segundo Problema: Inserções Demoradas
  • 31. Evolução do sistema Terceiro Problema: Filas AtrasadasMesmo separado, não podemos deixar aestatística atrasar tanto. Principalmentequando dependemos dela para otimizar aveiculação.Solução:
  • 32. Evolução do sistema Terceiro Problema: Filas AtrasadasCom a Engine Blackhole do MySQL, astriggers são executadas, mas os dadosnão vão para o disco, assim é possível gerar muito mais estatística. Adicionamos um Slave para fazer o storage do LOG
  • 33. Evolução do sistema Quarto Problema: Estatística Grande DemaisCom muitos GB de dados para ler e gerara estatística, otimizar a veiculação e gerarrelatórios começa a se tornar umproblema.Solução:
  • 34. BigQuery
  • 35. (Em implantação)
  • 36. Evolução do sistemaQuinto Problema: Latência de Arquivos EstáticosServidores lá fora, são mais baratos queaqui. Mas isso tem um custo de latência.Consequência: Ads demoram mais aaparecerSolução: CDN
  • 37. Evolução do sistema Sexto Problema: O crescimento da RedeNão é bem um problema. Crescer é o quequeremos.O sistema que processa a requisição éescalável, mas precisamos adicionar maisservidores.Solução: Melhorar a performance
  • 38. Melhorando a Performance1º Monitorando o sistema
  • 39. Evolução do sistema Melhorar a Performance: Monitore[287.2/s in last 5s: 1436 total:29353] DISPATCH: 0.01920s[236.2/s in last 5s: 1181 total:30502] DISPATCH: 0.01861s[272.8/s in last 5s: 1364 total:31834] DISPATCH: 0.02096s[271.0/s in last 5s: 1355 total:33157] DISPATCH: 0.02142s[271.4/s in last 5s: 1357 total:34482] DISPATCH: 0.02194s[268.6/s in last 5s: 1343 total:35793] DISPATCH: 0.02069s
  • 40. Evolução do sistema Melhorar a Performance: Monitore[40.8/s in last 5s: 204 total:204] DISPATCH: 0.06690s[48.8/s in last 5s: 244 total:422] DISPATCH: 0.06430s[46.0/s in last 5s: 230 total:626] DISPATCH: 0.07387s[46.2/s in last 5s: 231 total:831] DISPATCH: 0.06803s[40.2/s in last 5s: 201 total:1006] DISPATCH: 0.07426s[43.0/s in last 5s: 215 total:1195] DISPATCH: 0.06251s[106.6/s in last 5s: 533 total:533] DISPATCH: 0.02058s[141.6/s in last 5s: 708 total:1213] DISPATCH: 0.02255s[138.0/s in last 5s: 690 total:1875] DISPATCH: 0.02035s[146.0/s in last 5s: 730 total:2577] DISPATCH: 0.01853s[144.4/s in last 5s: 722 total:3271] DISPATCH: 0.02036s[147.6/s in last 5s: 738 total:3981] DISPATCH: 0.02013s
  • 41. Evolução do sistema Melhorar a Performance: Monitore Call Hits Avg. Timeget_compatible_ads 16 0.23063Saving on beanstalk 905 0.00792validate_realtime 400 0.00561get_optimized_ad 357 0.00418get_compatible_ads cached 384 0.00370
  • 42. Melhorando a Performance Redução de I/O
  • 43. Evolução do sistema Melhorar a Performance: Reduzir I/O Revisão de Querys Máquina Nova (ORM)
  • 44. Evolução do sistema Melhorar a Performance: Reduzir I/OCache (Memcache/Redis) é I/O
  • 45. Evolução do sistema Melhorar a Performance: Reduzir I/O Um quarto das chamadas
  • 46. Evolução do sistema Melhorar a Performance: Reduzir I/O Otimização do uso Substituir do Cache Memcached por Redis. Cachear o máximo possível de uma vez.
  • 47. Evolução do sistema Melhorar a Performance: Reduzir I/O Usando MGET No Redis
  • 48. Evolução do sistema Melhorar a Performance: Outras Otimizações- Reduzir a Latência entre servidores- Reduzir Loops do sistema- Substituir Arrays por Hashs (ou Sets)São otimizações que economizam muito pouco
  • 49. Melhorando a PerformanceMigrar para outra VM (Ruby 1.9)
  • 50. Evolução do sistema Melhorar a Performance: Ruby 1.9O sistema não é compatível com Ruby1.9 devido a depêndencias (gems).Essas gems não são utilizadas noprocessamento da requisição.Solução: Implementar um novosistema!
  • 51. O Novo sistema Shuriken
  • 52. Novo sistema Porquê Desenvolver um Novo Sistema?Separar o código da veiculação do resto dosistema. (site e admin)Conseguir testar outras VMs como JRuby,Rubinius, YARV...Garantir o funcionamento daquilo que não podeficar down.Refatorar, Otimizar e Repensar a Arquiteturasem se preocupar com o resto do sistema.
  • 53. Passos paradesenvolvê-lo com o sistema legado
  • 54. Novo sistema1º Separar o código que precisa escalar!Crie Testes! O Máximo possível, e migre oteste primeiro.Não Refatore! Pois parte da sua lógicapode se perder.No nosso caso reduzimos também o stack, eobjetos em memória cortando o Merb e usandoo Rack direto.
  • 55. Novo sistema 2º Desenvolva Incrementalmente!Separamos as Visualizações de Vitrines deAds que compõe 95% da nossa veiculação eportamos primeiro.Estamos em processo de portar asVisualizações de Vitrines de Produtos, edepois portaremos os cliques, e conversões.
  • 56. Novo sistema2º Desenvolva Incrementalmente!Legado Shuriken
  • 57. Novo sistema 3º Teste Exaustivamente!Reproduzimos um dia inteiro de requests nosistema até que ele não gerasse erros.Testamos também a geração de Logs econsumo das filas.Nota: Marshal is evil
  • 58. Novo sistema 4º Coloque em produção!Coloque-o em produção aos poucos paragarantir a confiabilidade.Problemas vão acontecer!O Shuriken subiu com Passenger e comUnicorn, e tivemos problemas
  • 59. Novo sistema 4º Coloque em produção! Problemas com PassengerCPU Leak? Unicorn O problema voltou após um reboot
  • 60. Novo sistema 5º Não Jogue Fora o seu Legado!O sistema legado deve continuar em uso, por umbom tempo até o amadurecimento do novosistema.Otimizações no Shuriken são portadas para olegado.Testes alcançam 100% de cobertura.Refatorações são feitas.O sistema legado é desligado.
  • 61. Novo sistema6º Repense a Arquitetura de modo Escalável! Um sistema deve ter camadas bem definidas. (Load Balancer, Aplicação, Cache, Database, Log, etc...) Cada camada deve ter sua própria estratégia de REDUNDÂNCIA (prestando serviços) e TOLERÂNCIA A FALHA (consumindo serviços).
  • 62. Atualmente estamos no 5º passo
  • 63. E Buscando pessoas que aceitem o desafio! rh-devel@boo-box.com
  • 64. Obrigado!nelson.haraguchi@boo-box.com @nelsonmhjr ##boo-box @irc.freenode.net