Escalando um único site WordPress via AWS / EC2

Question

Eu gerencio um site que é essencialmente apenas uma notícia / blog alimentado pelo WordPress. Os usuários médios no site estão entre 8 e 15. Mas ocasionalmente nós quebramos as notícias em nosso nicho, onde teremos de 1,5 a 5 mil pessoas. Até hoje, estávamos hospedando o site em um VPS por meio do Dreamhost . Mudamos para o AWS / EC2 porque achamos que a escalabilidade seria interessante.

Eu fiz backup de todo o nosso servidor, iniciei uma instância do EC2 (t2.micro executando o WordPress para AWS da Bitnami ), criou uma unidade de armazenamento para ele, deu um IP elástico, migrou e restaurou todos os nossos dados (usando UpdraftPlus). Fiquei feliz que o servidor estava agindo de forma razoável, derrubou nosso servidor anterior e criou um registro de DNS apontando para o IP da instância do AWS.

No entanto, hoje encontramos um problema em que a CPU estava atrelada a 100% de utilização, com os créditos da CPU ainda disponíveis. Eu achava que os créditos de CPU disponíveis escalariam o servidor para que ele não fosse indexado a 100% de uso. Eu acho que entendi mal. Então, achei que precisava configurar um grupo de escalonamento automático. Então, criei uma AMI a partir da instância que eu já tinha configurado, criei uma configuração de inicialização e criei um balanceador de carga. Em seguida, defino o grupo de escalonamento automático para ter 1 instâncias Desejada, 1 Mínima e 5 Máxima, para iniciar uma instância se CPU = > 85% e para fechar um se CPU = < 35%.

Eu pensei que teria sido bom, mas me deparei com um problema em que uma vez eu configurei isso. Ele encerrou a instância que configurei anteriormente e derrubou todo o meu site. Eu então corri em pânico até perceber que não havia apagado o armazenamento, e lancei outro e liguei esse disco.

Estou sentindo falta de algo aqui? Como posso configurar o AWS / EC2 para lidar com alguns milhares de usuários usando exatamente os mesmos dados / site, e sempre tê-lo, não ter que finalizar minha instância original?

Qualquer ajuda seria muito apreciada.

    

Answer 1

Um pouco mais de leitura na AWS e na prática fora da produção seria uma boa ideia. Existem muitos guias, e a própria AWS fornece ótimas informações, não é difícil. Você deve realmente testar em outro VPC ou região antes de trabalhar em sites de produção.

t2.micro é limitado a apenas um núcleo, independentemente dos créditos da CPU. Escalonamento automático leva tempo para chutar, dependendo dos intervalos de alerta / monitoramento. Você pode adicionar instâncias existentes a um elb, mas eu teria a tendência de configurá-lo, adicioná-lo e, em seguida, deixá-lo adicionar sua (s) própria (s) instância (s) e parar o original.

Um grupo de escalonamento automático, "golden" AMI e RDS seria a opção simples. No entanto, você pode acabar com diferentes versões do Wordpress, então isso requer mais reflexão. Você pode configurar o armazenamento em cache no nível do servidor da Web, o Nginx é excelente e reduziria sua carga enormemente - pelo menos em uma ordem de magnitude.

Eu tenho um tutorial que pode ser útil para você aqui . Não entro em escalonamento automático, já que não precisei de mim mesmo, mas é simples de configurar - já fiz isso muitas vezes.

    

Answer 2

Quando você começa a trabalhar com o Auto Scaling, precisa se acostumar com um único fato: instâncias do EC2 serão iniciadas e as instâncias do EC2 serão encerradas. Mesmo com Min = Max = 1, sua instância pode terminar a qualquer momento e ser substituída. Não pense nisso como algo ruim, apenas se acostume com isso e jogue junto. A longo prazo, é uma coisa muito boa.

Para começar o Auto Scaling, você precisa mover seu banco de dados para fora de suas instâncias com escala automática. Os dados podem estar em outra instância do EC2 ou podem estar em uma instância do RDS. Isso não importa. Mas não deve estar nas instâncias do EC2 que estão sendo iniciadas e finalizadas. Existem duas razões principais para isso:

• Como mencionado anteriormente, sua única instância do EC2 pode ser encerrada e substituída ou
• Você pode acabar com 2 ou mais instâncias do EC2 que exigem acesso ao mesmo conjunto de dados.

Depois de ter seus dados de suas instâncias do EC2, você configurará uma instância "master" do EC2. Este "mestre" será a instância do EC2 que você SSH (ou RDP) para atualizar seu site WordPress de uma perspectiva de código / versão. Ele será interrompido por 99% da sua vida útil. Seu único objetivo é gerar uma nova imagem AMI quando você atualizar a versão ou o código do seu site WordPress. Você:

• inicie-o
• faça login e atualize seu site
• pare a instância
• crie a AMI
• atualize seu grupo Auto Scaling com o novo AMI
• finalizando suas instâncias existentes do Auto Scaling EC2, elas serão substituídas por novas instâncias do EC2 de sua nova AMI. Tenha em atenção que, durante este período, poderá haver instâncias do EC2 a executar versões diferentes do seu site.

Se puder, eu recomendaria o seguinte:

• Use vários AZs para o seu grupo Auto Scaling e
• Tenha no mínimo 2 instâncias, não 1.

Dessa forma, você não tem uma única instância do EC2 que derrubará todo o site se ele cair.

Existem outras maneiras de lidar com o Auto Scaling, atualizações, etc. Mas, para um iniciante, a estrutura acima é bastante fácil de entender.