Scalability & Optimisation

A tort ou à raison, la “scalabilité” d’une architecture est souvent associée aux performances de cette même architecture.

Par achitecture j’entends le design de l'application, la technologie et l’infrastructure utilisée.

En ce qui me concerne je définis la scalabilité comme l’aptitude à supporter un plus grand nombre d’utilisateurs avec des temps de réponses comparables. Bien sûr, on peut y voir un lien directe avec les performances mais pas uniquement.

Je défini les performances d’une application comme étant fonction du hardware utilisé (CPU, RAM, contrôleur disque), l’infrastructure (bande passante du réseau, configuration des routers, switch, …), optimisation du code.
Certes en utilisant au mieux nos ressources nous pourrons avoir des performances rapides, mais qui risqueront de décroître rapidement, si la charge (nombre de requête) augmente rapidement.

L’idée d’une architecture "scalable" ou extensible est de fournir une application qui aura des temps de réponses plus ou moins constants en fonction de la charge.

Une image que j’aime évoquer est celle de la formule 1 et du tracteur. Une formule 1 pourra atteindre de vitesse de pointe phénoménale, mais elle ne pourra plus rouler si vous lui attachez une charge trop conséquente. Le tracteur fonctionne à l’opposé, il ne roulera pas vite mais pourra tirer pratiquement n’importe quelle charge.

Pour « scaler » en général on utilise une infrastructure qui permet d’adjoindre de nouveaux serveurs en cas de besoin. Cette faculté doit être prévue par le design, la technologie et l’infrastructure de votre application.
D’aucun pourrait dire qu’adjoindre des serveurs est idiot puisqu’il suffit d’upgrader le matériel (mettre un meilleur cpu et plus de ram). D’une part les upgrade matériels ne sont pas infini, la motherboard ne peut pas accepter un nombre illimité de processeurs ou de barettes de RAM. D’autre part si un processus mange 100% de votre temps CPU sur le processeur, il pénalisera d’office le reste des utilisateurs. Sur des serveurs différents, ce problème est moins grave, un serveur bloqué ne bloquera pas forcément les autres.

La question à se poser lors du design est simple:
Que se passe-t-il si j’ajoute un nouveau serveur ?
Si le design initiale ne marche pas il faut tenter de déterminer pourquoi.

L’un des problèmes fondamentaux est la réplication des sessions utilisateurs d’un serveur vers un autre (concevoir une architecture statefull). Heureusement, il existe des techniques pour solutionner ce genre de problèmes.

Conclusion

Existe-t-il des meilleurs outils de développements (meilleures technologies) pour être scalable ou pas ?
Ma réponse serait non, car la scalabilité est avant tout un problème de design, si vous avez mal conçu votre architecture, quelque soit le langage utilisé, votre application ne pourra pas être étendue facilement.
D’un autre côté si la scalabilité n’est pas forcément liée à l’optimisation, ce n’est pas pour autant que l’on peut programmer n’importe comment sans rien n’optimiser. Si le but est de conserver un temps de réponse constant quelque soit le nombre d’utilisateurs, ce temps de réponse doit tout de même être acceptable !