Vous avez ajouté les serveurs de jeu et l'orchestration d'Edgegap à votre jeu (félicitations !) et vous êtes maintenant prêt à passer à l'étape suivante : lancer l'hébergement de votre serveur de jeu multijoueur dans le monde réel.

Cela peut sembler intimidant. Et si la montée en charge ne fonctionnait pas, comme pour tant de projets d'envergure auparavant ?

Ce guide est conçu pour vous aider à préparer le lancement de votre jeu en mettant en lumière la façon dont Edgegap gère l'afflux soudain de trafic afin que votre jeu s'adapte en parfaite synchronisation avec la demande des joueurs.

Cet article doit être utilisé en parallèle avec notre « Liste de contrôle pré-lancement pour les jeux multijoueurs ».

Comment Edgegap gère-t-il les pics de charge imprévus sur sa plateforme ?

Avant tout, nous traitons chaque déploiement comme une entité distincte sur notre plateforme. Chaque déploiement est un pod au sein de notre infrastructure. Les requêtes proviennent de diverses sources, notamment des clients de jeu eux-mêmes, du matchmaker ou de tout autre moyen par lequel les utilisateurs interagissent avec notre API.

Dès qu'une requête arrive dans notre système, nous lançons immédiatement la télémétrie et la géolocalisation du joueur, et nous attribuons des tâches à nos workers pour provisionner un serveur sur notre infrastructure. En une seconde ou deux, le conteneur est opérationnel et prêt à accueillir les joueurs.

Comment garantissons-nous que toute l'infrastructure nécessaire est en place pour répondre rapidement à ces déploiements ?

Nous avons développé une couche d'abstraction supervisant 17 fournisseurs différents, englobant le cloud, le bare metal, l'edge et les fournisseurs de conteneurs en tant que service (Container-as-a-Service). Ensemble, ils nous offrent plus de 600 centres de données à travers le monde.

Notre liste de fournisseurs associe des acteurs à couverture mondiale, tels qu'Amazon, Google et Azure, à des services localisés spécifiques à un pays ou à une région. Cette approche complémentaire vous garantit la meilleure couverture, permettant à votre jeu de s'appuyer sur le plus grand réseau edge distribué au monde.

Au sein de notre plateforme, ces entités sont appelées points d'accès (Access Points), chacun disposant d'informations essentielles telles que la capacité, la charge de travail actuelle, les ressources disponibles et d'autres mesures pertinentes pour la prise de décision. Grâce à cette couche d'abstraction, vous n'avez pas à vous soucier de la provenance de vos joueurs, ni du fournisseur avec lequel vous devez travailler.

Cela vous permet de vous concentrer sur le jeu, tandis qu'Edgegap se charge d'orchestrer et de gérer l'infrastructure sous-jacente.

Quelles sont les priorités de la plateforme d'Edgegap, et dans quel ordre ?

La plateforme d'Edgegap donnera la priorité aux éléments suivants, dans cet ordre :

1. Vous fournir un serveur de jeu fonctionnel, basé sur les exigences que vous spécifiez dans le profil de votre application.

2. Rapprocher le plus possible le serveur de jeu des joueurs, avec le chemin réseau le plus court, afin d'offrir la meilleure expérience de jeu possible, sur la base de diverses mesures télémétriques.

3. Vous fournir un serveur de jeu fonctionnel le plus rapidement possible. L'objectif est de 1 à 2 secondes.

Lorsque nous subissons un afflux soudain (et nous parlons d'une quantité ÉNORME de trafic en un laps de temps très COURT ; par exemple, plus de 40 déploiements par seconde, ce qui signifie que 1 300 joueurs tentent d'accéder à un match dans un jeu à 32 joueurs chaque seconde, soit 4,6 millions de joueurs en 60 minutes), la liste ci-dessus devient plus difficile à assurer pendant les premières minutes de l'afflux. Dans ces rares cas, l'élément 2 (la proximité) est le premier à être assoupli : certains serveurs peuvent être placés légèrement plus loin des joueurs le temps que le système s'adapte, afin de garantir que chaque demande de déploiement soit honorée.

Combien de temps faut-il généralement à la plateforme pour se stabiliser en cas d'afflux de trafic imprévu ?

