Comment calculer les exigences du serveur pour une application Web

Question

Je développe un backend où j'exposerai des API pour mon application mobile. Les utilisateurs peuvent s'inscrire, ajouter des produits, partager les liens des produits par e-mail/sms/n'importe où et d'autres peuvent cliquer dessus et acheter le produit. Il s'agit du flux de travail simple de l'application mobile. L'application est une application gourmande en images qui aura des téléchargements et des récupérations d'images qui seront effectués par un service cloud tiers. SO la partie image n'est pas gérée par mon backend.

Maintenant, je fais partie de l'équipe de développement et j'ai peu d'expérience côté serveur matériel. Lorsque j'ai donné l'exigence pour l'infrastructure, ils m'ont posé les questions suivantes.

1. Débit d'application/de stockage
2. Débit d'application (nombre de connexions simultanées en 3 mois, 6 mois et 1 an)
3. Débit de stockage (croissance des données sur 3 mois, 6 mois et 1 an)
4. Exigence HA
5. Exigence DR

Je ne sais pas comment prévoir les 3 points ci-dessus. Comment sont calculés les débits? Selon une estimation, 10000 utilisateurs s'inscriront sur ma demande au cours du premier mois, dont 5000 seront des utilisateurs actifs. Sur une connexion moyenne à l'application, il y aura 10 hits API par utilisateur, ce qui conduira à 5000 * 10 = 50 000 hits par mois, ce qui correspond à 1 hit API par minute, soit ~ 2 connexions simultanées le premier mois.

Est-ce que le calcul va comme ça? et comment calculer la croissance des données? Cela signifie-t-il qu'un utilisateur s'inscrit, crée un produit et si je totalise la taille de la base de données consommée pour cela, est-ce ce qu'on appelle la croissance des données?

Cette question semblerait pathétique, mais j'ai vraiment besoin d'aide pour comprendre comment les débits sont calculés pour les besoins du serveur.

Answer 1

Les trois premiers points sont la planification des capacités. L'organisation essaie de budgétiser et de prédire l'avenir. Hélas, il n'existe aucun moyen simple ou accepté de prédire les performances et l'évolutivité. Chaque application et environnement est différent. Par conséquent, la meilleure façon de répondre est de mesurer.

Plus précisément:

1. Discutez avec votre direction ou les propriétaires de produits de la croissance probable des utilisateurs et des types d'utilisateurs. S'ils ne savent pas, devinez mais documentez que ce sont des suppositions.
2. Créez une exécution automatisée des chemins communs de votre application. Vous pouvez enregistrer l'activité ou entrer la vôtre dans des applications de test de charge comme JMeter .
3. Créez un environnement de test qui correspond à votre matériel actuel ou projeté. Portez une attention particulière à des choses comme la bande passante, le stockage, SSL, la journalisation ou d'autres aspects souvent oubliés qui pourraient affecter les performances. Modifiez le service d'imagerie tiers si vous le pouvez, en utilisant des images plus petites ou représentatives.
4. Utilisez l'application de test de charge pour créer la proposition pour le nombre prévu d'utilisateurs à différents moments.
5. Utilisez un outil de gestion des performances des applications, comme AppDynamics ou DynaTrace , pour mesurer les performances et identifier les goulots d'étranglement.

En plus des exigences ci-dessus, cela peut vous aider:

1. Confirmez que votre environnement prend en charge la charge demandée.
2. Trouvez la charge maximale prise en charge par votre environnement.
3. Trouvez les goulots d'étranglement qui limitent vos performances ou votre évolutivité.
4. Expérimentez avec différentes configurations pour voir comment effectuer ou évoluer.
5. Observez comment le système réagit lorsque vous déclenchez des échecs.

Les deux derniers points, exigence HA (haute disponibilité) et DR (reprise après sinistre, vraisemblablement RPO (objectif de point de récupération) et RTO (objectif de temps de récupération) ), sont plus difficiles à prédire car ce sont vraiment des exigences commerciales. Discutez avec votre direction ou les propriétaires de produits des échecs probables et combien ils coûteront pour atténuer ou corriger . Si vous êtes tous les deux novices, attendez-vous à beaucoup de devinettes et de nuits tardives de votre part.

