• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Escalando e otimizando sistemas legados
 

Escalando e otimizando sistemas legados

on

  • 2,532 views

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

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.

Statistics

Views

Total Views
2,532
Views on SlideShare
2,508
Embed Views
24

Actions

Likes
11
Downloads
0
Comments
0

6 Embeds 24

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

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Escalando e otimizando sistemas legados Escalando e otimizando sistemas legados Presentation Transcript

    • 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