La plateforme d'Edgegap gère couramment bien plus de 40 déploiements par seconde pour l'ensemble des jeux qu'elle héberge, de sorte que les pics quotidiens n'atteignent jamais cette phase critique. La fenêtre de 10 à 15 minutes ne s'applique qu'à un cas extrême : un seul jeu ajoutant soudainement plus de 40 déploiements par seconde de trafic non planifié (environ 4,6 millions de joueurs en une heure). Même dans ce cas, les serveurs continuent de se déployer. Les temps de déploiement pour ce jeu peuvent dépasser l'objectif de 1 à 2 secondes jusqu'à ce que la nouvelle capacité se stabilise, ce qui peut prendre de 10 à 15 minutes. Il s'agit du temps de montée en charge de la flotte dans un cas extrême, et non du temps de démarrage typique d'un serveur. Dans des conditions normales, les serveurs démarrent en un temps médian de 2 secondes à partir d'un démarrage à froid (2026, données de la plateforme).

Quelle est l'approche d'Edgegap face à un afflux de trafic soudain et imprévu ?

Notre gestionnaire de capacité (surnommé « Capman ») est conçu pour réagir au trafic entrant, en s'interfaçant avec les workers qui demandent des ressources.

Lorsqu'il détecte une augmentation de la demande, il augmente automatiquement la capacité des régions spécifiques où les ressources sont nécessaires en déployant des machines plus puissantes. S'il détecte une zone géographique nécessitant un soutien supplémentaire, il y provisionne davantage de machines afin d'optimiser la latence et l'expérience des joueurs. Tout cela se fait automatiquement.

Pour les pics plus importants nécessitant beaucoup de processeur (par exemple, un serveur de jeu nécessitant 2 processeurs pour chaque instance), la première augmentation de capacité prend entre 2 et 5 minutes. Après cela, le système s'adapte beaucoup plus rapidement car il demande des serveurs plus grands. Il ajuste la taille des serveurs demandés à chaque fournisseur en fonction du flux de trafic, demandant des serveurs plus petits ou plus grands selon que l'afflux s'accélère ou ralentit.

En résumé : pour les pics gourmands en processeur, la première augmentation de capacité prend de 2 à 5 minutes. Une stabilisation complète lors d'un afflux extrême et imprévu (plus de 40 déploiements par seconde pour un seul jeu) peut prendre jusqu'à 10-15 minutes, et les serveurs continuent de se déployer pendant ce temps. Le trafic quotidien standard n'est pas affecté.

Notes supplémentaires : cela ne se produit pas lorsque nous sommes informés d'un événement à l'avance (lancement, correctifs, etc.), ni pour les augmentations et diminutions normales de capacité (trafic typique sur 24 heures). Cela ne s'applique qu'aux pics imprévus, par exemple lorsqu'un streamer commence à jouer à votre jeu et qu'une multitude de nouveaux joueurs rejoignent l'aventure.

Pourquoi cela ne se produit-il pas pour les augmentations de capacité standard sur 24 heures, mais uniquement lors d'un afflux IMPRÉVU ?

Pour gérer le trafic quotidien, notre plateforme est conçue pour suivre le pic quotidien à mesure qu'il se déplace vers l'ouest à travers les fuseaux horaires, en augmentant la capacité de la région active suivante à l'avance.

En exploitant l'analyse prédictive et en surveillant les modèles de trafic, nous anticipons le moment et le lieu où les pics de trafic sont susceptibles de se produire. Notre infrastructure ajuste sa capacité de manière proactive avant ces périodes de pointe.

Cette mise à l'échelle proactive garantit que les ressources nécessaires sont disponibles au moment et à l'endroit où elles sont requises, maintenant ainsi une expérience de jeu fluide même pendant les périodes de forte demande.

Quel est le comportement d'Edgegap lorsque les points d'accès viennent à manquer et que les nouveaux points d'accès alloués se trouvent dans une région éloignée d'un joueur ?

Lorsqu'un déploiement est demandé, la plateforme prend la meilleure décision en fonction des ressources disponibles. Si la plateforme reçoit un nombre important et imprévu de requêtes pour une région spécifique, les ressources peuvent se faire rares dans cette région pendant que le système augmente sa capacité.

Dans de tels cas, et uniquement pendant la phase de montée en charge du système, les serveurs peuvent être placés légèrement plus loin que le meilleur emplacement initial.

L'objectif est de toujours disposer de capacité, quelle que soit la situation. Ces scénarios catastrophes se produisent rarement et sont temporaires, car le système s'adapte et apprend à connaître le comportement du nouveau trafic.

Que puis-je faire pour obtenir les meilleures performances de la plateforme d'Edgegap ?

Voici quelques mesures que vous pouvez prendre pour tirer le meilleur parti de notre plateforme avant un afflux de trafic prévu.

