Bassins chaleureux
Un pool chaud est une capacité de serveur démarrée à l'avance et maintenue prête, de sorte qu'un match n'attend pas un démarrage à froid. Il échange de l'argent contre du temps : le pool coûte la même chose que les matchs l'utilisent ou non. Sa valeur dépend du démarrage à froid : lorsque les nouveaux serveurs démarrent en quelques secondes, un pool devient une décision de coût plutôt qu'une exigence.
Aussi appelé
capacité réservée, pool chaud, pool de serveurs chauds, préchauffage
,
Que contient réellement une piscine chaude ?
Un pool chaud est une capacité de serveur maintenue prête avant que les matchs ne la demandent. L'alternative est le sur-demande : démarrer un serveur lorsqu'un match en fait la demande. Ce que le pool contient détermine le temps d'attente qu'il élimine :
Machines arrêtées. Configurer, puis arrêter. Les pools chauds d'AWS EC2 Auto Scaling fonctionnent souvent ainsi : la machine démarre, puis le serveur de jeu se lance.
Machines prêtes à accepter des instances de serveur de jeu. Des hôtes en cours d'exécution avec l'image du serveur déjà installée, de sorte qu'une nouvelle instance démarre sans avoir à provisionner une machine au préalable.
Instances en cours d'exécution. Le serveur de jeu est déjà actif, parfois avec sa carte chargée, et un match lui est alloué au lieu d'attendre un démarrage à froid.
Chaque étape réduit davantage l'attente, mais coûte plus cher pour chaque minute passée inutilisée. Les serveurs multi-salles ont leur propre version : les salles libres dans un serveur en cours d'exécution représentent une capacité pour laquelle le processus paie déjà.
En pratique - Aperçus du blog de Edgegap
Points clés de l'article
L'estimation des coûts cloud pour l'hébergement de serveurs de jeux est une tâche complexe pour les développeurs de jeux multijoueurs. Les cloud publics utilisent cette complexité pour dissimuler leurs véritables coûts.
Amazon fournit un outil pour établir une estimation, basé sur quelques inputs. Cependant, il cache, par conception, l'inefficacité de l'orchestration traditionnelle par rapport à la prochaine génération d'orchestration juste-à-temps, basée sur des conteneurs utilisant la co-locataire.
Un réservoir d'instances pré-initialisées (warm pool) est-il toujours requis ?
Cela dépend du temps nécessaire pour que la nouvelle capacité arrive. Lorsque l'ajout d'un serveur implique le provisionnement de machines, l'attente se chiffre en minutes. KRAFTON a fait état de jusqu'à 15 minutes pour mettre en ligne de nouveaux serveurs sur sa configuration Agones pour PUBG: Battlegrounds, et de 3 à 4 minutes après l'adoption de Karpenter et d'un proxy de registre de conteneurs (AWS re:Invent 2024). À cette vitesse, le seul moyen de répondre immédiatement à un match est de disposer d'une capacité déjà détenue. Le pool est une exigence de provisionnement, souvent maintenu dans chaque emplacement desservi par le jeu.
Lorsqu'un nouveau serveur démarre en quelques secondes, la question change. Un match peut obtenir un serveur dès qu'il le demande, et le pool devient une capacité réservée : une décision de coût, qui vaut la peine d'être conservée là où elle reste suffisamment active pour coûter moins cher que le service à la demande.
Un cas de figure subsiste dans les deux situations. Démarrer un serveur plus rapidement ne réduit pas le temps de chargement propre au jeu, un point sur lequel revient la partie 4.
Quelle taille doit avoir une piscine chauffée ?
Assez grand pour couvrir le temps nécessaire pour en ajouter d'autres. Un pool n'a qu'à répondre aux matchs qui arrivent pendant que la nouvelle capacité démarre. En gros : les demandes de match par minute, multipliées par les minutes nécessaires pour mettre en ligne un nouveau serveur. Les minutes de temps de recharge nécessitent des minutes de demande maintenues en réserve, et un pic plus important que les prévisions peut toujours le vider.
Sur l'Edge Cloud d'Edgegap, le temps de recharge est le démarrage à froid : 2 secondes, en moyenne, mesuré jusqu'au conteneur prêt (données de la plateforme, 18 septembre 2026). Un pool dimensionné pour le couvrir est proche de zéro.
Deux éléments multiplient le pool que vous détenez :
Emplacements. Un pool se situe dans un emplacement ou une région. Un jeu maintenu au chaud dans cinq régions contient cinq pools, chacun dimensionné pour son propre pic et en partie inactif pendant sa propre nuit.
Versions. Un pool contient une version de serveur. Un correctif vide l'ancien pool et en remplit un nouveau, et les deux peuvent se chevaucher pendant que les joueurs migrent.
Où la capacité réservée coûte-t-elle le moins cher ?
Là où elle reste active. La capacité réservée est payée qu'elle exécute des matchs ou non, elle coûte donc moins cher que le service à la demande uniquement pendant les heures où elle est utilisée. Adaptez sa taille à la charge que votre courbe de simultanéité indique comme suffisante pour la maintenir active, et lancez tout ce qui dépasse à la demande. C'est l'un des principes de l'orchestration hybride.
Sur Edgegap, les hôtes de la Private Fleet hébergent déjà l'image du serveur, de sorte qu'un match commence sur ces derniers sans pool distinct, et déborde sur Edge Cloud lorsque la flotte est pleine. Maintenir des instances en cours d'exécution à l'avance, grâce aux politiques de mise à l'échelle du Server Browser, en vaut la peine dans les cas mentionnés dans notre documentation : un serveur qui met plus de 30 secondes à s'initialiser, un lancement mondial prévoyant un afflux rapide de joueurs, et une topologie de réseau complexe.
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 !)
Une piscine chauffée est un pari sur la demande
Une réserve de serveurs actifs ("warm pool") était la façon dont l'orchestration basée sur une flotte masquait la lenteur du provisionnement : conserver des serveurs dans chaque emplacement, au cas où une partie se présenterait. Lorsqu'un nouveau serveur démarre en quelques secondes, cette raison disparaît. Ce qui reste est une décision de coût.
Diminuez donc la taille de la capacité réservée pour correspondre à la charge qui l'occupera, et lancez tout ce qui dépasse à la demande. Conservez-en moins, et le cloud couvre la différence. Conservez-en plus, et vous payez pour des serveurs qui attendent une prévision. Si vous dimensionnez une réserve pour masquer le temps de démarrage, mesurez d'abord ce temps de démarrage.
L'orchestration hybride répond aux deux aspects à la fois. Les hôtes réservés prennent en charge les mondes persistants et la charge constante qui les occupe, à un coût inférieur. Les déploiements à la demande prennent en charge tout le reste, démarrés au plus près des joueurs dans plus d'emplacements qu'une flotte fixe ne peut en atteindre, afin que les parties se déroulent mieux en ligne.
,
