Qu'est-ce qui rend une application évolutive?

Je continue de voir dans les offres d'emploi que le candidat doit avoir une expérience de la rédaction d'applications "évolutives". Qu'est-ce qui rend une application évolutive et comment puis-je savoir que mon code peut être étendu à des millions d'utilisateurs?

J'imagine qu'une meilleure façon de formuler cette question est la suivante: comment puis-je écrire mon code avec une évolutivité en tête? Pour que le code soit évolutif dès le départ, par opposition à une réflexion ultérieure. Existe-t-il certaines méthodologies de conception? Ou est-ce simplement une question de choisir les bons algorithmes pour le travail?

Il y a deux directions d'évolutivité:

• vertical (aka scaling up): processeur plus rapide, plus de RAM, plus d'espace disque;
• horizontal (aka scaling out): plus de cœurs dans le processeur, plus de processeurs, plus de serveurs;

Pour le premier, il suffit de veiller à 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'utiliser plus de threads ou de processus, vous atteindrez éventuellement les limites du système d'exploitation. C'est pourquoi les serveurs actuellement construits pour une évolutivité élevée pratiquent la concurrence sur la base d'événements asynchrones. Ce problème est décrit dans le célèbre document C10K .

La seconde est plus difficile. Cela nécessite une programmation avec deux éléments à 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 devrait être limitée. Dans la pratique, cela signifie généralement de sacrifier certaines parties d’ACID (il est prouvé que vous ne pouvez pas disposer d’ACID complet et avoir la capacité de passer de l’un à l’autre). La solution la plus connue pour le stockage de données dans ce paradigme sont les solutions NoSQL . Ils vont de très simples magasins de clé-valeur, à des systèmes de type SGBDR, dépourvus de la possibilité de faire des jointures. Les magasins de clés-valeur sont ultra-évolutifs, mais cela vient comme un prix. Vous pouvez en principe interroger uniquement sur la clé primaire. Il y a cependant une solution à cela, c'est la carte réduire. Cela peut sembler très sous-optimal si vous examinez le point de vue de la complexité cumulative, mais vous devez garder à l’esprit que cela fonctionne massivement parallèlement.

Si vous souhaitez en savoir plus sur l'évolutivité avec des exemples concrets, consultez le blog de HighScalability.com .

L'évolutivité est mesurée en termes de débit basé sur une variable. Par exemple, nombre de demandes / seconde avec X utilisateurs. La manière la plus simple de décrire l'évolutivité est la suivante:

Une mesure de l' efficacité lorsque la charge augmente.

La première chose que vous devez comprendre lors de la conception de l’évolutivité est la mesure la plus importante pour votre application. Il existe plusieurs façons de mesurer l’ efficacité, é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

Il existe davantage de mesures d'efficacité pouvant être utilisées, mais elles sont communes aux systèmes Web ou aux systèmes de traitement par lots.

Le prochain aspect de l’évolutivité consiste à mesurer l’évolution de votre efficacité lorsque la charge augmente. Les moyens courants d'augmenter la charge sont les suivants:

• Plus d'utilisateurs accédant au serveur (c.-à-d. Plus de trafic Web)
• Plus de données dans la base de données (les requêtes prennent plus de temps ou le traitement prend plus de temps)
• Panne de disque dur dans un RAID (performances / fiabilité du stockage affectées)
• Saturation du réseau

L'objectif d'une application évolutive est de maintenir ou d'améliorer l'efficacité lorsque nous traitons le problème de charge. En bref, si le temps de réponse est trop long, pouvons-nous ajouter un autre serveur pour répartir la charge de manière égale? Cette approche réduit la charge de travail d'un serveur et permet aux serveurs de fonctionner dans cette "zone idéale" d'efficacité.

Votre application devra être conçue spécifiquement pour être à l'échelle. Cela signifie que vous devez être prudent avec les données de session, en acheminant les demandes au bon serveur, en réduisant les goulots d'étranglement qui limitent la capacité de l'application à évoluer.

Vous voulez essentiellement éviter les goulots d'étranglement lorsque vous augmentez le nombre d'utilisateurs et / ou que vous traitez un jeu de données plus volumineux, et / ou que vous proposez votre interface dans plusieurs langues, etc.

Essentiellement, vous examinez votre schéma de base de données, vos algorithmes et votre processus de développement logiciel pour tenter de prévoir 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 lu ces conseils lorsque j'ai lu la création de sites Web évolutifs (lien vers amazon).

J'espère que cela t'aides!

La seule façon pour les applications d'être réellement évolutives 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 de traitement disponibles. Si votre programme est multi-crénelé, vous pouvez utiliser une boîte à 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 se développer et n'est donc pas évolutive.

Toute application véritablement évolutive doit être capable de s'étendre de manière transparente sur plusieurs ordinateurs, sans aucun décalage notable. Ce n’est pas facile et c’est l’une des raisons du succès de Google.

Il existe des problèmes uniques liés à la prise en charge d'applications de grande taille. L'offre d'emploi recherche des candidats qui ont travaillé dans cet environnement et qui ont dû résoudre de tels problèmes.

Depuis une application de haut niveau, les applications sont évolutives en se posant constamment la question de savoir ce qui se passerait si cet élément de code devait être exécuté des milliers de fois sur une très courte période. Cela signifie gérer vos empreintes de mémoire, utiliser la mise en cache des totaux et des données, utiliser des sources de données évolutives, etc.

Si vous construisiez une fonction de recherche qui fonctionnait bien quand il y avait 100 lignes dans la base de données pour la recherche et que 10 utilisateurs l'utilisaient à la fois. Quelle serait sa performance lorsque 100 utilisateurs l'utilisaient en même temps et qu'il y avait 100 000 lignes à rechercher.

Si la performance est la même, peu importe ce qui se passe, alors c'est très bon. il fonctionne si proportionnellement à la quantité d’utilisateurs / données (ce qui signifie 10 fois plus de données == 10 fois plus long à traiter) que c’est bien. Si le nombre de données à traiter est beaucoup plus faible (traitement du mode 10x == 10x ^ 10 plus long), la mise à l’échelle est mauvaise.

Mes exemples doivent vraiment figurer en notation Big O, mais je ne les connais pas assez bien pour écrire les exemples en Big O.

Vous pouvez simuler plus de données en vidant des données factices dans votre base de données. Il existe des outils pour simuler plus d'utilisateurs tels qu'Apache AB.