Voici la liste de contrôle :

1. Communiquez !

   • Si vous savez qu'un événement se prépare dans votre jeu (lancement, correctifs, tournois, streamers), prévenez l'équipe.

   • Les événements prévus (lancements, correctifs, tournois) partagés avec Edgegap à l'avance ne sont pas soumis à cette phase de montée en charge, car la capacité est pré-approvisionnée.

   • Ceci n'est recommandé que pour les grands événements planifiés, car la plateforme apprend votre modèle de trafic au fil du temps (c'est-à-dire les variations de trafic sur 24 heures) et ajuste sa capacité à la hausse ou à la baisse en conséquence.

2. Pour éviter les erreurs de délai d'attente (timeout), vous pouvez augmenter la valeur « max_time_to_deploy » de votre AppVersion via le tableau de bord ou notre API.

   • Le délai d'attente est le temps que notre système attendra avant de marquer un serveur de jeu (un déploiement) comme étant en erreur. Lors d'un afflux extrême, les déploiements individuels pour le jeu à l'origine de l'afflux peuvent mettre plus de temps que d'habitude à être prêts. Les autres jeux sur la plateforme ne sont pas affectés.

   • Définir ce délai d'attente à une valeur légèrement supérieure évite que les déploiements qui prennent un peu plus de temps lors d'un pic de trafic ne soient signalés en erreur par notre plateforme.

3. Nous vous recommandons de configurer votre système (par exemple, le lobby, le matchmaker) pour qu'il réessaie si cela se produit.

   • La plateforme fera toujours tout son possible pour vous fournir un serveur de jeu via un simple appel API. Cela dit, un volume de trafic très (et nous disons bien TRÈS !) important en un temps très court peut contraindre notre système à renvoyer un message d'erreur. Intégrez une logique de tentative dans votre matchmaker avec un évitement exponentiel (attendez plus longtemps entre chaque tentative, sans jamais relancer de requête toutes les secondes). Il s'agit d'une pratique standard de résilience pour tout orchestrateur soumis à une charge soudaine.

4. Bien que parler d'un plan de reprise d'activité puisse sembler contre-intuitif dans un document sur les performances, nous pensons que couvrir chaque aspect de chaque scénario est au cœur de notre métier et de notre façon de travailler.

   • Notre système repose sur une architecture de microservices, avec des composants hautement résilients.

   • Ces composants sont indépendants des fournisseurs : ils peuvent fonctionner chez n'importe quel prestataire et peuvent être facilement déployés ou redéployés pour ajouter de la capacité, ou pour réinstaller une nouvelle plateforme en cas de panne catastrophique.

   • De plus, les composants non critiques ne sont pas requis pour le service principal, de sorte que l'orchestration et l'hébergement des serveurs de jeu restent toujours la priorité absolue.

5. Préparez-vous avec un test de charge !

   • Il n'y a pas de meilleur moyen d'évaluer le comportement de l'infrastructure de votre jeu, d'Edgegap aux services de jeu, qu'avec un test de charge.

   • Nous vous recommandons vivement d'en effectuer un avant votre lancement, car cela fait partie de notre liste de contrôle de pré-lancement. Consultez l'article pour plus de détails.

Comment maintenons-nous des tarifs compétitifs ?

À mesure que le trafic se stabilise, nos systèmes automatisés réduisent la taille de l'infrastructure tout en conservant la capacité nécessaire pour servir vos joueurs. Les modèles de trafic et les tendances d'utilisation sont surveillés en continu, et l'analyse prédictive anticipe la demande afin d'ajuster la capacité à l'avance.

L'optimisation des coûts va au-delà de la simple réduction de capacité. Nous examinons continuellement notre façon d'utiliser chaque fournisseur, y compris des options telles que les instances réservées. Maintenir l'infrastructure au plus juste nous permet de répercuter ces économies sur nos clients sans faire de compromis sur les performances ou la fiabilité.

Conclusion

Edgegap met en œuvre de nombreuses solutions pour s'assurer que, quel que soit le volume de trafic généré par votre jeu, l'infrastructure puisse s'adapter rapidement pour répondre à la demande des joueurs.

Néanmoins, vous pouvez également faire beaucoup pour planifier à l'avance et prévenir les erreurs. Nous espérons que ce guide vous aidera à améliorer votre backend et, en fin de compte, vous apportera la tranquillité d'esprit en sachant que votre architecture multijoueur est conçue pour s'adapter à la demande de vos joueurs, et que ces derniers bénéficieront d'une expérience fluide et amusante.