Quand commencer à penser à l'évolutivité? [fermé]

J'ai un problème drôle mais aussi terrible. Je suis sur le point de lancer une nouvelle application (iPhone). C'est un jeu multijoueur au tour par tour fonctionnant sur mon propre backend personnalisé. Mais j'ai peur de me lancer.

Pour une raison quelconque, je pense que cela pourrait devenir quelque chose de grand et que sa popularité tuera mon pauvre serveur unique solitaire + base de données MySQL.

D'une part, je pense que si elle croît, je ferais mieux d'être préparé et d'avoir une infrastructure évolutive déjà en place.

D'un autre côté, j'ai juste envie de le diffuser dans le monde et de voir ce qui se passe.

Je lis souvent des trucs comme "l'optimisation prématurée est la racine de tous les maux" ou des gens qui disent que vous devriez juste construire votre jeu de tueur maintenant, avec les outils à portée de main, et vous soucier d'autres choses comme l'évolutivité plus tard.

Je serais ravi d'entendre des opinions d'experts à ce sujet ou de personnes expérimentées. Merci!

C'est en fait un choix assez facile.

À l'heure actuelle, vous n'avez aucun utilisateur et l'évolutivité n'est pas un problème.

Idéalement, vous voulez atteindre le point où vous avez des millions d'utilisateurs et l'évolutivité devient un problème.

Pour l'instant, vous n'avez pas de problème d'évolutivité; vous avez un problème de nombre d'utilisateurs. Si vous travaillez sur le problème d'évolutivité, vous ne réglerez pas le problème du nombre d'utilisateurs, ce qui signifie que vous aurez résolu un problème que vous n'avez pas encore, et vous n'aurez pas résolu le problème que vous avez. Le résultat le plus probable est que votre produit ne le fera pas, et tout votre travail sera pour rien.

Si vous travaillez sur le problème du nombre d'utilisateurs, vous allez résoudre un problème que vous avez en ce moment, puis vous pouvez vous concentrer sur le problème suivant, qui peut être l'évolutivité.

La bonne chose à propos des problèmes d'évolutivité est que, par définition, les avoir signifie généralement que les affaires sont sacrément bonnes, ce qui signifie que vous pouvez vous permettre de dépenser de l'argent pour optimiser l'évolutivité. Vous ne passez pas de zéro utilisateur à dix millions du jour au lendemain, et si vous gardez un œil sur les performances du système, vous aurez amplement le temps d'optimiser le moment venu.

Bien sûr, cela aide à garder l'évolutivité à l'esprit lors de l'écriture du code dont vous avez besoin en ce moment, mais cela n'a pas beaucoup de sens de dépenser des dizaines voire des centaines d'heures de travail sur une fonctionnalité dont vous ne savez pas si vous j'en aurai jamais besoin, et le scénario le plus probable est que vous n'en aurez pas. À l'heure actuelle, votre principale préoccupation est d'expédier. Que se passe-t-il après cela; vous pouvez vous en soucier plus tard.

Il n'y a aucune raison d'optimiser tant que vous ne savez pas que l'optimisation est nécessaire. Comment savez-vous que l'optimisation est nécessaire? Vous mesurez.

En supposant que votre serveur possède une sorte d'interface Web, vous pouvez simuler un grand nombre d'utilisateurs en utilisant des outils tels que Apache JMeter . Apprenez à utiliser l'outil, puis lancez des tests de résistance de votre back-end. Vous devriez être en mesure d'en apprendre suffisamment pour connaître les limites de votre système. Vous pouvez ensuite combiner ces informations avec le nombre d'utilisateurs que vous avez et le nombre moyen qui s'exécutent en même temps, pour décider du moment de l'extension.

TL; DR Vous devez penser à l'évolutivité avant d'écrire la première ligne de code.

Tout d'abord. Évolutivité! = Optimisation

Vous devez penser à l'évolutivité avant d'écrire la première ligne de code. Cela ne signifie pas que vous construisez une infrastructure massive au cas où votre jeu pourrait être un succès. Penser l'évolutivité signifie:

