testes de escalabilidade usando cloud
Post on 24-May-2015
360 Views
Preview:
DESCRIPTION
TRANSCRIPT
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.
TaikodomMMO 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.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.
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.
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).
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
Go grid
Bot MachineBot Machine
Configuração dos testes
Bot Machine
Bot ProcessBot Process
Bot Process
Sim MachineSim Machine
Sim Machine
Bot ProcessBot Process
Simulator
Proxy MachineProxy Machine
Proxy Machine
Bot ProcessBot Process
Proxy
DB Machine
MS SqlServer
WebServices
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.000Duração média dos testes: 1h20Tempo médio de setup dos testes: 4hNúmero de total de testes: ~40
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.
ContatoDaniel 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
top related