Como calcular os requisitos do servidor para um aplicativo Web

Estou desenvolvendo um back-end em que estarei expondo APIs para meu aplicativo móvel. Os usuários podem se registrar, adicionar produtos, compartilhar os links de produtos por e-mail / sms / em qualquer lugar e outros podem clicar nele e comprar o produto. Este é o fluxo de trabalho simples do aplicativo móvel. O aplicativo é um aplicativo intensivo de imagens que terá uploads e recuperação de imagens que serão feitos por serviços em nuvem de terceiros. Portanto, a parte da imagem não é tratada pelo meu back-end.

Agora sou da equipe de desenvolvimento e tenho pouca experiência no lado do servidor de hardware. Quando dei o requisito para a infraestrutura, eles me fizeram as seguintes perguntas.

1. Taxa de transferência de aplicativos / armazenamento
2. Taxa de transferência do aplicativo (número de conexões simultâneas em 3 meses, 6 meses e 1 ano)
3. Taxa de transferência de armazenamento (crescimento de dados em 3 meses, 6 meses e 1 ano)
4. Requisito de HA
5. Requisito de DR

Não sei como faço para prever os 3 pontos acima. Como são calculadas as vendas por meio de venda? Em uma estimativa, teremos 10000 usuários registrados no meu aplicativo no primeiro mês, dos quais 5000 serão usuários ativos. Em um login médio no aplicativo, haverá 10 ocorrências de API por usuário, o que levará a 5000 * 10 = 50.000 ocorrências por mês, o que equivaleria a 1 ocorrência de API por minuto, ou seja, ~ 2 conexões simultâneas no primeiro mês.

O cálculo é assim? e como faço para calcular o crescimento de dados? Isso significa que um usuário registra, cria um produto e se eu totalizar o tamanho do banco de dados consumido para isso, é isso que é chamado de crescimento de dados?

Essa pergunta parece patética, mas eu realmente preciso de ajuda para descobrir como as taxas de transferência são calculadas para os requisitos do servidor.

Os três primeiros pontos são o planejamento de capacidade. A organização está tentando fazer um orçamento e prever o futuro. Infelizmente, não há uma maneira simples ou aceita de prever desempenho e escalabilidade. Cada aplicativo e ambiente é diferente. Portanto, a melhor maneira de responder a isso é medir.

Especificamente:

1. Discuta com seus gerentes ou proprietários do produto qual será o provável crescimento de usuários e os tipos de usuários diferentes. Se eles não sabem, adivinhe, mas documente que essas são suposições.
2. Crie uma execução automatizada de caminhos comuns do seu aplicativo. Você pode registrar atividades ou inserir suas próprias aplicações de teste de carga, como o JMeter .
3. Crie um ambiente de teste que corresponda ao seu hardware atual ou projetado. Preste muita atenção a coisas como largura de banda, armazenamento, SSL, log ou outros aspectos frequentemente esquecidos que podem afetar o desempenho. Troque o serviço de imagem de terceiros, se puder, usando imagens menores ou representativas.
4. Use o aplicativo de teste de carga para criar o proposto para o número projetado de usuários em momentos diferentes.
5. Use uma ferramenta de gerenciamento de desempenho de aplicativos, como AppDynamics ou DynaTrace , para medir o desempenho e identificar gargalos.

Além dos requisitos acima, isso pode ajudá-lo a:

1. Confirme se o seu ambiente suporta a carga solicitada.
2. Encontre a carga máxima suportada pelo seu ambiente.
3. Encontre os gargalos que limitam seu desempenho ou escalabilidade.
4. Experimente diferentes configurações para ver o desempenho ou a escala.
5. Observe como o sistema lida quando você aciona falhas.

Os dois últimos pontos, requisito de alta disponibilidade (HA) (alta disponibilidade) e DR (recuperação de desastre, presumivelmente RPO (objetivo do ponto de recuperação) e RTO (objetivo do tempo de recuperação) ), são mais difíceis de prever, pois são realmente requisitos de negócios. Discuta com seus gerentes ou proprietários do produto as prováveis ​​falhas e quanto elas custarão para mitigar ou corrigir . Se vocês dois são novos nisso, espere muitas adivinhações e noites tardias de sua parte.

