Scalabilité ? Quesako ?!

scalabilité /ska.la.bi.li.te/ féminin.

(Anglicisme) (Informatique) Capacité d’un système, ou de ses composants, à être utilisé sur des plates-formes de tailles très inférieures ou très supérieures, ou avec des volumes ou flux de données très inférieurs ou supérieurs. Il s’agit d’une extension du concept de portabilité.

Synonyme : extensibilité

Qu'est-ce que la scalabilité ?

C'est l'aptitude de l'infrastructure informatique que vous avez mis en place à monter en charge, à être la plus optimisée possible pour un usage donné, à fournir à un instant t les meilleurs temps de réponse possibles, pour des objectifs de fréquentation prévus (ET imprévus), et à être extensible, rapidement et à peu de frais, s'il y a besoin d'en augmenter les performances.

Prenons un exemple classique :

vous avez à héberger un site dynamique, développé à partir d'un framework PHP plutôt complexe et modulaire, et donc lourd.

Le budget du projet est serré, personne ne sait vraiment si le projet aura du succès.

En conséquence de quoi, il a été prévu un serveur dédié au projet, pas plus, pas moins.

Vous vous apercevez très vite que les temps de réponse du site sont lents, qu'il faut plusieurs secondes pour générer une page.

Les développeurs qui ont mis au point le site ne s'en sont pas aperçu, parce qu'en phase de développement, c'est une situation tout à fait habituelle.

Pour autant, le site ne peut être mis en production, car les conditions d'exploitation seront très différentes des conditions de développement :

un développeur travaille tout seul sur son site, il y a donc peu de chances pour qu'il "plante" son ordinateur.

Par contre, lorsque le site entrera en production, il y aura (espérons-le) des dizaines voire des centaines de visiteurs simultanés (à ce propos, avez-vous pensé à demander les objectifs de fréquentation au marketing ?!)

Bref, il y a de fortes chances pour que le jour J, votre travail (ainsi que celui de toute l'équipe projet) vire au cauchemar ...

Le site sature votre infrastructure, impactant potentiellement d'autres clients, les chefs de projet s'arrachent les cheveux, le client vous hurle dessus, parce que le site web "ne marche pas", alors qu'il a déjà dépensé 80000€ de budget publicité pour la semaine de lancement, ce qui va d'autant plus augmenter la fréquentation, donc la charge.

Un exemple récent : le lancement initial du portail www.france.fr

Les conséquences : manque à gagner, dégradation de l'image de marque, voire bad buzz ...

Bref, comment faire en sorte que le site que vous avez à héberger tolère cette affluence ?

Lorsque j'ai débuté dans le métier, j'ai rapidement trouvé quelques astuces :

- vérifier qu'il y a un cache applicatif, et qu'il a bien été activé

- mettre en place un cache au niveau du moteur php (ce que l'on appelle les accélérateurs)

En désespoir de cause, il y a la solution de Papi, à savoir mettre la base de données sur un nouveau serveur, ce qui permet de soulager le serveur web.

Mais est-ce efficace pour autant ? Ok, on vient de doubler le budget serveurs du projet, mais a t-on doublé les performances du site ? D'expérience, c'est non !

Sur la plupart des sites dynamiques, c'est plutôt le serveur web qui fait goulet d'étranglement. En déportant la base de données, nous gagnons 25 à 50% de performances, pour un coût supplémentaire de 100%.

Ce qui n'est pas efficace, ni d'un point de vue performances (cela vous permettra de "souffler" un peu, mais cela ne fera que retarder le prochain plantage), ni d'un point de vue financier.

La scalabilité consiste donc à bâtir une infrastructure suffisamment performante pour absorber les pics de trafic, qui est déjà (ou peut être mise facilement) en partage de charge (load balancing en anglais), avec plusieurs serveurs web et SQL, et avec un certain nombre de services spécialisés mais très performants, qui permettront de soulager l'applicatif (par exemple Varnish, qui est un reverse proxy faisant office de cache d'éléments statiques voire de pages, ou encore Memcached, qui est un conteneur RAM accessible en réseau)