Auto Scaling
La mise à l'échelle automatique ajoute et supprime automatiquement de la capacité de serveurs de jeu au fur et à mesure que la demande des joueurs augmente et diminue. La politique détermine quand démarrer les serveurs, quelle marge de sécurité conserver avant la demande, et à quelle vitesse libérer la capacité par la suite. Bien réglée, elle est invisible ; mal réglée, elle produit soit des files d'attente, soit des machines inutilisées.
Aussi appelé
mise à l'échelle automatique
,
Que met à l'échelle l'Auto Scaling dans un jeu Multiplay ?
Dans un jeu multijoueur, l'unité de demande est une partie. Les joueurs font la queue, le système de matchmaking les regroupe, et le groupe a besoin d'un serveur.
Une partie contient un état en direct, et elle ne peut pas être divisée entre plusieurs serveurs ou déplacée en cours de jeu sans que les joueurs ne s'en aperçoivent. Ainsi, le chiffre qui importe n'est pas le niveau d'occupation des serveurs. C'est le nombre de parties supplémentaires qu'ils peuvent accueillir. Un serveur à 30 % de processeur avec une partie complète ne peut pas en accueillir une autre. C'est pourquoi la mise à l'échelle des serveurs de jeu surveille généralement la capacité libre : les emplacements de partie ouverts, ou les serveurs prêts et en attente.
Cette capacité s'obtient de deux manières. Conserver une flotte de machines et l'adapter avant la demande, ou démarrer un serveur pour chaque partie lorsque la partie le demande, ce qui dépend de la vitesse de démarrage d'un serveur (son démarrage à froid).
Que décide une politique de dimensionnement automatique ?
Plus qu'une simple question de quantité. Une politique décide du moment où la capacité est ajoutée, de sa quantité, de son emplacement et du moment où elle est libérée :
Marge de sécurité (Headroom) : Capacité libre conservée en prévision de la demande, afin de couvrir les parties qui commencent pendant que la nouvelle capacité se met en place.
Seuils et limites : Ce qui déclenche un changement, ainsi que les minimums et maximums à ne pas dépasser.
Emplacement : Les pics d'activité se déplacent avec les fuseaux horaires. Une capacité au mauvais endroit ne réduit la file d'attente de personne, et un serveur éloigné de ses joueurs offre une moins bonne expérience de jeu. L'ajustement de la capacité se fait à la hausse et à la baisse, mais aussi de manière géographique, à travers différents emplacements et les réseaux qui y acheminent les joueurs.
Libération : La rapidité avec laquelle la capacité est restituée lorsque la demande diminue.
Aucun de ces paramètres n'est figé. Les taux de requêtes, les temps de démarrage, la durée des parties et la latence des joueurs évoluent constamment, de sorte qu'à grande échelle, une politique est un flux continu de décisions prises à partir de données en temps réel.
Les deux modes de défaillance mentionnés dans la définition laissent une empreinte. Des files d'attente lors des pics d'activité signifient que la capacité arrive trop tard ou au mauvais endroit. Des machines inactives en période creuse signifient qu'elle est libérée trop tard. Ce second cas est plus difficile à détecter, car aucun joueur ne le signale.
Pourquoi est-il plus difficile, et plus coûteux, de réduire la taille que de l'augmenter ?
La mise à l'échelle vers le haut (scaling up) ajoute un serveur. La mise à l'échelle vers le bas (scaling down) doit attendre que l'un d'eux se vide.
Une machine hébergeant plusieurs parties ne peut être libérée que lorsque sa dernière partie se termine. Les parties se terminent à des moments décalés, de sorte qu'après un pic, les machines se vident partiellement. Cette traîne inactive est une capacité payée qui n'héberge personne, et un monde persistant peut ne jamais se vider du tout.
Les deux façons de raccourcir la traîne ont chacune un coût :
Le regroupement (Packing). Les nouvelles parties vont d'abord vers les machines les plus remplies, de sorte que les plus vides se vident plus tôt.
La fin précoce des parties. Cela y met fin pour les joueurs, c'est pourquoi les outils de mise à l'échelle (scalers) offrent généralement une protection pour les parties en cours.
L'adaptation des parties sur les machines pour qu'elles se vident proprement est un travail semblable à Tetris, qui se joue 24 heures sur 24. Avec l'auto-hébergement, les développeurs du studio le construisent et l'ajustent. Avec l'orchestration, c'est automatisé : les fournisseurs hybrides associent une capacité réservée pour la charge constante à une capacité à la demande pour les pics, qui démarre et s'arrête avec ses parties. Déterminer si le développement en interne en vaut le temps est une question de coût, et la page des tarifs donne un chiffre pour la solution clé en main.
Comment le temps de démarrage du serveur influence-t-il l'auto-scaling ?
La marge de manœuvre existe parce que le déploiement d'une nouvelle capacité prend du temps. Lorsqu'un serveur met plusieurs minutes à démarrer, une politique conserve des minutes de demande en réserve, dans chaque emplacement.
Lorsqu'un serveur démarre en quelques secondes, un match peut en obtenir un dès qu'il le demande. La marge de manœuvre devient une capacité réservée : une décision de coût, qui vaut la peine d'être maintenue là où elle reste active. Cela aide également l'autre moitié. Un serveur démarré pour un match s'arrête lorsque ce match se termine, il n'y a donc pas de file d'attente à vider. La plupart des jeux combinent les deux : une base dimensionnée pour une charge stable, et tout le reste à la demande (orchestration hybride).
Sur l'Edge Cloud d'Edgegap, les serveurs démarrent en un temps médian de 2 secondes, et la plateforme a soutenu 40 déploiements par seconde sur un benchmark de 60 minutes (données de la plateforme : période glissante de 30 jours jusqu'au 18 septembre 2026 ; novembre 2023). Les serveurs liés à un match s'arrêtent à la fin de celui-ci, facturés à la minute.
Les studios souhaitant optimiser entre une capacité réservée rentable (Private Fleets, 58 emplacements) et une capacité à la demande (Edge Cloud, plus de 615 emplacements à la demande dans le monde) peuvent le faire grâce à l'orchestration hybride d'Edgegap.
Un mot de notre sponsor (nous-mêmes !)
Les lancements et les pics de trafic viral n'arrivent pas un serveur à la fois. Lors d'un test de performance de 60 minutes, Edgegap a démarré 40 serveurs de jeu par seconde pendant toute une heure, sur plus de 550 emplacements et via 17 fournisseurs, de sorte qu'un afflux de joueurs se traduit par des parties jouées en ligne, et non par une longue file d'attente.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
Passer à l'échelle n'est que la moitié de la décision
Chaque orchestrateur monte en charge. Deux autres questions déterminent s'il convient à votre jeu.
Où se positionne la nouvelle capacité ? La mise à l'échelle doit suivre les joueurs par emplacement et par itinéraire réseau, en temps réel, au fur et à mesure que le pic se déplace.
À quelle vitesse s'arrête-t-elle ? La capacité qui survit à sa partie est facturée alors que personne ne l'utilise.
Edgegap répond aux deux pour chaque partie. Chaque déploiement va vers le meilleur emplacement disponible sur le réseau Edge Cloud au moment de la demande, démarre en une médiane de 2 secondes, et s'arrête lorsque la partie se termine. Les studios ayant une charge stable réservent des hôtes Private Fleet et basculent vers Edge Cloud au-delà de cette limite.
Posez ces deux questions à n'importe quel fournisseur, avec des chiffres, pour votre heure de pointe et l'heure suivante.
,
