Confusão de escalonamento automático da instância do AWS EC2

Question

Então, primeiro, eu sou completamente novo na AWS, então fique de olho comigo.

Eu tenho uma instância em execução há alguns meses e agora preciso fazer o escalonamento automático, pois estou recebendo picos de tráfego maiores e ela fica sobrecarregada às vezes.

Então deixe-me ver o que eu fiz até agora e vocês podem me dizer onde eu errei e o que eu tenho que fazer diferente.

• Primeiro, criei um balanceador de carga com minha única instância principal, chame de "instância A"
• Em seguida, criei dois alarmes do CloudWatch "instância A" monitorando a carga da CPU. Em seguida eu criei uma imagem de "instância A"
• Em seguida, criei uma configuração de inicialização para o meu AMI recém-criada.
• Em seguida, criei um grupo do Auto Scaling e vinculei ao meu Load Balancer e também configure os dois Alarmes de Escala que eu configuro anteriormente.
• Defino o grupo AutoScaling Min para 0 e Max para 3 porque Eu só quero começar a lançar instâncias quando minha instância original (instância A) ultrapassa a capacidade.

Então, basicamente, quero que minha instância original esteja em execução o tempo todo. Então, quando começar a ultrapassar a capacidade, eu quero que o Auto Scaling Group inicie as instâncias de inicialização e o Load Balancer para distribuir a carga entre elas. Meu pensamento aqui está soando?

Outras questões importantes.

Quando eu faço alterações de código e dados na minha instância original, eu tenho que refazer a imagem que minha configuração de inicialização usa?

O que precisa ser desativado com nomes DNS e IPs? Atualmente estou usando o Route 53, eu faço esse ponto para o meu Load Balancer e é isso?

Obrigado pessoal!

    

Answer 1

Vamos repassar suas dúvidas.

So basically I want my original instance to be running at all times. Then when it starts going over capacity I want the Auto Scaling Group to start launching instances and the Load Balancer to distribute the load across them. Is my thinking here sound?

Eu diria sim , mas tenho algumas reservas. Se bem entendi, você colocou sua instância "principal" fora do grupo de dimensionamento automático. Teoricamente, isso garantiria que o escalonamento automático não eliminasse sua instância original. Há algumas coisas que gostaria de mencionar:

• Você não está aproveitando totalmente as possibilidades do Auto Scaling. O Auto Scaling não apenas permite que sua configuração seja dimensionada, mas também pode garantir limites. Se, por qualquer motivo, sua instância "principal" morrer, sua política de dimensionamento automático não entrará em ação. Se você mantiver sua instância em um grupo de dimensionamento automático com min-size de 1, o Auto Scaling substituirá automaticamente a instância com falha.
• Quando o escalonamento automático é geralmente uma boa prática para tratar suas instâncias como "descartáveis", porque é assim que você cria sistemas resilientes. Não dependa de uma instância para estar sempre disponível.
• Você pode definir a política de finalização do seu grupo de dimensionamento automático para que termine sempre as instâncias mais recentes primeiro. Isso garantiria que sua instância "principal" seja mantida (desde que seja saudável). Meu comentário anterior ainda se aplica.

When I make code and data changes to my original instance, do I have to remake the image my Launch Configuration uses?

Eu diria no , mas isso é mais um problema de design. Sua imagem deve descrever o estado do seu servidor, mas não deve ser responsável pela distribuição do código. Considere uma situação em que você teria que atualizar seu aplicativo devido a um bug urgente, mas seus servidores estão sob carga alta. Faz a atualização do seu servidor principal, criando uma AMI, atualizando sua configuração de inicialização e matando seus servidores escalonados automaticamente para que possam ser recuperados com o som mais recente da AMI como uma solução atraente? Minha resposta para isso seria não (novamente). Observe as estratégias de controle e implantação da versão do código-fonte (sou desenvolvedor do Rails em 60% do tempo e uso git e capistrano , por exemplo).

Há situações em que sua abordagem também funcionaria e há muito meio-termo aqui (eu também recomendaria ver os scripts Chef e userdata ). Eu mesmo, na verdade, raramente uso AMIs personalizadas, graças a Chef .

What needs to be down with DNS names and IPs? I'm currently using Route 53, do I make that point to my Load Balancer and that's it?

Basicamente, sim . Você pode selecionar o (s) balanceador (s) de carga que deve (m) ser anexado (s) a novas instâncias ao criar seu grupo de dimensionamento automático. Eu ainda não usei a GUI para Auto Scaling, mas tenho certeza que está lá em algum lugar. Caso contrário, a CLI ainda a suporta. Aponte seu registro Route53 para seu ELB alias e é basicamente isso.

Resposta a perguntas adicionais (2014/02/23):

Se você está desenvolvendo usando o Rails, eu recomendo o Capistrano para implementações, que podem levar uma versão específica do seu aplicativo em seu sistema de controle de versão preferido (como o git) e implemente-o em vários servidores em um ambiente específico. Há um monte de tutoriais por aí, mas os Railscasts revisados (e pro) de Ryan Bates sobre o assunto são muito concisos, embora você precise de uma assinatura em seu site para assistir a ambos. A maioria dos outros tutoriais irá ajudá-lo também. Acione um novo servidor com a sua AMI e um script de lançamento que extrai um clone temporário do seu git repo e executa um comando local do Capistrano para ativar seu aplicativo. Isso garante que, mais tarde, você também possa implantar novas versões de seu aplicativo usando o Capistrano com apenas um comando para todos os servidores em execução.

O Capistrano também oferece alguns outros benefícios, incluindo a possibilidade de executar tarefas específicas em todos ou em apenas um dos seus servidores e reverter uma implantação, o que é muito difícil de realizar usando apenas o git.