Scalabilité Horizontale Vs Scalabilité Verticale : un peu d'éclaircissement

Suite ce post du blog sur le thème : "Comment developper un backend pour supporter des milliers voir des millions d'utilisateur?" qui a été beaucoup lu et donc beaucoup de gens ont posé des questions de toute sorte dans tous mes canaux sociaux, notre ami Yvannol Fotso pose la question suivante:

<<Merci j'ai un soucis pourquoi vraiment faire du DPR sur une requête peut être comme consulter son profil de Facebook (l'exemple que vous avez pris) pourrait réduire la lourdeur de la requête Http ? 😀😀Donc la scalabilité horizontal repose l'augmentation des composants mémoire vive ... La création des instances serveur ici(S. Vertical) se fait comme en systèmes d'exploitation /programmation repose sur quoi ici les threads? Ou les fork ?>>

avant de répondre en profondeur sur cette question, j'aimerai revenir sur la definition de scalabilité verticale et horizontale car il faut un peu bien d'éclaircissement:

Scalabilité veriticale :

c'est la technique qui permet d'augmenter les resources de la machine ou est exécuté une application, par resources on entend par là, la RAM, le disque dure, le processeur/CPU etc..oui mes amis si vous voulez par exemple executer plusieurs applications à la fois dans votre machine windows qui n'a que 4GB de RAM ou bien vous constatez simplement que votre machine devient lente quand vous ouvrez contemporainement android studio, visual studio, visual studio code, microsoft word ou excell etc.. alors si votre machine peut supporter plus de 4GB, la permière des idées qui vous viendra à l'esprit ce serait d'aller acheter 4GB supplementaires et de l'installer dans votre machine pour esperer le voir executer plus rapidement toutes ces applications, de meme si votre machine peut supporter plusieurs CPU, vous serez tenté à en faire de meme, c'est ça la scalabilité verticale, dans le monde des machines virtuelle et des technologies basées sur les containeur comme docker, c'est facile d'ajouter dynamiquement en runtime c'est là dire à la volée la RAM ou la CPU ou meme le disque dure d'une machine virtuelle ou d'un conteneur docker, c'est ça l'avantage du cloud computing et c'est pourquoi dans le cloud, on vous facture en fonction des resources que vous utilisez et generalement il n'y a pas un taux fixe par mois.

Scalabilité Horizontale :

A la difference de la scalabilté verticale ou on multiplie les resources, ici la technique utilisée est de multiplier plutot le nombre de machine par exemple au lieu d'aller acheter des RAM ou CPU comme dans la scalabilité verticale, on peut bien decider d'aller acheter plutot une nouvelle machine et faire certaine tache dans cette machine et d'autres dans la vieille machine, dans le monde du cloud computing ou toutes les machines ne sont pas physique mais virtuelle, il s'agit simplement de creer plusieurs instances d'une machine virtuelle pour gerer la meme application, c'est à dire que si on a une application beaucoup solicité par les utilisateurs, on peut faire en sorte que quand il y a plusieurs utilisateurs en contemporain au meme moment qui sollicitent l'application, on crée des nouvelles machines virtuelles et on repartit les requetes des utilisateurs vers ces differentes machines, c'est un peu ce qu'on appelle le Load Balancing et les technologies a conteneur comme docker/kubernetes gère cela de manière simple et automatique, tout depend de comment est projecté l'application.

Une application web est fait pour gerer les requetes des utilisateurs qui sont essentiellement des requetes HTTP à travers leur navigateur, attention ouvrir une page web ne signifit pas qu'on fait une seule requete, mais plusieurs requetes en sous taches automatiquement car géneralement une page web, non seulement est fait des fichiers css, javascript et de la page HTML, mais peut aussi avoir des images, des video etc.. du coup pour chacune de ses resources, le navigateur fait d'autres requetes HTTP au serveur pour telecharger ces resources et associer à la page web, du coup, le simple fait d'ouvrir votre page facebook par exemple, ce n'est pas juste une seule requetes qui est fait au serveur mais des dizianes voir des centaines de requetes, juste pour vous seul et il y est de forte chance que au meme moment que vous etes entrain d'ouvrir votre page facebook, vous ayez des milliers voir des millions d'autres utilisateurs qui sont entrain de faire exactement la meme chose, du coup si facebook a un et un seul serveur alors ce serveur sera hyper sollicité et à un certain moment, la machine va planter car les resources du serveur (RAM, CPU, etc..) ne sont pas illimitées, generalemement les serveur web fonctionne avec ce qu'on appelle des thread, bref ce sont generalement des applications multi-thread, donc chaque requetes est un thread que le serveur ouvre et un thread signifit demande de RAM et CPU au systhème d'exploitation, donc le serveur à un moment n'aura plus de resource pour les requetes et du coup la app va planter et sera innaccessible.

Dans le cas de la projectation d'une application web backend, il faut donc opter pour une architecture qui permet le moment venu de pouvoir automatiquement rendre scalable l'application c'est à dire, l'application doit etre coder de telle sorte que si l'application a tel nombre d'utilisateur, alors on peut soit immediatement proceder et de manière automatique au redimensionnement du serveur à savoir appliquer une scalabilité verticale, par exemple on peut avoir une configuration qui dit : si les requetes de facebook atteignent 100 au meme moment alors augemente la RAM de 5GB et double la CPU, dans le cas ou on atteind 1000 requetes en meme temps, alors on double plutot les machines virtuelles de manière à pouvoir redistribuer les requetes dans ces differentes machines, ceci doit etre fait de manière automatique et pas manuelle.

Quand on parle de multiplier les instances d'une machine, cela veut dire que la meme application backend, la meme copie doit etre capable d'etre multiplier et surtout on doit projecter l'application backend de manière à identifier les parties critiques qui sont le plus sollicitées et ce sont ces parties qui doivent etre multipliées dans plusieurs machines, par exemple sur facebook, ce n'est pas chaque feature/fonctionalités qui est beaucoup sollicité en meme temps, le  service qui gère par exemple les données de votre profile facebook est certainement moins sollicité que le service qui doit gerer votre file d'actualité qui est plus sollicité, du coup l'application doit etre bien divisée de manière que ces deux services puissent fonctionner de manière autonome, ainsi, on pourra en cas de millier de requetes, rendre scalable seulement le service qui est plus sollicité pour eviter de multiplier les instances d'une machines avec un service qui n'est pas sollicité, voila pourquoi on opte pour des architectures dite à microservice et non des applications monolithiques ou on melange tout dans la meme application et on ne divise pas en microfonctionnalité, quand vous avez une application à microservice, il devient facile de le rendre scalable, du moins les feature/fonctionalités qui sont plus sollicité , car multiplier des instances de la machines,coute eccessivement en le terme du cloud computing.

Happy Coding

---

---

Share

Comments (1)

Leave A Comment

Your Name:
Comment: