Escalando e otimizando sistemas legados

Escalando e Otimizando sistemas Legados 11/09/2011 #QCONSP

Quem sou Eu?

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.

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

Performance vs Escalabilidade

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.

Performance vs EscalabilidadeNormalmente desenvolvemos pensando na performance, e isso está correto!Escalabilidade é trabalho de Arquitetura de Sistemas.

Sistemas Legados

Sistemas LegadosTodo sistema legado é diferenteMas todos têm algo em comum Estão em produção Funcionam São Confiáveis São Lucrativos

Sistemas Legados Qual é o problema então? Nenhum!Até que comece a incomodar...

Sistemas LegadosAdicionar uma Feature pequena aqui... Corrigir um bug alí... Integrar com outro sistema...

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.

Sistema LegadoQual é o Legado que vou falar?

O quÊ é a ?

O quÊ faz a ?

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.

Mas o quê isso significa para TI?

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

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

Situação atual do sistema

Requests no LB por segundo Pico de 8k req/s

300GB de Log gerados por dia Pico de 6k inserts/s

1.2TB de Estatística Processada

Agora que sabemos o quê é o sistema , Como ele evoluiu até o quê é hoje?

Vamos aos Problemas...

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:

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

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

Evolução do sistema Segundo Problema: Inserções DemoradasInstalamos Beanstalkd nos servidores de aplicação, e eles são consumidos separados da request.

Evolução do sistema Segundo Problema: Inserções Demoradas

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:

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

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:

BigQuery

(Em implantação)

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

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

Melhorando a Performance1º Monitorando o sistema

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

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

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

Melhorando a Performance Redução de I/O

Evolução do sistema Melhorar a Performance: Reduzir I/O Revisão de Querys Máquina Nova (ORM)

Evolução do sistema Melhorar a Performance: Reduzir I/OCache (Memcache/Redis) é I/O

Evolução do sistema Melhorar a Performance: Reduzir I/O Um quarto das chamadas

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.

Evolução do sistema Melhorar a Performance: Reduzir I/O Usando MGET No Redis

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

Melhorando a PerformanceMigrar para outra VM (Ruby 1.9)

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!

O Novo sistema Shuriken

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.

Passos paradesenvolvê-lo com o sistema legado

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.

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.

Novo sistema2º Desenvolva Incrementalmente!Legado Shuriken

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

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

Novo sistema 4º Coloque em produção! Problemas com PassengerCPU Leak? Unicorn O problema voltou após um reboot

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.

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).

Atualmente estamos no 5º passo

E Buscando pessoas que aceitem o desafio! rh-devel@boo-box.com

Obrigado!nelson.haraguchi@boo-box.com @nelsonmhjr ##boo-box @irc.freenode.net

http://gurusp.org	9
http://us-w1.rockmelt.com	1
http://paper.li	1
http://twitter.com	1
http://www.gurusp.org	1
http://www.linkedin.com	1

Escalando e otimizando sistemas legados

by Nelson Haraguchi

Accessibility

Categories

Upload Details

Usage Rights

6 Embeds 14

Statistics

Escalando e otimizando sistemas legados Presentation Transcript