Testes de Escalabilidade
         usando Cloud
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.

                             Daniel Sperry
                           Lead Programmer
                          daniel@hoplon.com
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.
Taikodom
MMO de Ação Espacial
  Players são pilotos de espaçonave lutando para
  conquistar o espaço

Versã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.
Histórico

2005 - 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.0
2008 - 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.0
2010 - Closed beta iniciado.
2011 - Open beta.
2012 - Lançado no Brasil. Closed beta nos EUA.
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.
Taikodom 2.0
Arquitetura mais tradicional:
● engine comercial
● database
● webservices
Estragégia para escalabilidade
Estraté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).
Arquitetura
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.
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
Estimativas iniciais
Configuração dos testes

Go 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
Quantidade de testes e custos
Períodos dos testes
● 2010/outubro
● 2010/dezembro
● 2011/março à maio
● 2011/dezembro

Custo total de utilização: < US$ 8.000
Duração média dos testes: 1h20
Tempo médio de setup dos testes: 4h
Número de total de testes: ~40
Resultados
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
Minimizando custos

● Persistir imagem das máquinas bases
● Fechar a torneira ao terminar os testes
● Planos pré-pago do GoGrid
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.
Contato
Daniel Sperry
 ● Taikodom Lead Programmer
 ● daniel@hoplon.com
 ● http://br.linkedin.com/in/dsperry

Estamos contratando!
 ● game designers
 ● programadores
 ● artistas
 ● produtores

Envie seu currículo para: rh@hoplon.com
Contato
Daniel Sperry
 ● Taikodom Lead Programmer
 ● daniel@hoplon.com
 ● http://br.linkedin.com/in/dsperry

Estamos contratando!
 ● game designers
 ● programadores
 ● artistas
 ● produtores

Envie seu currículo para: rh@hoplon.com

Testes de escalabilidade usando cloud

  • 1.
    Testes de Escalabilidade usando Cloud 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. Daniel Sperry Lead Programmer daniel@hoplon.com
  • 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.
    Taikodom MMO de AçãoEspacial Players são pilotos de espaçonave lutando para conquistar o espaço Versã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.
    Histórico 2005 - Desenvolvimentodo 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.0 2008 - 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.0 2010 - Closed beta iniciado. 2011 - Open beta. 2012 - Lançado no Brasil. Closed beta nos EUA.
  • 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.
    Taikodom 2.0 Arquitetura maistradicional: ● engine comercial ● database ● webservices
  • 7.
    Estragégia para escalabilidade Estratégiade 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.
  • 9.
    Testes de escalainhouse ● 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.
    Escolha de umserviç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.
  • 12.
    Configuração dos testes Gogrid 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.
    Quantidade de testese custos Períodos dos testes ● 2010/outubro ● 2010/dezembro ● 2011/março à maio ● 2011/dezembro Custo total de utilização: < US$ 8.000 Duração média dos testes: 1h20 Tempo médio de setup dos testes: 4h Número de total de testes: ~40
  • 14.
  • 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.
    Minimizando custos ● Persistirimagem das máquinas bases ● Fechar a torneira ao terminar os testes ● Planos pré-pago do GoGrid
  • 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.
    Contato Daniel Sperry ●Taikodom Lead Programmer ● daniel@hoplon.com ● http://br.linkedin.com/in/dsperry Estamos contratando! ● game designers ● programadores ● artistas ● produtores Envie seu currículo para: rh@hoplon.com
  • 19.
    Contato Daniel Sperry ●Taikodom Lead Programmer ● daniel@hoplon.com ● http://br.linkedin.com/in/dsperry Estamos contratando! ● game designers ● programadores ● artistas ● produtores Envie seu currículo para: rh@hoplon.com