Démarrage à froid
Le démarrage à froid est le délai entre la demande d'un serveur de jeu et le moment où son conteneur est prêt à accueillir une partie, provisionné à partir de zéro plutôt qu'alloué sur une instance déjà en cours d'exécution. Le jeu se charge ensuite à l'intérieur du conteneur avant que les joueurs ne s'y connectent. Un démarrage à froid définit le temps d'attente minimal pour un groupe de joueurs mis en relation, et des démarrages trop longs contraignent les studios à maintenir une capacité de réserve active, ce qui représente un coût financier.
Aussi appelé
temps de démarrage, temps de démarrage du serveur
,
Que se passe-t-il lors d'un démarrage à froid d'un serveur de jeu ?
Un démarrage à froid (cold start) représente la partie de la plateforme nécessaire pour mettre un match en ligne. Lorsqu'un système de matchmaking demande un serveur, la plateforme choisit une machine, s'assure que l'image du serveur y est présente, crée le conteneur, mappe les ports par lesquels les joueurs se connecteront et démarre le processus du serveur. Le conteneur est alors prêt à accueillir le match.
La partie liée au jeu vient ensuite. Le moteur démarre à l'intérieur du conteneur et charge la carte avant que les joueurs ne se connectent. Cette étape dépend de la version du jeu, et non de l'hébergement : un serveur dédié sans interface graphique (headless) livré sans les ressources de rendu a généralement moins de données à charger.
La répartition du temps de la plateforme varie. L'acheminement de l'image sur la machine est souvent l'étape la plus lente, c'est pourquoi les plateformes qui démarrent les serveurs rapidement ont tendance à conserver les images en cache à proximité de leur lieu d'exécution. Et si aucune machine en cours d'exécution n'a de place disponible, une nouvelle doit d'abord être provisionnée, ce qui représente une tout autre échelle de temps (voir « Warm Pools or Cold Starts: What Does Each Cost? »).
En pratique - Aperçus du blog de Edgegap
Points clés de l'article
Objectif de modernisation de l’infrastructure : KRAFTON visait à éliminer les goulots d’étranglement opérationnels et à améliorer la scalabilité pour des centaines de milliers de joueurs simultanés dans des régions mondiales en passant d’un serveur de jeu basé sur les sessions à une orchestration moderne de serveurs de jeu basée sur des conteneurs.
Limites de mise à l’échelle d’Agones : La plateforme open source d’orchestration de serveurs de jeu souffrait de délais d’amorçage de 15 minutes lors des pics de mise à l’échelle. L’équipe d’ingénierie de KRAFTON a fortement investi dans des solutions personnalisées pour réduire ce délai à 3-4 minutes grâce à des proxys de registre de conteneurs et à l’adoption de Karpenter. Alors que les développeurs peuvent simplement utiliser une solution entièrement gérée comme Edgegap, qui démarre les serveurs de jeu à partir d’un démarrage à froid en 3 secondes en moyenne.
Avantages en efficacité opérationnelle : La conteneurisation a réduit le provisionnement des environnements à moins de 5 minutes et a permis des capacités de libre-service. Les équipes ont obtenu un accès autonome à l’infrastructure de test sans intervention DevOps.
Impact caché sur les ressources : Le parcours de modernisation a consommé des années d’efforts d’ingénierie spécialisés qui auraient pu être consacrés à l’amélioration du gameplay. La plupart des studios ne peuvent pas se permettre ce niveau d’investissement en infrastructure tout en maintenant des cycles de développement compétitifs.
Alternative de plateforme gérée : Les solutions entièrement gérées offrent des performances et des capacités de mise à l’échelle équivalentes, voire supérieures, sans complexité interne. Les studios obtiennent une infrastructure de niveau entreprise grâce à une intégration simple plutôt qu’à des projets de mise en œuvre sur plusieurs années en utilisant une plateforme comme Edgegap.
Pourquoi les heures de démarrage publiées du serveur ne correspondent-elles pas ?
Parce qu'ils mesurent souvent des tâches différentes. Trois questions vous permettent de savoir ce qu'un chiffre englobe :
Où commence le chronomètre ? L'attribution d'un match à un serveur déjà en cours d'exécution est une allocation. La création du serveur pour ce match est un démarrage à froid. Les deux sont réels, et le premier est généralement plus rapide car le travail a été effectué plus tôt.
Où s'arrête-t-il ? Lorsque le conteneur est prêt, ou une fois que le jeu est chargé. L'écart entre les deux correspond au temps de démarrage propre au jeu.
Médiane ou moyenne ? La médiane correspond à l'attente d'un match typique. Une moyenne peut être tirée vers le haut ou vers le bas par quelques démarrages inhabituels.
Deux chiffres honnêtes peuvent différer pour ces seules raisons. Un chiffre à chaud indique la vitesse à laquelle un tampon distribue ce qu'il contient déjà. Un chiffre à froid indique ce qui se passe lorsque le tampon est vide.
Pools chauds ou démarrages à froid : quel est le coût de chaque option ?
Un groupe de serveurs tièdes maintient les serveurs en fonctionnement avant que les joueurs n'en aient besoin, de sorte qu'une partie peut être attribuée en quelques instants. AWS GameLift appelle cela un tampon et expose clairement le compromis : un tampon plus important réduit le temps d'attente des joueurs, mais vous payez pour de la capacité que vous risquez de ne pas utiliser (documentation AWS). L'autoscaler de flotte d'Agones fonctionne de la même manière, adaptant la taille de la flotte pour maintenir un nombre défini de serveurs prêts (documentation Agones).
Le groupe doit être dimensionné en prévision de la demande, et un pic peut le vider. Après cela, les nouvelles parties attendent que de la capacité soit ajoutée. Sur sa configuration Agones pour PUBG: Battlegrounds, KRAFTON a signalé jusqu'à 15 minutes pour mettre en ligne de nouveaux serveurs lors des pics de montée en charge : 1 à 3 minutes pour provisionner les instances, 2 à 3 pour les démarrer et 5 à 10 pour provisionner les pods (AWS re:Invent 2024, résumé ici).
Plus le démarrage à froid est rapide, plus le groupe peut être restreint, et moins un pic coûte cher en temps d'attente pour les joueurs.
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 !)
Pourquoi nous mesurons les démarrages à froid à partir de zéro
Edge Cloud d'Edgegap démarre un serveur de jeu en 2 secondes, en moyenne, à partir d'un démarrage à froid : provisionné à partir de zéro plutôt qu'alloué sur un serveur déjà en cours d'exécution, mesuré jusqu'à ce que le conteneur soit prêt, avant le démarrage du moteur de jeu (données de la plateforme, sur 30 jours glissants, au 18 septembre 2026).
Nous mesurons à partir de zéro car c'est le cas lors des tests de lancement. Un pool chaud masque le temps de démarrage jusqu'à ce qu'un pic d'activité l'épuise, et à partir de ce moment, les nouveaux matchs attendent un démarrage à froid. Lorsque cette attente est de 2 secondes, les serveurs peuvent être déployés à la demande, sans aucun buffer à dimensionner ou à payer.
La capacité chaude a toujours sa place. Si un jeu met du temps à charger sa carte, les serveurs peuvent être préchauffés via des politiques de mise à l'échelle du Server Browser, généralement sur des Private Fleets. Le préchauffage couvre le propre temps de chargement du jeu, ce que la vitesse de déploiement n'impacte pas.
,