• S'assurer que le code est écrit pour qu'il évolue. J'ai vu de nombreux projets où aucune réflexion n'a été apportée à la nécessité d'évoluer. Les résultats sont une base de code qui ne sera pas mise à l'échelle quel que soit le matériel que vous lui lancez, ou dont le coût de mise à l'échelle est prohibitif.
• Déterminez votre stratégie de mise à l'échelle. Ayez un plan sur la façon de soutenir tous les utilisateurs. Vous avez une base de données MySQL, allez-vous la scinder ou la mettre en cluster, ou autre chose. Des stratégies comme le sharding nécessitent une certaine réflexion car elles imposent des exigences à l'architecture. Clustering, moins. Soutenez-vous les sessions et comment les sessions réagiront-elles avec plusieurs serveurs frontaux? Aurez-vous besoin de sessions collantes, dans votre équilibreur de charge.
• Déterminez la stratégie de mise en œuvre. Allez-vous utiliser AWS pour la mise à l'échelle. Pouvez-vous tirer parti de produits ou services qui vous offrent une évolutivité dynamique prête à l'emploi? Cela implique également de comprendre vos coûts.

MAIS il semble que vous ayez déjà une base de code. La question est maintenant de savoir quand commencer la mise à l'échelle. Cela dépend complètement de votre code.

Si votre code se prête à la mise à l'échelle, la partie difficile est terminée. Vous pouvez obtenir un compte AWS, faire tourner des serveurs au besoin et vous partez.

Si votre code n'évolue pas ou présente des goulots d'étranglement, vous avez du travail à faire. Vous devez identifier vos goulots d'étranglement et les corriger. Le "quand" est vraiment difficile à savoir. Certains services atteignent un plateau, certains augmentent régulièrement et certains explosent. Décider quand affecter des ressources à quelque chose comme la mise à l'échelle est généralement une fonction de l'entreprise et c'est une évaluation des risques.

À votre place , je pourrais sortir en "beta" et gérer les attentes des utilisateurs. De cette façon, je peux sortir le produit et voir comment il se déroule.

Il y a donc deux fois que vous devriez penser à l'évolutivité.

Tout d'abord, il doit être soigneusement réfléchi avant d'écrire une seule ligne de code. C'est pour vous assurer que vous ne vous écrivez pas dans un trou d'évolutivité et pour vous assurer que votre code est instrumenté pour vous donner les mesures dont vous avez besoin pour la deuxième fois.

La deuxième fois que l'on considère l'évolutivité, c'est suffisamment d'avancées ralentissant de manière inacceptable. Cela signifie que vous devez savoir ce que signifie «trop lent» et comment votre chose réagit sous charge. Si vous avez un service dont le pilote (probablement qps) augmente de N% par mois, vous avez des temps plutôt différents de "95% des ressources machine consommées" si votre utilisation des ressources est quadratique ou linéaire en charge.

Avec un jeu au tour par tour, vous devriez avoir une marge de sécurité décente (vous n'avez probablement pas un seul monde de jeu, et si vous en avez, il y a probablement une géométrie interne, ce qui signifie que vous n'avez pas "tout le monde interagit avec chacun chacun "problèmes").

Sans connaître les détails, je prendrais un ou deux jours pour réfléchir à l'endroit où vous avez des problèmes de mise à l'échelle et quelles stratégies possibles vous avez pour les résoudre. Mais, c'est important, pensez-y. Ne faites pas, pensez juste (et documentez). À moins que vous n'ayez des problèmes d'évolutivité qui commencent à se manifester à quelques centaines d'utilisateurs, vous devriez alors avoir le temps de vérifier la charge et d'augmenter le nombre de ressources principales.

D'après votre description, il semble qu'il y ait deux résultats possibles:

• Le jeu est un échec et puis vous vous en fichez.
• Le jeu est réussi et votre backend ne pourra pas gérer la charge et le résultat sera un échec.

Hmmm.

Voici quelques questions à vous poser:

• Combien d'utilisateurs votre backend actuel peut-il gérer avec des performances acceptables?
• Avez-vous une sorte de plan pour limiter l'impact sur les utilisateurs actuels si vous voyez une sorte de croissance rapide (par exemple, retirer temporairement le jeu de l'App Store)
• En combien de temps pouvez-vous trouver un meilleur backend si vous réussissez?
• Quelles sont les implications commerciales de l'attente. Pouvez-vous vous nourrir? Quels sont les risques?
• Quelles sont les implications commerciales de la sortie maintenant, étant donné les réponses à la question ci-dessus.

