Testes de escalabilidade usando cloud

616 views

Published on

Como utilizamos um serviço de cloud para validar nossas estimativas de escalabilidade. Rodando o sistema inteiro, mais clientes de teste, num cloud a baixíssimo custo.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
616
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Testes de escalabilidade usando cloud

  1. 1. Testes de Escalabilidade usando CloudComo utilizamos um serviço de cloud para validar nossas estimativas de escalabilidade. Rodando o sistema inteiro, mais clientes de teste, num cloud a baixíssimo custo. Daniel Sperry Lead Programmer daniel@hoplon.com
  2. 2. Disclaimer Essa é uma história de várias pessoas, o palestrante é apenas um dos envolvidos nos eventos descritos, o leader programmer durante a execução desses testes.
  3. 3. TaikodomMMO de Ação Espacial Players são pilotos de espaçonave lutando para conquistar o espaçoVersão 2.0: Em Barnard, um sistema remoto, um buraco negro artificial explodiu. O jogador deve escolher uma facção: ■ Consórcio: Uma missão de ajuda "humanitária" enviada pelo sistema solar. ■ Renegados: lutam contra a "tirania" dos consorciados.
  4. 4. Histórico2005 - Desenvolvimento do Taikodom iniciado: python, c++ e java.2005 - Versão inicial aberta a testes.2006 - Protótipo em java e c++2007 - Convertido para java, beta 1.02008 - Lançamento nacional do 1.0, 100% java.2009 - Nova definição de produto.2009 - Acordo de publicação internacional para versão 2.0 (Gamersfirst)2009 - Início da codificação da versão 2.02010 - Closed beta iniciado.2011 - Open beta.2012 - Lançado no Brasil. Closed beta nos EUA.
  5. 5. Taikodom 1.0 - escalabilidade● Taikodom 1.0 não usava database convencional. Utilizava servidor transacional in memory desenvolvido in house.● Testes de performance indicavam que poderia fazer mais de 100K Transações por segundo.● Na vida real, depois de 2 semanas, e com algumas centenas de CCU, o servidor parava regularmente durante dezenas de segundos em função do garbage collection.● Os jogadores chamaram a reação percebida por eles no cliente de jogo de LAG.● Os problemas foram resolvidos mas o estrago de imagem já estava feito.
  6. 6. Taikodom 2.0Arquitetura mais tradicional:● engine comercial● database● webservices
  7. 7. Estragégia para escalabilidadeEstratégia de escalabilidade:● evitar ponto único de falha/gargalo escrito in house.● calcanhar de aquiles: database● projetado para cada shard suportar até 10k CCU.● stored procedures devem demorar menos de 5ms (evitamos LINQ to SQL).
  8. 8. Arquitetura
  9. 9. Testes de escala inhouse● Começamos com testes internos usando bots.● De noite ligávamos as máquinas do Studio e executávamos os bots nelas, processo semi manual.● Resultados: ○ algumas centenas de CCU. ○ eliminação de bugs e de gargalos. ○ chegamos no limite que um teste manual poderia gerar.
  10. 10. Escolha de um serviço● Na época avaliamos seriamente ○ amazon EC2 ○ GoGrid ○ rackspace● Critérios de escolha: ○ elasticidade ○ custo, especialmente das máquinas highend ○ familiaridade/facilidade de uso
  11. 11. Estimativas iniciais
  12. 12. Configuração dos testesGo grid Bot Machine Sim Machine Proxy Machine Bot Machine Sim Machine Proxy Machine DB Machine Bot Machine Sim Machine Proxy Machine MS SqlServer Bot Process Bot Process Bot Process Bot Process Bot Process Bot Process WebServices Bot Process Simulator Proxy
  13. 13. Quantidade de testes e custosPeríodos dos testes● 2010/outubro● 2010/dezembro● 2011/março à maio● 2011/dezembroCusto total de utilização: < US$ 8.000Duração média dos testes: 1h20Tempo médio de setup dos testes: 4hNúmero de total de testes: ~40
  14. 14. Resultados
  15. 15. Resultados dos testes● Identificamos/corrigimos bugs de networking● Identificamos as stored procedures mais caras.● Identificamos problemas de deadlocks na database● Atingimos a meta interna de 5K CCU por shard
  16. 16. Minimizando custos● Persistir imagem das máquinas bases● Fechar a torneira ao terminar os testes● Planos pré-pago do GoGrid
  17. 17. Cloud - Desafios● Tempo de upload dos servidores● Requisição de mais IPs● Tempo de criação de cada instância● Escolha dos tamanhos certos das instâncias.● Fechar a "torneira" ao sair● Tempo total do teste: na melhor das hipóteses 1 tarde inteira.
  18. 18. ContatoDaniel Sperry ● Taikodom Lead Programmer ● daniel@hoplon.com ● http://br.linkedin.com/in/dsperryEstamos contratando! ● game designers ● programadores ● artistas ● produtoresEnvie seu currículo para: rh@hoplon.com
  19. 19. ContatoDaniel Sperry ● Taikodom Lead Programmer ● daniel@hoplon.com ● http://br.linkedin.com/in/dsperryEstamos contratando! ● game designers ● programadores ● artistas ● produtoresEnvie seu currículo para: rh@hoplon.com

×