Answer 2

Je proposerais une base plus objective. Accédez à vos journaux HTTP existants. En supposant qu'il s'agit d'une mise à jour d'une application déjà sur le terrain, tirez simplement les journaux et examinez les demandes HTTP qui sont incluses. Cela fournit une base objective absolue pour votre modélisation de la charge au lieu d'un doigt mouillé dans l'air pour tester le vent.

Gardez également à l'esprit du point de vue de l'assurance qualité. Vous ne pouvez pas à la fois posséder l'exigence et la validation. Ainsi, vous pouvez utiliser les données objectives des journaux pour aider à créer les informations sur le modèle de charge, mais un membre de l'entreprise doit approuver la définition réelle. Pourquoi? Parce que vous injectez une exigence dans le flux qui n'était pas disponible jusqu'à présent pour les développeurs, les architectes, les gestionnaires de plate-forme, etc ... si vous échouez à l'application, vous voulez que l'entreprise derrière vous que les chiffres soient exacts.

Que pouvez-vous extraire les journaux?

• Taux de transaction le plus élevé par heure (nombre de demandes bloquées par heure)
• Nombre d'utilisateurs le plus élevé par heure (compte des adresses IP bloquées par heure)
• Flux de données utilisateur (voir la balise referer sur les requêtes pour construire une arborescence des requêtes précédentes)
• Temps de réponse existants (si le champ temporel w3c est activé pour vos appels de services Web). Cela peut être utilisé pour définir les attentes pour les futures versions sur une base objective pour atteindre ou dépasser le modèle actuel
• Pensez aux temps des retards entre les demandes par IP. Vous pouvez réellement modéliser les points d'échantillonnage sur le temps entre deux demandes en saisissant la balise de référence et en bloquant par adresse IP pour créer un jeu d'échantillons. Vous pouvez ensuite extraire les statistiques de ces échantillons pour les temps de réflexion minimum, maximum, moyen et 90e centile. Heck, certains packages de statistiques vous fourniront même une fonction dans laquelle vous pouvez insérer un nombre aléatoire pour obtenir une distribution adaptée à la production
• Si vous avez des journaux pour les périodes précédentes, vous pouvez projeter des modèles de croissance pour les résultats observés par rapport aux souhaits (ventes ou projections d'utilisation)

Je préfère Splunk pour ce type de travail. Pour la plupart des organisations, vous devriez pouvoir extraire 30 jours de journaux dans le niveau gratuit sans avoir à vous soucier de configurer ensemble une demi-douzaine d'applications différentes comme vous le faites avec la pile ELK.

Ne vous trompez pas et vous pourriez bien chasser des fantômes d'ingénierie qui ne se produiraient jamais en production et ne réduiraient en fait aucun risque. Assurez-vous que quelqu'un du côté de l'entreprise approuve vos besoins ou vous pourriez bien posséder des excédents budgétaires individuels pour chasser les défauts.

Answer 3

J'aime vraiment ta question. C'est une bonne chose. Je ne pense pas qu'il y ait une vraie réponse à cela, mais je vais essayer. Lors de la création/conception d'un nouveau serveur, il est plus important de choisir le bon
Environnement et méthodes. Tous les environnements ne sont pas scalabales, la plupart seulement de manière limitée. Ce que l'équipe matérielle essaie de calculer, c'est quel type de systèmes de fichiers et d'interfaces ils peuvent utiliser. Certains systèmes de fichiers sont faciles à configurer mais difficiles à étendre. D'autres sont difficiles à configurer mais faciles à gérer et à étendre.

La meilleure chose à mon avis est de prendre contact avec ceux qui vous posent ces questions et de leur expliquer pourquoi vous ne pouvez pas y répondre maintenant. Lors du lancement d'une nouvelle application ou d'un nouveau système, personne ne peut dire comment tout cela évolue, surtout quand il n'y a aucun autre système auquel vous pouvez vous comparer. Mais vous avez la connaissance de l'API que vous avez conçue et le "Hardware-Man" a la connaissance de la façon dont ses environnements/serveurs fonctionnent. Ensemble, vous pouvez comprendre ces questions avec certitude.

J'espère que cela vous aidera.