Estimativa dos limites de simultaneidade para uma arquitetura AWS executando o WordPress

1

Eu estou tentando estimar um número de usuários simultâneos que uma instalação do WordPress AWS pode suportar (que precisa estar altamente disponível e suportar grandes cargas). Me pedem uma faixa solta que eu diria que podemos garantir (eles perguntaram ao cara que é novato no DevOps ...).

A arquitetura é a seguinte:

  • Duas instâncias do% RDSr5.2xlarge (principal + réplica de leitura) para o banco de dados.
  • Um grupo de escalonamento automático que gerencia entre 1 e 25% das instâncias do EC2 emt2.2xlarge
  • CloudFront como um CDN para o conteúdo.

Algumas condições sobre o aplicativo:

  • Existem cerca de 1300 publicações.
  • Cada página pesa entre 200 Kb e 3 Mb (muito raro), sendo principalmente cerca de 500 Kb.

Obviamente, o objetivo é ter tempos de resposta "razoáveis", embora eu não tenha sido informado de um intervalo.

Por usuários simultâneos , quero dizer petições simultâneas ou ocorrências. Eu adoraria testá-lo, mas infelizmente eu preciso de muitos recursos pagos.

Eu realmente não sei qual é o raciocínio correto para aplicar aqui. A coisa mais útil e relacionada que eu encontrei até agora é isso - no entanto, as condições são bem diferentes e não podemos pegar os números e escalá-los linearmente. O autor do post mediu que, com 18% det2.medium de instâncias funcionando a 60%, é possível executar o WP com 90 RPS e manter tempos de resposta de aproximadamente 350ms. Estender essa conclusão para minha arquitetura escapa da minha compreensão.

Idealmente, além de uma resposta ao meu problema, gostaria de obter um método para obter respostas válidas para essas perguntas.

    
por Alexander George 07.10.2018 / 23:16

1 resposta

1

Normalmente, não nos perguntam quantos usuários uma determinada arquitetura pode suportar, em vez disso, nos perguntam qual arquitetura precisamos para suportar um determinado número de usuários. Não é uma questão mais importante?

De qualquer forma, algumas notas:

  • Se você projetar sua arquitetura para ser verdadeiramente escalável em todas as camadas - entrega de conteúdo (Cloud Front), servidores da Web (sem estado, descartáveis), armazenamento de arquivos (EFS, S3), banco de dados Aurora, réplicas somente leitura) - então você não precisa se preocupar muito com quantos usuários uma determinada configuração pode suportar. Se a demanda for menor ou maior, a arquitetura simplesmente será dimensionada para atender à demanda.
  • Sua arquitetura parece estar no caminho certo para escalabilidade, então eu acho que a melhor maneira é levantar uma prova de conceito e fazer um teste de carga profissional . Existem empresas que podem fazer isso de locais geograficamente dispersos. Isso vai mostrar como o seu design executa e de lá você será capaz de interpolar o várias configurações necessárias para vários números de usuários simultâneos.

  • Uma palavra de advertência sobre os tipos de instâncias T2 - eles usam os chamados créditos da CPU , o que os faz rodar rapidamente por um curto período de tempo baixa. Quando estão ociosos, acumulam esses créditos novamente e, por algum tempo, podem correr mais rápido novamente. Isso é ótimo para a carga de trabalho que vem em picos, mas para uma carga sustentada, você ficará melhor com, por exemplo, Tipos de instâncias M5 (por exemplo, m5.large) - oferecem um desempenho consistente.

  • É melhor ter número maior de instâncias menores (por exemplo, 20x m5.large ) em vez de um número menor de instâncias grandes (por exemplo, 5x m5.2xlarge ) - a escala de entrada e saída é mais suave, o desempenho do disco é melhor, a falha de um único nó não tem um impacto tão grande, etc.

  • Considere o uso de instâncias spot e frotas spot para economia extra nos custos de sua instância.

  • Você mencionou que veicula algumas publicações - se esses documentos PDF estiverem estáticos, será muito melhor armazená-los no S3 e ler o CloudFront diretamente no S3 sem passar pelo seu WordPress em tudo. Se eles não são públicos e precisam, por exemplo um visto de assinatura em URLs assinados do CloudFront / S3 . Isso reduzirá significativamente a carga nos seus servidores WordPress.

Espero que ajude:)

    
por 08.10.2018 / 01:08