Quand un serveur de jeu commence à grandir, la première décision concrète concerne généralement votre stratégie de scalabilité serveur : agrandir la même machine (vertical) ou répartir la charge sur plusieurs machines (horizontal) ? Les deux voies sont valables, mais celle qui vous convient dépend de l'architecture de votre jeu, du nombre de joueurs et de l'endroit où se situe réellement le goulot d'étranglement. Cet article compare les deux approches de façon concrète et technique.
Scalabilité verticale : une machine plus puissante
La scalabilité verticale (scale up) consiste à ajouter des cœurs CPU, de la RAM ou des disques plus rapides à votre serveur existant. Son plus grand avantage est la simplicité : rien ne change dans votre code et vous évitez la complexité des systèmes distribués. Un seul process, une seule base de données, un seul état du monde de jeu gardé en mémoire — comme tout est au même endroit, la latence reste basse.
Les architectures MMO classiques comme Metin2 ou Tibia en sont de bons exemples : l'essentiel de la logique de jeu tourne dans un seul game process, en mémoire partagée. Dans un tel système, passer de 200 à 800 joueurs se résout souvent avec un CPU plus rapide et plus de RAM. Chez les fournisseurs cloud, cela peut être aussi simple que de redimensionner une instance vers un palier supérieur en quelques minutes.
Mais la scalabilité verticale a un plafond strict :
- Limite physique : même la plus grosse machine finit par manquer de cœurs à ajouter.
- Point de défaillance unique : si cette machine tombe, tout le jeu tombe. Aucune redondance.
- Coût non linéaire : le matériel haut de gamme devient démesurément cher par cœur.
- Goulot mono-cœur : si votre boucle de jeu tourne sur un seul thread, même une machine à 32 cœurs est limitée par la vitesse de ce thread.
Scalabilité horizontale : plus de machines
La scalabilité horizontale (scale out) consiste à répartir la charge sur plusieurs serveurs. Dans les jeux, cela revient rarement à « découper le même monde sur deux machines », car partager l'état du jeu est difficile. En pratique, la scalabilité horizontale arrive plutôt sous l'un de ces motifs :
- Sharding : chaque machine héberge un monde/realm/salle distinct. Les joueurs sont répartis entre les shards et n'interagissent pas directement de l'un à l'autre.
- Décomposition en services : des parties comme l'authentification, le chat, le matchmaking et les paiements deviennent des services séparés qui scalent indépendamment.
- Serveurs par partie : dans les jeux de type FPS/MOBA, chaque match tourne sur une instance éphémère ; un orchestrateur remplit les serveurs vides.
La force de l'approche horizontale est l'élasticité : on ajoute des machines quand la charge monte, on les retire quand elle baisse. La panne d'une machine n'entraîne pas tout le système. En contrepartie, être distribué a un coût : partage d'état, communication inter-services, cohérence et complexité de déploiement.
La vraie question : où est le goulot d'étranglement ?
Prenez la décision de scalabilité par la mesure, pas par instinct. Trouvez d'abord le vrai goulot. Pour un aperçu rapide sous Linux :
# Charge globale et CPU par cœur
htop
# Chaque cœur individuellement (pour repérer un goulot mono-thread)
mpstat -P ALL 1
# Pression d'E/S disque
iostat -x 1
# Nombre et états des connexions réseau
ss -sCes sorties montrent la direction. Si un cœur est bloqué à 100 % alors que les autres sont au repos, le problème est une boucle de jeu qui ne se parallélise pas ; ajouter des machines n'y changera rien — il faut un CPU plus rapide ou une séparation des threads dans le code. Si tous les cœurs sont pleins, la scalabilité verticale aide un temps. Si le goulot est la base de données, ni la scalabilité horizontale ni la verticale de l'application ne suffisent ; corrigez d'abord les requêtes et les index.
Le plus souvent, la bonne réponse : vertical d'abord, puis décomposer
Un parcours de croissance réaliste ressemble à ceci. Commencez avec une seule machine bien configurée et scalez verticalement ; c'est la voie la moins chère et la plus rapide. En parallèle, faites le pas horizontal le plus simple : déplacez la base de données sur sa propre machine. Séparer le game process de MySQL apporte souvent à lui seul un grand soulagement, car les deux ne se disputent plus le même CPU et le même disque.
L'étape suivante est de détacher les parties sans état : chat, API web, matchmaking. Elles scalent horizontalement sans peine derrière un répartiteur de charge (comme nginx ou HAProxy). Découpez le monde de jeu réel le plus tard possible ; le sharding est généralement la partie la plus difficile et ne doit être fait que lorsque c'est vraiment nécessaire.
# Répartition de services API sans état avec nginx
upstream game_api {
least_conn;
server 10.0.0.11:8080;
server 10.0.0.12:8080;
server 10.0.0.13:8080;
}
server {
listen 80;
location /api/ {
proxy_pass http://game_api;
}
}Différence de coût et d'exploitation
La scalabilité verticale est peu coûteuse à exploiter : une machine à gérer, un flux de logs, un déploiement. Mais une fois la limite matérielle atteinte, le coût explose et la flexibilité disparaît. La scalabilité horizontale peut être plus efficace par unité de matériel, mais elle ajoute un coût d'équipe : supervision, découverte de services, logs distribués, déploiements plus complexes. Pour un petit projet, scaler horizontalement trop tôt relève souvent de la sur-ingénierie.
- Peu de joueurs, un monde : scalez verticalement, sortez la base de données.
- Beaucoup de realms/salles : croissez horizontalement avec un sharding par realm.
- Jeu par partie : un pool de serveurs dynamique piloté par un orchestrateur.
- Goulot mono-thread : profilez d'abord le code ; le matériel n'y peut rien.
Questions fréquentes
Par quoi commencer, l'horizontal ou le vertical ?
Presque toujours le vertical. Passer à une machine plus grosse prend quelques minutes et le code ne change pas. Ne recourez à l'horizontal que lorsque vous approchez du plafond matériel ou que la redondance est réellement critique.
Puis-je répartir un seul monde de jeu sur deux machines ?
En général non, ou du moins pas facilement. Partager le même monde exige de garder l'état cohérent entre les machines, ce qui est très difficile. Préférez des mondes séparés (shards) ou la décomposition en services.
La scalabilité corrige-t-elle un goulot de base de données ?
Corrigez d'abord les requêtes et les index. Une requête lente n'accélère pas en ajoutant des machines. Une fois les index corrects, des étapes comme des répliques de lecture ou un serveur de base dédié prennent tout leur sens.
Si vous voulez diagnostiquer correctement le goulot avant d'agrandir votre serveur, je peux examiner avec vous l'architecture de votre jeu et définir la voie de scalabilité la mieux adaptée. Contactez-moi et parlons de votre projet.