Instâncias EC2 pequenas e médias para dimensionamento horizontal com o Elastic Load Balancer

2

Estou tendo alguns debates sobre o dimensionamento de instâncias do Amazon EC2. Eu desenvolvi meu aplicativo usando o ASP.NET, então tenho que optar por uma instância do Windows EC2. O MySQL e as imagens são servidos a partir de outras instâncias, portanto, o escalonamento é (por enquanto) apenas para a instância do aplicativo da Web.

Minhas opções (por enquanto):

  1. Instâncias pequenas de 64 bits - Comece com uma Instância pequena de 32 bits, crie um Elastic Load Balancer, adicione instâncias sob demanda mais pequenas quando o tráfego aumenta (depende das especificações do CloudWatch que eu configuro).
  2. Média de instâncias de CPU alta - comece com uma instância de média alta CPU (custa mais, mas mais potente), crie um Elastic Load Balancer e adicione mais instâncias de média alta CPI quando necessário.

A primeira opção é mais barata, e permite que o aplicativo seja escalonado gradualmente, em comparação com a instância do Medium. A instância do Medium funciona apenas com 32 bits, então estou bloqueado para os 32 bits. Eu não quero escalar, como prefiro escalar horizontalmente. Isso significa que, quando o tráfego estiver baixo, não pagarei o alto preço da instância do Medium. Assim, com a segunda opção, posso optar por uma pequena instância de 64 bits e escalonar horizontalmente adicionando mais servidores no Elastic Load Balancer depende automaticamente das especificações obtidas do Amazon CloudWatch (ou seja, CPU, RAM, etc.).

Meu problema é que tenho problemas para decidir qual deles escolher. Eu li que a instância de média alta CPU é 5x mais poderosa que a pequena. Mas o preço é um pouco agressivo para começar. Em geral, prefiro pagar menos e aumentar a escala quando necessário adicionando mais pequenas instâncias.

Preciso da sua ajuda para escolher o caminho a seguir. Quais as vantagens de cada abordagem? Por que é melhor obter o alto CPU médio comparado ao pequeno em termos de escala horizontal, se houver uma vantagem. Afinal, a ideia de uma arquitetura de nuvem é economizar custos em servidores que você não precisa de seu poder de computação em um determinado período de tempo.

Eu fiz o melhor para otimizar a instância usando o cache para a página e consultas SQL para o MySQL (que existe no Xeround, que resolveu o problema de escalar quando se trata de DB). Meu banco de dados é relativamente pequeno (1000 linhas com menos dados), portanto, os 1.7GB de memória ram na pequena instância estão ok para minhas necessidades de armazenamento em cache. Eu acho que o principal problema estará na CPU quando o tráfego aumentar. Além disso, o armazenamento também é muito pequeno, hospedando apenas as páginas ASPX do meu site.

Suponho que o aplicativo possa atrair dez milhares de visitantes por dia, talvez mais. Portanto, o escalonamento é imprescindível - MAS uma escala horizontal de pequena instância é uma jogada inteligente? - Será uma escolha mais inteligente para aplicativos web de alto tráfego?

Neste momento, estou mais preocupado com a solução de pequena instância + Elastic Load Balancer. Parece lógico pagar menos e pagar mais conforme o aplicativo cresce.

Esperando por suas respostas bem informadas. Obrigado.

    
por Idan Shechter 15.10.2011 / 18:12

2 respostas

1

Por todos os meios, comece pequeno. Você sempre pode mudar para um tamanho de instância maior a qualquer momento. Se você está projetando com dimensionamento horizontal em mente, o back-end pode ser qualquer mistura de sistemas.

    
por 17.10.2011 / 18:09
1

Se a CPU é realmente o gargalo, o meio é o melhor negócio, já que é 5x a CPU por 2x o custo. No entanto, suspeito que o seu gargalo será com o arquivo io, em cujo caso um meio pode apenas superar ligeiramente um pequeno.

    
por 18.10.2011 / 06:00