Rails AWS Architecture - migrando de uma única máquina Linode para a AWS

1

Nossa startup tem um aplicativo que está em produção há quase um ano executando Rails/MySQL+MongoDB/Unicorn/Nginx com sucesso em uma única caixa de Linode.

Recentemente, decidimos mudar para a AWS por vários motivos:

  1. Custo - recebemos vários milhares de dólares em crédito da AWS (por meio de um programa acelerador em que estamos) e seria uma pena não usá-lo.
  2. Escalabilidade - estamos começando a receber bastante publicidade ultimamente e nossos números de usuários estão aumentando. Pelo custo da caixa Linode e pelo que recebemos em retorno, ela não será bem dimensionada no futuro próximo.
  3. Habilidades - a pilha da AWS parece impressionante nos recursos e ferramentas disponíveis, e eu ouvi e li muita coisa boa (e um pouco ruim) sobre como poderia ser um bom lugar para começar a crescer .

No geral, os problemas de custo e escalabilidade são vantajosos para nós, já que a hospedagem gratuita e confiável é difícil de superar (bem, até ficar sem crédito AWS). Ainda precisamos garantir fundos para que todos os custos de TI saiam do meu bolso (vários US $ 100 / mês).

Então, basicamente, quero migrar nosso aplicativo para a AWS e estou pensando sobre a seguinte pilha:

     Elastic-Load-Balancer
              |
              |
[1+ Rails App over Unicorn/Nginx]
              |
              |
[1+ DB Server (MySQL + MongoDB)]

Onde os servidores de aplicativos ou bancos de dados podem crescer horizontalmente conforme necessário. Como não estamos realmente empurrando o ponto de interrupção ainda, eu estava pensando em começar com 1 servidor de aplicativos, 1 servidor de db (não RDS, por enquanto) e ELB + Route53 para gerenciar DNS e balanceamento de carga.

Eu nunca usei a AWS e não sou especialista em DevOps, então queria feedback sobre algumas coisas:

  1. Como devo gerenciar a parte do servidor da web da pilha em relação à configuração do unicorn + nginx? Até agora, tudo estava na mesma máquina e, portanto, não era um grande problema. Devo manter minha configuração do nginx.conf e apenas ouvir o nginx nas portas 80/443 em cada instância do App?
  2. Gostaria de poder aumentar a camada de aplicativos simplesmente adicionando mais instâncias (AMIs) conforme necessário. Isso será administrável no curto prazo? Por exemplo, até que tenhamos dinheiro para contratar um devops ou uma loja próxima devido à pobreza:)
  3. Quaisquer outras lições aprendidas ou coisas para manter em mente serão muito apreciadas.

Observação - por vários motivos, eu não quero usar o OpsWorks ainda: nosso servidor de aplicativos é muito personalizado, sem suporte do Mercurial, não é muito maduro, etc.

Obrigado.

    
por sa125 20.04.2013 / 16:06

1 resposta

2

Os Aws podem fornecer a escalabilidade no caso de você precisar Sugestões de arquitetura

  • use elb para o primeiro nível
  • use dois ou mais servidores de aplicativos (por motivos de redundância)
  • use rds se puder

Agora ... Se o rds não for uma opção, você terminará com um banco de dados mestre e um escravo. Para o db eu recomendo volumes ebs que são distribuídos.

Gerenciamento de configuração pode ser qualquer coisa desde que você esteja confortável com ela. Claro que há chef, fantoche e os gostos.

    
por 20.04.2013 / 21:38