Orchestration de serveurs de jeu
L'orchestration de serveurs de jeu est l'allocation, la mise à l'échelle et la désactivation automatisées d'instances de serveurs de jeu à mesure que les matchs commencent et se terminent. Elle décide où chaque serveur s'exécute, le démarre, transmet son adresse aux joueurs et le récupère une fois le match terminé. Effectuer cela manuellement cesse d'être pratique dès lors qu'un jeu gère plus d'une poignée de matchs simultanément.
Aussi appelé
orchestration
,
Que fait l'orchestration de serveurs de jeu pour un match ?
La plupart des studios arrivent ici avec une question plus simple : comment héberger les serveurs de mon jeu ? L'orchestration répond à la partie qui se répète, une fois par match, plusieurs fois par jour.
Un serveur est demandé. Lorsque les joueurs sont prêts à jouer, votre backend appelle l'API de l'orchestrateur pour obtenir un serveur. L'origine de l'appel importe peu : un matchmaker, un lobby ou votre propre service. Si un serveur approprié est déjà en cours d'exécution, les joueurs peuvent le rejoindre à la place.
Un emplacement est choisi. L'orchestrateur décide de l'endroit où le serveur s'exécute, en fonction de ce qu'il sait des joueurs et de la capacité disponible.
Un serveur démarre. Il lance un conteneur à partir de l'image de serveur du jeu, généralement une version headless du serveur dédié.
Les joueurs reçoivent l'adresse. L'orchestrateur renvoie une adresse IP et un port, et votre backend les transmet aux joueurs.
Le match se termine, le serveur s'arrête. Sa capacité est libérée pour le match suivant.
Répétées pour chaque match, ces étapes constituent la tâche pour laquelle l'orchestration existe : s'adapter à la demande des joueurs. Elle ajoute des serveurs au fur et à mesure que les joueurs arrivent et les supprime lorsqu'ils partent, aussi bien au sein d'un même emplacement que sur plusieurs. Ainsi, chaque match requis par le jeu d'un studio dispose d'un serveur, idéalement à un emplacement où le match se déroule de manière fluide en ligne. En termes d'infrastructure, il s'agit d'une mise à l'échelle horizontale (ajouter d'autres serveurs de même taille) plutôt que d'une mise à l'échelle verticale (attribuer une machine plus puissante à un seul serveur). Les serveurs de jeu évoluent rarement verticalement : les besoins d'un match sont fixés par sa version, la capacité augmente donc en ajoutant des serveurs.
Deux décisions déterminent la façon dont un orchestrateur procède : les endroits où les serveurs sont autorisés à s'exécuter, et la manière dont cette capacité est payée.
Où les serveurs doivent-ils fonctionner et comment la capacité est-elle payée ?
Où : hubs régionaux ou à proximité de chaque match. De nombreux jeux exécutent des serveurs dans quelques grandes régions de serveurs, et les joueurs sont envoyés vers la plus proche. C'est rentable pour le studio : la capacité est concentrée, facile à exploiter, et chaque région dispose d'un large bassin de joueurs à associer. Le coût retombe sur les joueurs les plus éloignés d'un hub, qui jouent chaque match avec une distance supplémentaire. L'alternative consiste à choisir un emplacement pour chaque match parmi de nombreux autres plus petits, en fonction de l'endroit où se trouvent les joueurs de ce match. Cela réduit la distance pour un plus grand nombre de joueurs et réduit l'écart entre les joueurs d'un même match, ce qui permet de maintenir un niveau de jeu équitable. C'est aussi important dans un match amical que dans un match compétitif : un match qui semble équitable est généralement un match que les joueurs apprécient davantage. Cela en demande également plus à l'orchestrateur, qui doit faire ce choix en temps réel.
Comment : capacité fixe ou cloud.
La capacité fixe correspond à du bare metal ou à des hôtes réservés, loués au mois. Elle coûte moins cher de l'heure lorsqu'elle est occupée, inclut souvent le trafic sortant et convient aux charges qui ne baissent jamais : les mondes persistants ou la base de matches exécutés à chaque heure. La demande des joueurs est pourtant rarement stable. Elle culmine généralement de la fin d'après-midi jusqu'en soirée, heure locale, et diminue pendant la nuit, de sorte qu'un hôte dimensionné pour le pic fonctionne en partie vide le reste de la journée. Vous payez pour celui-ci pendant qu'il reste inactif, et il n'existe que dans les emplacements que vous avez loués. Cela fait de la capacité fixe une décision de retour sur investissement : combien d'heures par jour elle est suffisamment occupée pour coûter moins cher que le paiement à l'utilisation.
La capacité cloud est démarrée à la demande et facturée pendant son exécution, soit en tant que votre propre parc cloud, soit en tant que capacité multi-locataire partagée avec d'autres studios. Le partage répartit le coût de nombreux emplacements sur de nombreux jeux, de sorte que chacun d'eux peut atteindre plus d'endroits qu'il n'en louerait seul.
Pourquoi la plupart des jeux finissent-ils par devenir hybrides ?
Parce que la plupart des jeux connaissent ces deux types de charge. Un jeu basé sur des matchs maintient une base constante de parties à toute heure, avec des pics d'activité par-dessus : en soirée, le week-end, lors d'un lancement ou d'une mise à jour de contenu. Une capacité fixe est la solution la plus économique pour gérer cette base. La capacité cloud peut quant à elle absorber les pics et atteindre les joueurs éloignés des serveurs fixes. Exécuter ces deux types de ressources sous un orchestrateur unique correspond à une orchestration hybride, et la répartition idéale varie pour chaque jeu.
Les cas extrêmes se situent aux deux opposés. Fortnite fonctionne « presque entièrement » sur AWS, y compris son parc de serveurs de jeu (DatacenterDynamics, février 2023). Les MMO persistants penchent vers l'autre extrême, car un univers qui ne s'arrête jamais est la définition même d'une charge qui ne baisse jamais : The Isle fonctionne sur la Private Fleet d'Edgegap, tout comme Path of Titans.
Sur Edgegap, les deux options sont la Private Fleet, avec 58 emplacements, et Edge Cloud, avec plus de 615 emplacements répartis sur plus de 17 fournisseurs, le tout géré par un orchestrateur unique (données de la plateforme, 18 septembre 2026). Pour savoir où situer la limite entre capacité fixe et cloud selon votre niveau de simultanéité, faites une simulation dans le calculateur de tarifs.
Qu'est-ce qui détermine le bon modèle pour votre jeu ?
Le serveur de jeu, plus qu'un simple orchestrateur. Pour la plupart des jeux, la réponse réside dans un équilibre entre rentabilité et expérience joueur, et quatre propriétés du serveur déterminent où se situe cet équilibre :
Durée de la session. Les matchs qui se terminent peuvent passer d'un emplacement et d'un type de capacité à un autre librement. Un monde persistant a besoin d'un hébergement qui reste actif.
Ressources par match. Le CPU et la mémoire par match, mesurés dans une build profilée, déterminent le nombre de matchs possibles sur un hôte, et donc la valeur d'un hôte fixe. Voir vCPU.
Joueurs par serveur. Un match en 1v1 est positionné pour deux personnes ; un lobby de 100 joueurs est positionné pour une foule répartie sur une carte.
Matchs par processus. Un serveur multi-salles regroupe de nombreux matchs dans un seul processus, ce qui modifie l'unité de mesure que vous dimensionnez et payez.
Partez de là, puis choisissez les briques de base : conteneurs et images de serveur pour le packaging, auto-scaling et pools chauds pour la capacité, gestion de flotte pour les hôtes fixes. La question de savoir si vous devez construire cela vous-même est traitée dans l'hébergement de serveurs de jeu.
Ces propriétés évoluent à mesure qu'un jeu grandit, se lance dans de nouvelles régions ou ajoute un mode persistant. L'orchestrateur doit donc permettre au mix d'évoluer avec elles, sans dépendance exclusive : conteneurs standards, capacités fixes et cloud côte à côte, et cloud facturé à la minute. Edgegap est conçu ainsi.
Un mot de notre sponsor (nous-mêmes !)
La plupart des studios atteignent leur limite de mise à l'échelle lors du lancement, face aux joueurs. Edgegap a atteint 14 millions de sessions simultanées lors d'un test de référence d'une heure sur de réels conteneurs de serveurs de jeu. Ainsi, la limite que vous devez anticiper est celle de votre jeu, pas celle de votre hébergeur.
Place pour le joueur, puis fixez le prix
Les hubs régionaux sont un moyen rentable de faire fonctionner des serveurs. Les joueurs éloignés de ces derniers en paient la différence en termes de latence, à chaque match.
Nous avons mesuré ce que vaut le placement. Dans une rediffusion du trafic en direct d'un éditeur de jeux AAA, le déploiement du serveur dédié de chaque session à l'emplacement le mieux adapté à ses joueurs a réduit le temps d'aller-retour moyen de 58 %, passant de 116 ms à 49 ms, et a permis de placer 78 % des joueurs sous la barre des 50 ms, contre 14 % sur la configuration cloud public de l'éditeur (étude de cas, 2019). Les joueurs le remarquent. Dans une enquête menée en 2022 auprès de 2 000 joueurs aux États-Unis et au Royaume-Uni, 1 joueur sur 3 a déclaré arrêter de jouer lorsque la latence se fait sentir, et 42 % ont affirmé qu'ils joueraient davantage sans elle (rapport sur la connectivité, juillet 2022).
Nous partons donc du joueur : placer chaque match là où se trouvent ses joueurs, puis rendre cela rentable grâce à un mix, une base de référence fixe avec le cloud pour tout ce qui dépasse. C'est ainsi qu'Edgegap a orchestré 135 millions de déploiements de serveurs de jeux depuis février 2019 (données de la plateforme, 18 septembre 2026).
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
Est-ce que l'orchestration de serveurs de jeu fonctionne avec Unity, Unreal et Godot ?
Oui. Un orchestrateur exécute une image de conteneur, de sorte qu'il ne dépend pas du moteur qui a construit le serveur. Le moteur importe à deux niveaux : pour la construction d'un serveur Linux pour l'image, et pour une petite intégration afin que le serveur puisse lire ses données de match et signaler quand il est prêt ou a terminé. Les serveurs Unity, Unreal et Godot s'adaptent tous à ce schéma, tout comme les serveurs écrits sans moteur, tels qu'un serveur Node.js pour un jeu en ligne.
,
