Como evitar o abraço da morte na instância EC2?

Eu tenho um aplicativo iOS na loja de aplicativos e, recentemente, recebi um grande aumento de tráfego na minha página de destino hospedada no EC2 e resultou na página não responder, felizmente consegui recuperá-lo reiniciando e atualizando a instância para um t2.medium.

Agora, estou procurando contratar alguém para implementar uma tecnologia para evitar a mesma morte novamente. Minha experiência só foi tão longe, permitindo-me entender coisas básicas sobre devops, mas não o suficiente para o balanceador de carga na AWS. Quero saber o que é uma implementação acessível para minha instância.

Minha página de destino e o back-end do aplicativo iOS estão hospedados na mesma instância.

Se você quiser algo rápido para resolver isso sem muito mais conhecimento, recomendo o pé de feijão elástico. É outro aplicativo da AWS que manipulará a configuração do balanceador de carga e o dimensionamento da instância para você.

Não há custo adicional sobre o balanceador de carga e instâncias, para que você possa continuar usando instâncias do tipo t2, mas permita que o pé de feijão elástico seja escalado o quanto você quiser ajudar.

O dimensionamento automático não é instantâneo e, em períodos de pico de tráfego, levará um curto período de tempo, minutos normalmente, para lidar com um pico, mas será muito melhor do que dimensionar manualmente o tamanho da instância e é realmente fácil de entender com.

Eu recomendaria o auto-scaling, como mencionado acima, com a adição de alguns alarmes do CloudWatch para iniciar o processo de auto-scaling quando limites específicos começarem a aumentar, não quando ele já estiver muito longe.

Por exemplo; configure o CloudWatch para monitorar seu servidor, quando a CPU estiver em 50% ou mais por um período de 30 segundos ou mais, inicie o processo de dimensionamento automático.

Isso pode não ser completamente sem falhas, mas é fácil fazer isso através de alguns guias on-line e tudo configurável via GUI.

Além disso, se sua página de destino é estática, por que não hospedá-la em um nível gratuito t2.micro e usar outro nível gratuito t2.micro para seu aplicativo?

Eu adoraria ajudar com isso, se você estiver procurando por alguma ajuda. Dependendo da sua página, talvez você não precise do ec2. Por exemplo, se você veicular algo estático ou JavaScript, ele pode ser veiculado no s3 com uma distribuição na nuvem. Ou podemos usar um grupo de dimensionamento automático, se for absolutamente necessário.

Existem duas estratégias gerais para lidar com os surtos de tráfego: aumentar a capacidade e reduzir custos.

Aumentar a capacidade significa dimensionamento automático, motivo pelo qual todos ficaram muito entusiasmados quando as nuvens públicas se tornaram disponíveis. Em seu sentido mais básico, isso inicializará mais servidores da Web para você com base na carga e os adicionará a um balanceador de carga, mas como pode ser difícil de gerenciar, também existem mais soluções auto-mágicas, como o Elastic Beanstalk.

O problema da expansão automatizada da capacidade é que ela também se expande automaticamente - 10x tráfego normal significa 10x servidores significa 10x dinheiro que você precisa pagar. É por isso que, embora seja uma estratégia útil a ser lembrada, acho que você deve sempre começar vendo o quanto pode trapacear.

Como trapaça, quero dizer cache, que se baseia na idéia de que na maioria das vezes você pode fornecer aos usuários dados levemente desatualizados e eles não perceberão, o que pode economizar uma quantidade enorme de tempo. Imagine que você tem uma página que decide que está tudo bem se estiver cinco segundos desatualizada e obtém 20 req / s. Sem o armazenamento em cache, você está executando esse cálculo 1200 vezes por minuto, enquanto no armazenamento em cache é apenas 12. Você pode ver como isso pode fazer uma tremenda diferença.

Obviamente, existem muitos tipos de cache, e um site bem-sucedido utilizará vários deles. Mas para o seu caso de uso, existem duas opções muito boas e fáceis.

A primeira é tornar o site completamente estático. Isso pressupõe que você possa fazê-lo, mas, se puder, basta solicitar ao Nginx o html diretamente, e ele pode atender a inúmeras solicitações sem suor.

Se você precisar de algum nível de dinamicidade, fazer um cache de página inteira é uma boa opção. O Nginx tem alguma capacidade para fazer isso, mas eu realmente gosto de verniz devido à sua flexibilidade.

Qualquer que seja a opção ou opções que você escolher, verifique se você carregou o teste para confirmar se o configurou corretamente; às vezes, a fixação de um ponto expõe um novo gargalo.

Gostaria de compartilhar nossa experiência com a AWS. Implantamos nosso aplicativo no EC2 e enfrentamos o mesmo problema e também alto custo. Implementamos nosso aplicativo Amazon EC2 Container Service, embora nosso aplicativo fosse monolítico, mas alcançamos

• Disponibilidade
• Custo-beneficio
• Escalabilidade

O balanceador de carga de aplicativo manipula o tráfego e direciona o tráfego para a instância íntegra e você pode executar várias tarefas dos mesmos serviços sem se preocupar em dimensionar e equilibrar a carga.

Essa arquitetura facilita a implementação do isolamento de falhas. Técnicas como verificação de integridade, armazenamento em cache, anteparas ou disjuntores permitem reduzir o raio de explosão de um componente com falha e melhorar a disponibilidade geral de um determinado aplicativo.

Isso depende muito da arquitetura específica, mas por exemplo:

• Carregue com antecedência seu site com o CloudFront para reduzir a carga no host
• Use o serviço de hospedagem do lado do cliente em algo como S3 para dimensionar
• Elastic Load Balancer com um grupo de Escalonamento Automático