Lorsque la charge serveur augmente, et qu’il est temps de rajouter des ressources matérielles à votre infrastructure, deux approches s’offrent à vous : augmenter vos ressources verticalement ou horizontalement. On parle de scaling vertical versus scaling horizontal.
La scalabilité verticale
La scalabilité verticale est la plus intuitive : cela revient à ajouter des ressources à un unique serveur (en lui ajoutant de la RAM, en changeant son CPU pour un plus véloce…). C’est simple ! Mais :
- Le coût est rapidement exponentiel de la capacité matérielle.
- Cette solution a des limites : vous pourrez probablement multiplier par 2 les capacités de votre serveur, peut-être même par 5, mais pas par 100 !
Cela reste dans la majorité des cas la solution la plus pragmatique, et en particulier pour des applicatifs en production depuis de nombreuses années.
La scalabilité horizontale
La scalabilité horizontale revient à ajouter de nouveaux serveurs réalisant le même type tâche. Cela permet de n’utiliser que des serveurs standards (on parle de commodity hardware). Mais les implications logicielles sont rapidement importantes !
- L’application doit être stateless (sans état) : cela signifie que les données sont stockées dans un autre service (dans votre base de données, dans un cache distribué…)
C’est l’idéal. Vous devriez concevoir vos nouveaux développement avec cet objectif. - Si votre applicatif stocke des données en local (par exemple des données de sessions utilisateurs stockée en RAM) : vous pouvez malgré tout scaler horizontalement s’il est possible de couper ces données en sous ensembles indépendants (on parle de sharding). Il est alors nécessaire de s’assurer que chaque client ne communique qu’avec un unique serveur. Cela passe par exemple par un proxy qui redirige le client vers un serveur applicatif donné en fonction des identifiants du client, on parle de sticky session.
- Si il n’est pas possible de sharder facilement vos données, alors vous ne pouvez pas scaler horizontalement sans modifier en profondeur votre applicatif. Vous devez, au moins temporairement, vous en tenir à un scaling vertical.
L’idéal, vous l’aurez compris, est ne pas avoir de données stockées en local sur vos instances, même si cela est rarement le cas sur un applicatif legacy. Car en plus de vous permettre de scaler horizontalement, vous pourrez :
- Avoir un meilleur SLA : en cas de défaillance matérielle sur l’une des instances, les autres instances pourront absorber la charge avec une interruption de service minimale pour l’utilisateur
- Cela nécessite évidemment de monitorer les serveurs pour décommissioner les instances défaillantes
- Il est aussi nécessaire que les serveurs sains soient capables de tenir la charge. On parle de dimensionnement “N+1”
- Mettre à jour votre applicatif sans interruption de service. En mettant à jour le serveur 1, puis le serveur 2,… Si vous devez mettre à jour le schéma de base de données, il sera alors nécessaire de vous assurer que chaque mise à jour est rétro-compatible.
Que dois-je faire ?
Tout dépend ! Quelques questions pour vous aiguiller dans votre réflexion :
- Quel est votre SLA cible ? Doit-il être supérieur à celui fourni par un seul serveur, dont la probabilité de défaillance dans l’année est de ~10% (source https://www.statista.com/statistics/430769/annual-failure-rates-of-servers/), et que vous répareriez manuellement en cas de défaillance matérielle, en quelques heures ?
- Si virtuellement aucune interruption de service n’est permise, vous n’avez pas d’autre choix que de scaler horizontalement.
- Mais la majorité des applications, par exemple intra entreprise, peuvent se satisfaire d’une interruption de service de quelques heures par an !
- Quel est la taille de votre problème de charge ? Vous manque-t-il 10% de ressources, ou prévoyez-vous dans le futur des pics de charges de 1000% ? La scalabilité verticale peut, selon votre contexte, être parfaitement suffisante ! Mais attention cependant à ne pas faire des choix qui empêcheront votre entreprise de changer son business model ou se développer à l’international. Votre SI reste la colonne vertébrale de votre entreprise.
- Quoiqu’il en soit, refactorer un applicatif qui n’est pas pensé pour scaler horizontalement peut se révéler onéreux voire irréaliste. Ainsi vos nouveaux développements doivent être réalisés en pensant scalabilité horizontale.
Note : Le sharding revient à éclater une base de données en plusieurs bases de données, de structure identique. Le choix de la base à utiliser se fait en fonction d’un critère à définir. Un organiseur est un bon exemple de sharding : on divise une base en sous bases, le choix de la base se faisant par critère alphabétique.