Eu proporia uma base mais objetiva. Vá para os logs HTTP existentes. Supondo que seja uma atualização para um aplicativo já existente no campo, basta puxar os logs e examinar as solicitações HTTP incluídas. Isso fornece uma base objetiva absoluta para a modelagem de sua carga, em vez de um dedo molhado no ar para testar o vento.

Além disso, lembre-se de uma perspectiva de controle de qualidade. Você não pode possuir o requisito e a validação. Portanto, você pode usar os dados objetivos dos logs para ajudar a construir a informação do modelo de carregamento, mas alguém da empresa precisa assinar a definição real. Por quê? Como você está injetando um requisito no fluxo que até agora não estava disponível para os desenvolvedores, arquitetos, gerentes de plataforma, etc ... se você falhar no aplicativo, deseja que os negócios atrás de você sejam os números precisos.

O que você pode puxar os logs?

• Maior taxa de transações por hora (solicitações de contagem bloqueadas por hora)
• Usuários mais altos por hora (contar o endereço IP bloqueado por hora)
• Fluxos de dados do usuário (consulte a etiqueta de referência nos pedidos para criar uma árvore de pedidos anteriores)
• Tempos de resposta existentes (se você tiver o campo do tempo w3c ativado para suas chamadas de serviços da web). Isso pode ser usado para definir expectativas de lançamentos futuros de maneira objetiva, para atingir ou exceder o modelo atual
• Pense nos tempos dos atrasos entre solicitações por IP. Você pode modelar os pontos de amostra no tempo entre duas solicitações, agarrando a etiqueta de referência e bloqueando o endereço IP para criar um conjunto de amostras. Em seguida, você pode obter estatísticas nessas amostras para os tempos de reflexão mínimo, máximo, médio e percentil 90. Heck, alguns pacotes de estatísticas ainda fornecem uma função na qual você pode inserir um número aleatório para obter uma distribuição apropriada à produção
• Se você tiver registros de períodos anteriores, poderá projetar modelos de crescimento para o observado versus o desejado (vendas ou projeções de uso)

Eu prefiro o Splunk para esse tipo de trabalho. Para a maioria das organizações, você deve poder extrair logs de 30 dias no nível gratuito sem ter que se preocupar em configurar meia dúzia de aplicativos diferentes juntos, como você faz com a pilha ELK.

Entenda os requisitos erroneamente e você pode estar perseguindo fantasmas de engenharia que nunca ocorreriam na produção e não reduziriam nenhum risco. Certifique-se de que alguém do lado comercial atenda às suas necessidades ou você poderá possuir excedentes orçamentários individualmente para perseguir não defeitos.

Eu realmente gosto da sua pergunta. É um bom. Eu não acho que haja uma resposta real para isso, mas vou tentar. Ao criar / projetar um novo servidor, é mais importante escolher o ambiente
e os métodos certos . Nem todos os ambientes são escaláveis, principalmente de maneira limitada. O que a equipe de hardware está tentando calcular é que tipo de sistemas de arquivos e interfaces eles podem usar. Alguns sistemas de arquivos são fáceis de configurar, mas difíceis de expandir. Outros são difíceis de configurar, mas fáceis de gerenciar e expandir.

A melhor coisa, na minha opinião, é entrar em contato com aqueles que fazem essas perguntas e explicar por que você não pode respondê-las agora. Ao iniciar um novo aplicativo ou sistema, ninguém pode dizer como tudo isso evolui, especialmente quando não há outro sistema com o qual você possa comparar. Mas você tem o conhecimento sobre a API que você projetou e o "Hardware-Man" tem o conhecimento de como seus ambientes / servidores funcionam. Juntos, você pode descobrir essas questões com certeza.

Espero que isso ajude você.