Scalabilité

La scalabilité désigne la capacité d'un système à absorber une augmentation de charge sans s'écrouler ni coûter disproportionnellement cher. Un site scalable sert aussi bien cent visiteurs que cent mille, moyennant des ressources supplémentaires proportionnées.

Ce n'est pas la même chose que la performance. Un site peut être très rapide avec dix utilisateurs et devenir inutilisable à mille : il est performant mais pas scalable.

Scalabilité verticale et horizontale

La scalabilité verticale consiste à renforcer la machine existante : plus de processeurs, plus de mémoire, un disque plus rapide. C'est simple à mettre en œuvre, sans modification du code, mais on atteint vite un plafond physique et le prix grimpe rapidement.

La scalabilité horizontale consiste à ajouter des machines et répartir la charge entre elles. Il n'y a théoriquement pas de limite, et le coût suit l'usage. En contrepartie, l'application doit avoir été conçue pour tourner en plusieurs exemplaires simultanément, ce qui ne s'improvise pas après coup.

Ce qui empêche un système d'être scalable

• L'état stocke en mémoire. Si une session utilisateur vit dans la mémoire d'un serveur précis, ajouter un second serveur casse l'expérience. L'état doit être externalisé, en base ou dans un cache partagé.
• La base de données. C'est le goulot d'étranglement le plus fréquent. Multiplier les serveurs applicatifs ne sert à rien si tous interrogent la même base saturée.
• Les traitements synchrones. Générer un PDF ou envoyer un email pendant que l'utilisateur attend bloque une ressource. Ces tâches doivent partir dans une file d'attente.
• Les fichiers locaux. Un document téléversé sur un serveur devient invisible depuis les autres. Le stockage doit être externalisé.

Comment on l'obtient en pratique

• Mettre en cache ce qui est lu souvent et modifié rarement, au niveau du navigateur, du CDN et du serveur.
• Externaliser les sessions et les fichiers vers des services partagés.
• Sortir les traitements longs de la requête utilisateur, via des files de messages.
• Indexer correctement la base et surveiller les requêtes lentes, souvent la cause réelle d'un ralentissement.
• Mesurer avant d'optimiser : la scalabilité se prouve par un test de charge, pas par une intuition d'architecture.

Faut-il concevoir scalable des le départ

Rarement, et c'est un arbitrage souvent mal compris. Construire une architecture distribuée pour un service qui aura trois cents utilisateurs coûte cher en temps de développement et en complexité de maintenance, pour un bénéfice nul.

L'approche raisonnable consiste à éviter les choix qui bloquent la montée en charge, sans pour autant construire l'infrastructure d'un geant. Externaliser les sessions et les fichiers des le départ ne coûte presque rien et évite une refonte douloureuse le jour où la croissance arrive.