Déploiement
Un déploiement est une instance d'exécution unique d'un build de serveur de jeu, créée pour héberger un match et détruite à la fin de celui-ci. Il possède une adresse, une durée de vie mesurée en minutes et une capacité définie. Le décompte des déploiements plutôt que des machines est la méthode de mesure et de facturation de l'hébergement basé sur des sessions.
Aussi appelé
déploiement de serveurs de jeu, déploiement de serveurs
,
Que contient un déploiement de serveur de jeu ?
Un déploiement est le point de rencontre entre un build et une partie. Quel que soit l'élément déclencheur, qu'il s'agisse d'un matchmaker, d'un navigateur de serveurs ou du propre backend d'un jeu, le résultat comporte les mêmes éléments de base, et chacun d'eux doit être approuvé par le backend, le serveur et les clients des joueurs :
Une version de build. L'image exacte qui s'exécute, afin que chaque joueur de la partie se connecte à la même version du jeu.
Une taille. La quantité de processeur (CPU) et de mémoire qui lui est allouée, souvent une fraction de vCPU pour un serveur léger.
Une localisation. L'endroit où il s'exécute, idéalement proche des joueurs de la partie.
Une adresse et des ports. Une adresse publique et les ports auxquels les joueurs se connectent. Le port externe diffère souvent de celui sur lequel le serveur écoute à l'intérieur de son conteneur, une cause fréquente d'échec des premières connexions (mappage de ports).
Des données de partie. Ce que le serveur doit savoir au démarrage, comme l'identité des joueurs attendus, le mode de jeu et la carte, généralement transmises sous forme de variables d'environnement.
Des tags. Des étiquettes permettant de retrouver le déploiement ultérieurement dans les journaux, les tableaux de bord et les tickets d'assistance.
Lorsque l'un de ces éléments est incorrect, le symptôme apparaît généralement ailleurs : un joueur qui ne peut pas se connecter, un serveur qui exécute l'ancienne version du build, ou un plantage impossible à tracer.
Comment commence et se termine un déploiement ?
Le démarrage est généralement automatique. Un système de matchmaking ou un navigateur de serveurs demande un déploiement dès que les joueurs ont besoin d'un serveur, l'infrastructure choisit l'endroit où il s'exécute, et le conteneur démarre. Le temps que cela prend est le démarrage à froid, et l'affectation d'un groupe de joueurs à un serveur spécifique est l'allocation de serveur.
L'arrêt nécessite plus de réflexion. Un déploiement s'arrête généralement de l'une de ces cinq manières :
Le serveur s'arrête lui-même à la fin de la partie, en appelant un point de terminaison d'arrêt.
Le backend du jeu l'arrête, par exemple une fois que tous les joueurs sont partis.
Une durée maximale s'écoule.
Le serveur plante et, selon sa politique de redémarrage, est redémarré ou laissé à l'arrêt.
La machine sous-jacente est mise hors service.
La première méthode est souvent la plus fiable, car le serveur sait quand sa partie est terminée. Les deux dernières expliquent pourquoi il est préférable d'envoyer les résultats de la partie et les journaux au fur et à mesure plutôt que de les conserver pour la fin, comme le décrit la page des conteneurs.
Un déploiement que personne n'arrête continue de s'exécuter et, dans le cas d'une facturation à l'usage, continue de coûter. Une durée maximale est un garde-fou utile, à condition d'être plus longue que la partie la plus longue.
Session ou persistant. La plupart des déploiements durent le temps d'une seule partie. Un monde persistant, un espace social ou un fragment de MMO maintiennent un déploiement actif pendant plusieurs jours. Les plateformes cloud limitent souvent le temps d'exécution, de sorte que les serveurs à longue durée de vie s'exécutent généralement sur des hôtes réservés, avec un état sauvegardé en dehors du conteneur, et sont remplacés selon un calendrier plutôt que conservés indéfiniment.
Comment les serveurs de jeux se mettent-ils à jour sans interruption ?
Le « déploiement » a une deuxième signification : le déploiement d'une nouvelle version (build). C'est là que se dirigent les recherches sur les déploiements bleu-vert et sans interruption (zero-downtime).
Pour les jeux basés sur des matchs, les déploiements par match rendent cette fonctionnalité presque intégrée. Dès qu'une nouvelle version est publiée, les nouveaux matchs démarrent sur celle-ci tandis que les matchs en cours se terminent sur l'ancienne. Aucun serveur n'est mis à jour sur place, donc aucun match n'est interrompu. Deux conditions permettent d'y parvenir : l'ancienne et la nouvelle version peuvent fonctionner côte à côte pendant toute la durée du match le plus long, et les joueurs qui utilisent encore l'ancien client sont maintenus sur les serveurs de l'ancienne version ou invités à faire une mise à jour. L'allocation de serveurs couvre les problèmes qui surviennent le jour du déploiement d'un correctif.
Le déploiement bleu-vert applique le même concept à l'ensemble d'un environnement : la nouvelle version fonctionne à côté de l'ancienne, le trafic est redirigé, et l'ancienne version reste prête pour un retour en arrière (rollback). Les serveurs persistants représentent le cas le plus complexe. Ils nécessitent une vidange, avec le transfert des joueurs vers un nouveau déploiement, ou un redémarrage pendant les heures les plus creuses.
Sur Edgegap, un correctif uniquement côté serveur suit le modèle par match : une nouvelle version de l'application pointe vers la nouvelle image et, une fois qu'elle est en ligne, les nouveaux matchs l'utilisent tandis que les matchs en cours se terminent sur l'ancienne (documentation du matchmaker). Notre guide sur les mises à jour progressives automatisées couvre l'ensemble du pipeline. Les balises d'image uniques, qui transforment un retour en arrière en un simple changement de pointeur, sont abordées dans la section sur les conteneurs.
Pourquoi l'hébergement de serveurs de jeux est-il mesuré en déploiements ?
Sur l'hébergement basé sur l'usage, la facture suit les déploiements, et non les machines. Chacun est facturé selon sa taille pendant qu'il fonctionne, le modèle derrière un serveur de jeu serverless. Deux facteurs déterminent le coût : la taille de chaque déploiement et sa durée de vie. Dimensionner correctement un build, avec une fraction de vCPU lorsque le jeu le permet ou plusieurs matchs dans un seul serveur multi-salles, et arrêter les déploiements à temps importent souvent plus que le tarif horaire. Les tarifs actuels et un calculateur sont disponibles sur notre page de tarification.
Compter les déploiements permet également de mesurer l'échelle et la vitesse. Edgegap a exécuté 135 millions de déploiements de serveurs de jeux depuis février 2019, un décompte qui inclut les déploiements qui n'ont pas réussi à démarrer. Son temps de déploiement médian est de 2 secondes, du démarrage à froid au conteneur prêt sur une période glissante de 30 jours, et il a soutenu 40 déploiements par seconde lors d'un benchmark en novembre 2023 (données de la plateforme, 18 septembre 2026). Un déploiement qui ne parvient pas à démarrer n'est pas facturé (documentation sur les déploiements).
Un mot de notre sponsor (nous-mêmes !)
Les pools chauds rendent l'allocation rapide car vous payez pour des serveurs qui restent inactifs. Edgegap déploie un nouveau serveur de jeu en une médiane de 2 secondes à partir d'un démarrage à froid, mesuré jusqu'à ce que le conteneur soit prêt avant le démarrage de votre moteur, de sorte qu'un serveur n'existe que lorsqu'un match en a besoin.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
Faites en sorte que chaque déploiement s'arrête de lui-même
Une grande part des coûts d'hébergement évitables provient souvent de déploiements qui ont survécu à leur partie : un serveur qui n'a jamais su que le dernier joueur était parti, un déploiement de test laissé en fonctionnement pendant le week-end, ou une version défectueuse qui redémarre en boucle. La facturation à la minute n'est rentable que si chaque déploiement s'arrête lorsque son travail est terminé.
Intégrez l'arrêt directement dans le serveur, et pas seulement dans le backend : lorsque la partie se termine, le serveur s'arrête de lui-même. Ensuite, vérifiez-le. Chaque semaine, listez les déploiements qui ont fonctionné plus longtemps que votre partie la plus longue possible. Chacun d'eux est soit un serveur persistant que vous aviez l'intention de conserver, soit une fuite à corriger.
Sur Edgegap, chaque déploiement reçoit sa propre URL d'arrêt et son jeton lors de son démarrage, chaque version d'application peut définir une durée maximale de sécurité, et les balises facilitent la recherche et le nettoyage des déploiements de test.
,
