Qu'est-ce qui rend une application évolutive?
Je continue de voir dans les offres d'emploi que le candidat doit avoir de l'expérience dans la rédaction de candidatures "évolutives". Qu'est-ce qui rend une application évolutive et comment puis-je savoir que mon code peut évoluer vers des millions d'utilisateurs?
Je suppose qu'une meilleure façon de formuler cette question est la suivante: comment puis-je écrire mon code avec une évolutivité à l'esprit? Pour que le code soit évolutif dès le départ par opposition à une réflexion après coup. Existe-t-il certaines méthodologies de conception? Ou s'agit-il simplement de choisir les bons algorithmes pour le travail?
Il y a deux directions d'évolutivité:
- vertical (alias scaling up): CPU plus rapide, plus de RAM, plus d'espace disque;
- horizontal (alias scaling out): plus de cœurs dans le CPU, plus de CPU, plus de serveurs;
Pour le premier, il suffit de faire attention à ne pas avoir de limitations arbitraires. Celles-ci sont dues à des tailles entières trop petites ou à des structures de longueur fixe/limitée. Ces structures peuvent être liées au système d'exploitation sous-jacent. Par exemple, si vous essayez d'évoluer en utilisant plus de threads ou de processus, à un moment donné, vous allez atteindre les limites du système d'exploitation. C'est pourquoi actuellement les serveurs construits pour une évolutivité élevée font de la concurrence basée sur des événements asynchrones. Ce problème est décrit dans le célèbre document C10K .
Le deuxième est plus difficile. Cela nécessite une programmation avec deux choses à l'esprit: les données seront traitées en parallèle et les données peuvent être physiquement distribuées. La communication entre les nœuds doit être limitée. Dans la pratique, cela signifie généralement sacrifier certaines parties de l'ACID (il est prouvé que vous ne pouvez pas avoir un ACID complet et pouvoir évoluer en même temps). La solution la plus connue pour le stockage de données dans ce paradigme sont les solutions NoSQL . Ils vont des magasins de valeurs-clés très simples aux systèmes de type SGBDR, seulement dépourvus de la possibilité de faire des jointures. Les magasins de valeurs-clés sont ultra-évolutifs, mais cela a un prix. Vous pouvez essentiellement interroger uniquement sur la clé primaire. Il y a cependant une solution à cela, c'est map réduire . Cela peut sembler très sous-optimal si vous regardez le point de vue de la complexité cumulative, mais vous devez garder à l'esprit que cela fonctionne massivement en parallèle.
Si vous souhaitez en savoir plus sur l'évolutivité avec des exemples concrets, consultez HighScalability.com blog .
L'évolutivité est mesurée en termes de débit en fonction d'une variable. Par exemple, nombre de requêtes/seconde avec X utilisateurs. La façon la plus simple de décrire l'évolutivité est:
Une mesure de efficacité lorsque la charge augmente.
La première chose que vous devez comprendre lors de la conception de l'évolutivité est quelle mesure est la plus importante pour votre application? Il existe plusieurs façons de mesurer efficacité qui est un élément clé de l'évolutivité:
- Demandes simultanées par seconde
- Temps de réponse moyen par demande
- Nombre d'enregistrements traités par seconde/minute
D'autres mesures d'efficacité peuvent être utilisées, mais elles sont courantes pour les systèmes Web ou les systèmes de traitement par lots.
L'aspect suivant de l'évolutivité consiste à mesurer ce qui arrive à votre efficacité lorsque la charge augmente. Les moyens courants d'augmenter la charge sont les suivants:
- Plus d'utilisateurs atteignent le serveur (c'est-à-dire plus de trafic Web)
- Plus de données dans la base de données (c'est-à-dire que les requêtes prennent plus de temps ou le traitement prend plus de temps)
- Panne de disque dur dans un RAID (les performances/fiabilité du stockage sont affectées)
- Saturation du réseau
Le but d'une application évolutive est de maintenir ou d'améliorer l'efficacité lorsque nous traitons le problème de charge. Bref, si le temps de réponse prend trop de temps, peut-on ajouter un autre serveur pour répartir uniformément la charge? Cette approche réduit la quantité de travail à effectuer par un serveur et maintient les serveurs dans ce "point idéal" pour plus d'efficacité.
Votre application devra être conçue spécifiquement à l'échelle. Cela signifie que vous devez être prudent avec les données de session, acheminer les demandes vers le bon serveur, réduire les goulots d'étranglement qui limitent la capacité de l'application à évoluer.
Vous voulez essentiellement éviter les goulots d'étranglement des performances lorsque vous augmentez le nombre d'utilisateurs et/ou traitez un ensemble de données plus important et/ou offrez votre interface dans plus de langues, etc.
Vous jetez un coup d'œil à votre schéma de base de données, à vos algorithmes et à votre processus de développement logiciel et essayez de prédire les problèmes futurs. Vous souhaitez également configurer la surveillance des performances pour identifier les problèmes lorsqu'ils commencent à se développer.
J'ai pris ces conseils en lisant Création de sites Web évolutifs (lien vers Amazon).
J'espère que cela t'aides!
La seule façon dont les applications peuvent être vraiment évolutives, c'est de ne pas avoir de restrictions qui ne peuvent pas être passées (ou seulement très cher).
Un exemple typique est ce qui se passe lorsque vous manquez de cycles CPU disponibles? Si votre programme est à plusieurs voies, vous pouvez exécuter une boîte avec plusieurs cœurs, mais que se passe-t-il lorsque vous ne pouvez plus acheter une boîte plus grande? Votre application ne peut tout simplement plus grandir et n'est donc pas évolutive.
Toute application vraiment évolutive doit pouvoir se propager sur plusieurs ordinateurs de manière transparente et ce, sans heurts notables. Ce n'est pas facile et c'est l'une des raisons pour lesquelles Google a connu un tel succès.
Il existe des problèmes uniques liés à la prise en charge d'applications à grande échelle. L'offre d'emploi recherche des candidats qui ont travaillé dans cet environnement et ont dû résoudre de tels problèmes.
À partir d'une application de haut niveau, les applications sont rendues évolutives en posant constamment la question de savoir ce qui se passerait si ce morceau de code devait être exécuté des milliers de fois en très peu de temps. Cela signifie gérer vos empreintes mémoire, utiliser la mise en cache des totaux et des données, utiliser des sources de données elles-mêmes évolutives, etc.
Si vous construisiez une fonction de recherche qui fonctionnait bien lorsqu'elle contenait 100 lignes dans la base de données à rechercher et 10 utilisateurs l'utilisaient à la fois. Comment cela fonctionnerait-il lorsque 100 utilisateurs l'utilisaient en même temps et qu'il y avait 100 000 lignes à rechercher.
S'il fonctionne de la même façon, c'est très bien. si elle est proportionnelle à la quantité d'utilisateurs/de données (ce qui signifie 10 fois plus de données == 10 fois plus de temps à traiter), c'est bien. S'il fonctionne beaucoup plus bas, plus il dispose de données (données en mode 10x == 10x ^ 10 plus longues à traiter), alors il ne se met pas à l'échelle correctement.
Mes exemples devraient vraiment être montrés en notation Big O mais actuellement je ne les connais pas assez bien pour écrire les exemples en Big O.
Vous pouvez simuler plus de données en déversant des données factices dans votre base de données, et il existe des outils pour simuler plus d'utilisateurs tels qu'Apache AB.