La réponse à votre question devrait devenir évidente une fois que vous les aurez étudiées. Aucun expert ne peut vous dire quoi faire sans plus d'informations, car chaque système est différent et chaque entreprise est différente.

Votre serveur sera utilisé de manière interactive par les utilisateurs. Cela signifie que la latence affecte l'expérience utilisateur de manière très profonde. Une latence incorrecte entraîne toujours une mauvaise expérience utilisateur.

Faites au moins quelques tests de charge ad hoc comme décrit par Bryan.

Une approche plus sérieuse

Faites quelques exécutions de simulation et découvrez ce que la latence fait à votre expérience utilisateur (soit en utilisant une simulation de retard de réseau ou tout simplement sleep () à l'intérieur de votre application). Découvrez à quelle latence cela devient perceptible, ennuyeux et inutilisable.

Vient ensuite le premier pas vers l'optimisation. Décidez d'un SLA pour votre serveur: par exemple au pire 10% d'appels avec une latence gênante et 1% d'appels avec une latence inutilisable. Avec ces limites, vous pouvez utiliser le test de charge pour savoir combien d'utilisateurs votre serveur peut prendre en charge.

Le test de débit pur sans mesurer la latence (ou au moins manuellement en utilisant le serveur pendant le test de charge) n'est pas très utile car il ne vous dit pas si les nombres de débit mesurés entraînent une expérience utilisateur supportable.

Une très belle présentation sur la mesure de la latence par Gil Tene: http://www.infoq.com/presentations/latency-pitfalls

Au stade des exigences métier, qui est ensuite utilisé pour établir une compréhension commune des performances pour tous les éléments en aval tels que l'architecture, les opérations, le développement, l'assurance qualité et la surveillance en prod. Si vous n’établissez pas une compréhension commune de ce qui est requis à l’avance, chacune des parties de l’organisation émettra des hypothèses sur la performance (ou n'y pensera pas du tout) lorsqu’elle s’engagera dans des tâches particulières tout au long du cycle de vie du application. Cela est vrai que vous soyez engagé dans une cascade, une cascade courte, agile ou quelle que soit la méthodologie de développement du moment, c'est chaud sur la liste des mots clés de CV.

Les performances et l'évolutivité sont difficiles. La fonctionnalité est simple. Un code de mise à l'échelle médiocre se développera pour remplir le pool de ressources que vous lui fournissez.Par conséquent, déplacer la bulle des coûts en achetant du matériel plus volumineux ne vous prend que bien avant de devoir corriger le code inefficace ou acheter toujours plus de matériel. Laisser cela durer en priorité est également très coûteux. Il y a des décisions d'architecture et de conception qui sont prises au début du cycle de vie de l'application et qui peuvent devoir être complètement inversées afin de répondre à une exigence tardive liée aux performances - Pensez à un fabricant de voitures de sport haute performance devant passer de l'aluminium à la fibre de carbone en fin de cycle de conception pour atteindre un rapport puissance / poids lié aux performances et comment cela impacte l'outillage, la formation, la construction de la voiture, etc ...

Demandez aux architectes, développeurs et opérateurs de votre organisation quelles sont les performances requises pour l'application. Si celles-ci ne sont pas saisies dans l'entreprise, ne soyez pas surpris si vous recevez des réponses différentes (ou aucune réponse) de différentes personnes, même au sein du même groupe. Ces «hypothèses» reviennent toujours pour faire claquer l'organisation en cours de déploiement.