Emplacements mondiaux de l'Edge Cloud
Cibles de déploiement distinctes où un conteneur de serveur de jeu peut être planifié à la demande.

Migration
/
Agones
Conservez l'architecture que vous avez conçue, évitez de gérer l'orchestration des serveurs de jeu pour vous recentrer sur le développement du jeu.
Déployez à l'échelle mondiale avec un simple appel API, obtenez une adresse et un port en retour, et le binaire de votre conteneur ne change jamais. Ce qui disparaît, c'est la plateforme sous-jacente : les clusters, les pools de nœuds, le contrôleur et l'allocateur, les autoscalers de flotte, le chemin de distribution des images et le cycle de mise à niveau qui suit continuellement trois versions de Kubernetes.
L'orchestration hybride d'Edgegap combine les Private Fleets bare metal, une capacité que vous contrôlez toujours pleinement, avec notre réseau Edge Cloud de plus de 615 emplacements à la demande pour assurer la rentabilité de votre hébergement. Chaque déploiement Edge Cloud est dirigé vers le meilleur emplacement disponible au moment de la requête, mesuré du point de vue du joueur.
Ce qui change (et ce qui ne change pas)
Une migration vers Agones est un changement d'hébergement, pas une réécriture, et l'architecture que vous avez bâtie reste reconnaissable. Voici à quoi vous attendre lors de votre migration.
Une analyse détaillée, fonctionnalité par fonctionnalité, se trouve à l'étape Étape 3 : Identifier et remplacer les fonctionnalités ci-dessous.
Ce qui reste inchangé
Votre netcode et transport
Edgegap ne touche jamais à votre transport, à votre sérialisation ou à votre boucle de tick. Le conteneur exécute le même binaire de serveur que vous construisez aujourd'hui.
Conteneuriser
Vous fournissez déjà une image de conteneur, l'artefact reste donc inchangé. Poussez la même image vers notre registre ou conservez celle que vous utilisez aujourd'hui.
Votre flux de connexion client
Votre client reçoit toujours une adresse et un port et s'y connecte. Seule l'origine de cette adresse change.
Votre modèle d'allocation
La forme de ce que vous avez construit reste la même : votre backend demande un serveur et reçoit en retour les détails de la connexion. Vous remplacez une requête par une autre, sans pour autant redéfinir la manière dont les sessions sont distribuées.
Qu'est-ce qui change
Le SDK d'Agones est disponible
Ready(), Health(), Allocate(), Reserve() et Shutdown() quittent votre binaire, et le sidecar du SDK quitte la spécification du pod avec eux. Edgegap n'a besoin d'aucun SDK serveur. Votre serveur lit son IP publique et son mappage de ports à partir des variables d'environnement lors du déploiement, et il est prêt dès qu'il commence à écouter.
Un seul appel de déploiement remplace GameServerAllocation
Au lieu de créer une GameServerAllocation et d'extraire l'état, l'adresse et le port du résultat, votre backend effectue une seule requête POST vers le point de terminaison de déploiement, puis reçoit le FQDN et le port via un webhook de déploiement ou en interrogeant l'état du déploiement. Aucun sélecteur d'étiquettes, aucune topologie d'allocateur.
Le cluster cesse d'être sous votre responsabilité
Pas de contrôleur ni d'allocateur à gérer, pas de pools de nœuds à provisionner et à optimiser, pas de circuit de distribution d'images à concevoir, pas de tableaux de bord de flotte à surveiller à 3 heures du matin, et aucune décision à prendre quant aux régions dans lesquelles déployer et payer un cluster. Un seul appel atteint chaque emplacement, et vous payez pour le déploiement plutôt que pour le cluster qui se trouve derrière. Le téléavertisseur pour le système qui lance vos correspondances passe chez nous.
La course effrénée aux mises à niveau est terminée
Agones prend en charge trois versions de Kubernetes à la fois, de sorte que les mises à niveau des clusters et de l'orchestrateur s'effectuent au rythme d'un tiers, dans chaque région, pour toujours. Ce calendrier n'est plus votre problème, et son test non plus.
Calendrier prévu
Étape 1
Retirez les appels SDK Agones et le sidecar de la spécification de votre pod. Rien de propriétaire ne les remplace.
~2 heures
Étape 2
Votre serveur fonctionne déjà comme un conteneur, cette étape est donc un contrôle plutôt qu'un travail.
Déjà fait
Étape 3
Le registre d'Edgegap est disponible gratuitement, ou vous pouvez conserver celui que vous utilisez déjà.
~30 min.
Étape 4
Une seule requête de déploiement, associée à un webhook ou à une vérification d'état pour l'adresse, remplace le GameServerAllocation que votre backend crée actuellement.
~1 jour
Étape 5
Déployez à l'échelle mondiale sur Edge Cloud, et réduisez éventuellement encore vos coûts grâce à l'hébergement sans frais de sortie sur Private Fleets.
Déploiement instantané
Étapes de migration détaillées
Si vous exécutez Agones sur vos propres clusters et souhaitez bénéficier de la même orchestration sans avoir à l'exploiter, les étapes simples suivantes vous permettront d'être opérationnel en un rien de temps. Nos ingénieurs sont disponibles si vous souhaitez d'abord passer en revue votre configuration.
Avant de commencer, il est utile de bien comprendre ce qui s'intègre avec quoi. Edgegap est une API : votre backend envoie une requête de déploiement et reçoit l'adresse et le port une fois que le déploiement est prêt, par webhook ou en interrogeant son statut, et rien n'est ajouté au binaire de votre serveur de jeu. Il n'y a pas de SDK serveur ni de sidecar. Nous partons du principe que : vous exécutez actuellement Agones sur vos propres clusters Kubernetes, vous disposez d'un conteneur de serveur de jeu fonctionnel, et vous pouvez modifier l'appel d'allocation dans votre backend.
Edgegap ne requiert pas de SDK serveur pour s'intégrer. La première étape consiste à retirer le SDK Agones de votre serveur de jeu : la connexion au serveur du SDK, l'appel Ready() après le démarrage, la boucle de ping Health(), ainsi que les appels Allocate(), Reserve() et Shutdown() qui font passer le GameServer par ses différents états. Tout ce qui effectue une lecture via GameServer() ou WatchGameServer(), ainsi que tous les appels SetLabel() ou SetAnnotation() utilisés pour transmettre les métadonnées de match, sont également retirés. Le sidecar du SDK quitte la spécification du pod avec eux, tout comme AGONES_SDK_GRPC_PORT et AGONES_SDK_HTTP_PORT. Sur Edgegap, votre serveur lit ce dont il a besoin à partir des variables d'environnement injectées lors du déploiement, y compris son IP publique et son mappage de ports, et il est prêt pour les joueurs dès qu'il est en écoute. Les métadonnées de match qui transitaient auparavant sous forme de labels voyagent désormais sous forme de variables d'environnement dans la requête de déploiement.
Votre serveur de jeu fonctionne déjà en tant que conteneur, cette étape est donc une vérification plutôt qu'une reconstruction. Confirmez que l'image se construit et démarre sans le side-car SDK, puis poussez-la vers le registre gratuit d'Edgegap ou conservez le registre que vous utilisez aujourd'hui. Si vous avez construit un chemin de distribution d'images pour accélérer les téléchargements, comme l'ont fait de nombreuses équipes exploitant Agones à grande échelle, rien de tout cela ne vous accompagne : le téléchargement et le placement des images sont de notre ressort.
Agones - Fonctionnalités | Edgegap - Fonctionnalités |
|---|---|
SDK et sidecar Agones | Aucun SDK serveur. Ports et variables injectés lors du déploiement. |
GameServerAllocation | Un seul POST vers le point de terminaison de déploiement. Le FQDN et le port sont transmis via un webhook de déploiement ou par interrogation de l'état du déploiement. |
Fleet et GameServerSet | Applications et versions pour l'image, Private Fleets pour une capacité persistante. |
Dimensionnement des réplicas et de la mémoire tampon | Rien à dimensionner sur Edge Cloud (à la demande). Private Fleets redimensionnées chaque mois. |
FleetAutoscaler | Automatique. Bascule vers Edge Cloud lorsqu'une Private Fleet est pleine. |
RollingUpdate, maxSurge et maxUnavailable | Déploiement de version sur Applications et Versions, avec mises à jour progressives gérées automatiquement pour vous. |
Ordonnancement compacté ou distribué | Placement au moment de la requête, mesuré à partir du joueur. |
Allocation multi-cluster | Un seul point de terminaison. Aucune topologie d'allocateur à maintenir. |
Approvisionnement des nœuds, bin-packing et autoscaling de cluster | Géré par Edgegap. Aucun nœud à provisionner, dimensionner ou compacter, et la capacité s'adapte par déploiement sans autoscaler de cluster à ajuster. |
Registre d'images et chemin de distribution | |
Mises à niveau des versions de Kubernetes et d'Agones | Plateforme entièrement gérée pour votre compte |
Surveillance, journalisation et alertes pour la plateforme, sécurité | API Deployment Status, Webhook de déploiement, Analytique et surveillance des déploiements, support 24/7, protection contre les attaques DDoS. |
Travail de portage | Optionnel : connectez votre agent de codage au serveur MCP Edgegap. Il charge les compétences d'agent testées d'Edgegap et utilise votre image existante pour créer l'application et la version et déployer votre serveur, et chaque modification peut d'abord être prévisualisée sous forme de simulation. Il n'existe pas encore de compétence spécifique à Agones : la compétence API Deploy écrit l'appel d'allocation, et la compétence launch couvre la planification de la capacité avec Private Fleets. |
Les Private Fleets sont ce qui se rapproche le plus de la flotte que vous exploitez aujourd'hui : une capacité persistante et dédiée avec un hébergement sans frais de sortie (egress-free). La différence réside dans tout ce qui l'entoure. Il n'y a aucun réplica à ajuster, aucune politique de dimensionnement automatique (autoscaler) à rédiger, aucun nœud à provisionner ou à compacter (bin-pack), et aucun cluster à mettre à niveau. Vous redimensionnez la Private Fleet chaque mois, et tout ce qui dépasse bascule automatiquement sur Edge Cloud.
Prix
Découvrez comment l'orchestration d'Edgegap se compare au coût de fonctionnement de votre propre infrastructure.
Agones gère les pods GameServer, les Fleets et le FleetAutoscaler. Tout ce dont une plateforme a besoin d'autre est fourni par l'équipe qui opère l'auto-hébergement. Ce tableau est une liste de tâches, pas une grille tarifaire : c'est à vous de modéliser vos coûts d'ingénierie.
Tâche de plateforme | Agones auto-hébergé | Edgegap |
|---|---|---|
Approvisionnement, dimensionnement et bin-packing des nœuds | À votre charge | Géré par Edgegap. Aucun nœud à approvisionner, à dimensionner ou à organiser (bin-pack) |
Registre d'images et chaîne de distribution | À vous de les concevoir et de les exploiter | |
Mise en mémoire tampon de la capacité et politique d'autoscaling | À vous d'ajuster, par flotte, par cluster | Plusieurs stratégies à exploiter sur Edge Cloud, automatisées sur Private Fleets |
Mises à niveau de Kubernetes et d'Agones | À votre charge, sur une fenêtre de prise en charge de trois versions, dans chaque région | Plateforme entièrement gérée pour votre compte |
Supervision de la plateforme, alertes et astreinte (pager) | À votre charge | Outil d'analyse et de supervision approfondi, avec support 24h/24 et 7j/7 inclus |
Topologie d'allocation multi-cluster | À votre charge |
Ce que ce tableau ne couvre pas : le coût des opérations. Nous avons exécuté le calculateur tiers de coût total de possession de Deconstructor of Fun pour une adoption modeste d'Agones, et le résultat s'élève à environ 42 k$ pour l'intégration et 567 k$ sur trois ans pour le développement et la maintenance, la maintenance étant évaluée à 15 à 25 % du coût de construction annuel. La ligne la plus importante de ce modèle est le coût d'opportunité. Lisez la ventilation complète et ses mises en garde.
Le rôle récurrent d'un orchestrateur n'est pas le déploiement, mais le taux de remplissage. Avec Agones auto-hébergé, vous payez pour chaque nœud aussi longtemps qu'il fonctionne, et non pour les joueurs qui s'y trouvent.
Agones auto-hébergé | Edgegap | |
|---|---|---|
Montée en charge (Scaling up) | Par nœuds entiers. Franchir un seuil impose de payer pour une machine complète afin d'absorber le surplus | Par déploiement, fractionnable à partir de 0,25 vCPU |
Réduction de charge (Scaling down) | Attend que les sessions avec état se vident avant qu'un nœud puisse être libéré | Prend fin avec le match |
Tampon à chaud (Warm buffer) | Dimensionné pour couvrir le temps d'approvisionnement, et inactif par conception | Non requis sur Edge Cloud. Les déploiements sont approvisionnés à partir de zéro en 2 secondes, médiane, jusqu'au conteneur prêt |
Temps d'approvisionnement | Défini par l'approvisionnement du nœud et le téléchargement de l'image (image pull), raison pour laquelle les équipes opérant à grande échelle étendent Agones avec leur propre approvisionnement de nœuds et distribution d'images avant d'obtenir de bons chiffres | 2 secondes, médiane, à partir d'un démarrage à froid, sans rien à ajouter |
Facturation | Par nœud, aussi longtemps que le nœud fonctionne, que ses serveurs de jeu soient pleins ou vides | Par déploiement, à la minute sur Edge Cloud, et la facturation s'arrête à la fin du match. Private Fleets facture à l'heure |
Agones auto-hébergé | Edgegap | |
|---|---|---|
Calcul | Vos contrats cloud ou bare metal, à vos tarifs négociés | 0,00115 $ par vCPU par minute sur Edge Cloud, tarif unique mondial, ou 0,0261 $ par vCPU par heure sur Private Fleets |
Couverture | Les régions dans lesquelles vous avez mis en place des clusters | Plus de 615 emplacements Edge Cloud à la demande, avec chaque déploiement sur le meilleur emplacement disponible au moment de la demande, mesuré depuis le joueur |
Trafic sortant (Egress) | Selon les accords de votre fournisseur | Inclus sur Private Fleets |
Effet net à des milliers d'utilisateurs simultanés (CCU) | Le coût correspond aux ressources de calcul plus l'équipe de plateforme | 25 à 35 % de moins qu'un cloud pur avec une répartition hybride correctement optimisée. Modélisez-le dans le calculateur de prix |
Edgegap | Google Cloud | |
|---|---|---|
Orchestration | Orchestration hybride, aucun SDK de serveur de jeu requis : | Aucun service de serveur de jeu géré : l'URL de Game Servers de Google redirige désormais vers la page Cloud pour le développement de jeux, et sa bibliothèque client indique que « L'API Cloud Gaming est officiellement obsolète. » ; Google oriente les studios vers « Exécuter et dimensionner des serveurs de jeu dédiés sur GKE » avec le projet open source Agones, installé et exploité par le studio |
Infrastructure | Fournisseur unique : 43 régions et 130 zones Google Cloud (page des emplacements, mise à jour le 28 octobre 2026) ; les studios créent un cluster GKE régional ou zonal dans chaque emplacement qu'ils desservent | |
Matériel |
| Les nœuds GKE sont des instances de « machine virtuelle Compute Engine » ; types de machines choisis par le studio sur GKE Standard, ou gérés par Google sur Autopilot, où Agones présente des « contraintes prédéfinies et arrêtées » (pas de conteneurs Windows, demandes minimales de ressources pour les pods) |
Placement |
| Le studio choisit la région ou la zone du cluster ; Agones installe un service de ping pour que les clients puissent « déterminer à quel cluster se connecter en fonction de la latence » ; pour l'allocation multi-cluster, Agones recommande désormais « un maillage de services (Service Mesh) dans chacun de vos clusters Agones » |
Tarification | Frais de gestion de 0,10 $ par cluster et par heure, avec un crédit mensuel de 74,40 $ par compte de facturation ; Autopilot à 0,0445 $ par heure de vCPU plus mémoire (us-central1, à la demande) ; nœuds Standard facturés aux tarifs Compute Engine ; sortie Internet à 0,12 $ par Gio jusqu'à 1 Tio (Niveau Premium, de l'Iowa vers l'Amérique du Nord) | |
Évolutivité |
| Jusqu'à 65 000 nœuds par cluster GKE Standard et 5 000 par cluster Autopilot ; « Toutes les augmentations de quota de nœuds ne sont pas automatiques » ; aucun chiffre de test de charge ou de taux de déploiement de serveurs de jeu n'a été publié (au 4e trimestre 2026) |
Intégration |
| SDK client Agones requis : « Les SDK clients sont requis pour qu'un serveur de jeu fonctionne avec Agones », pour Unreal Engine, Unity, C++, C#, Node.js, Go, Rust, Python et REST ; matchmaking via le projet open source Open Match, mentionné dans la FAQ jeux de Google |
Support | 24/7 pour les clients, gratuit. Disponible sur Discord, Slack, e-mail | « L'assistance pour Game Servers est proposée dans le cadre de l'offre d'assistance Premium » (15 000 $ par mois minimum, 180 000 $ par an selon les calculs d'Edgegap) ; les tickets Agones sont traités sur GitHub et les canaux communautaires |
Latence | Réduction moyenne de 58 % par rapport au cloud public (étude de cas Edgegap) | Aucune mesure de latence publiée pour les serveurs de jeu sur GKE (au 4e trimestre 2026) ; les clients peuvent chronométrer le service de ping HTTP et UDP d'Agones |
Historique | Agones co-développé par Google et Ubisoft depuis 2017, cédé par Google à la CNCF (mars 2026) ; DeNA a été mentionné comme exploitant ses serveurs de jeu dédiés sur GKE (blog Google Cloud, mars 2023) |

Clients
15 études de cas sont disponibles auprès de studios qui ont migré vers Edgegap depuis une autre plateforme.

Migration d'un jeu LiveOps pour solutioner la charge de travail DevOps
Découvrez pourquoi le tireur d'extraction VR n°1 est alimenté par l'hébergement et l'orchestration de serveurs de jeu d'Edgegap.
Étude de cas

Serveurs persistants qui "scale" & améliorent l'expérience des joeurs
Découvrez comment The Isle a amélioré l'expérience de ses joueurs grâce aux déploiements mondiaux de serveurs persistants d'Edgegap.
Étude de cas

Un MMO cosy migré en quelques jours grâce à l’orchestration d’Edgegap
Comment Qloud Games a migré l’hébergement des serveurs de jeu de Loftia chez Edgegap en moins de 24 heures et a lancé une bêta avec des milliers de joueurs.
Étude de cas

Guerre VR à grande échelle : Triangle Factory lance Forefront 1.0 sur Edgegap
Comment Triangle Factory a migré son jeu de tir en VR le plus ambitieux vers Edgegap et a lancé sa version 1.0 complète en toute confiance.
Étude de cas

Du Peer-to-Peer aux combats équitables : Bloody Bastards sur serveurs dédiés
Comment Tibith Ltd a migré Bloody Bastards, un succès mobile, du peer-to-peer vers les serveurs dédiés et le matchmaking d'Edgegap, garantissant que chaque match soit géré côté serveur.
Étude de cas

Comment Noodlecake propose le mode multijoueur tout en oubliant l'existence des serveurs
Comment Noodlecake a migré Super Flappy Golf vers l'orchestration automatisée d'Edgegap et s'est recentré sur le développement du jeu.
Étude de cas

Breachers migre vers Edgegap
Comment Triangle Factory a adapté son jeu de tir VR compétitif en 5v5 à une infrastructure conçue pour la précision qu'exige ce genre.
Étude de cas

Comment Blue Duck utilise les Fleets d'Edgegap pour l'orchestration de son MMO
Découvrez comment Blue Duck Studios utilise l'API Fleets d'Edgegap pour orchestrer les serveurs de son jeu de football.
Étude de cas

1047 Games sur Edgegap : une migration et un lancement fluides
Comment 1047 Games a migré Splitgate: Arena Reloaded vers Edgegap et a lancé Empulse sur son orchestration, avec un hébergement resté fiable tout au long.
Étude de cas

De l'orchestration homebrew à 50 000 joueurs du jour au lendemain
Comment Slipstream Games a réduit ses coûts de serveur de 50%, a diminué son ping de 200-250 ms à 100-110 ms et a lancé sur CrazyGames atteignant 50 000 joueurs en 24 heures.
Étude de cas

De la flotte à la demande : des serveurs dédiés pour un jeu de scooters
Comment iScoot est passé à une orchestration à la demande basée sur des instances, aboutissant à des serveurs dédiés 10 fois plus petits en terme de modèle de coûts
Étude de cas

Triangle Factory migre Hyper Dash chez Edgegap
Comment un jeu de tir en VR gratuit reste rapide, mondial et rentable grâce à une infrastructure à la demande qui s'adapte à ses joueurs.
Étude de cas
Découvrez l’impact de l’orchestration automatisée des serveurs de jeu d’Edgegap pour une expérience multijoueur impeccable.
Méthodologie
Chaque métrique indique ce qui est mesuré, sur quelle période et ce qui est exclu. Les résultats de référence sont datés du test qui les a produits et ne sont pas reformulés en tant que chiffres actuels.
Où les serveurs peuvent fonctionner et combien nous en avons exploités.
Cibles de déploiement distinctes où un conteneur de serveur de jeu peut être planifié à la demande.
Emplacements où un studio peut réserver des hôtes Private Fleet pour son usage exclusif.
Nombre total de déploiements de serveurs de jeu orchestrés depuis février 2019, y compris les déploiements qui n'ont pas réussi à démarrer, selon la même méthode de calcul que nos concurrents.
La rapidité avec laquelle notre orchestration déploie un serveur, et ce qu'elle soutient en condition de test.
Démarrage à froid : provisionné à partir de zéro, et non alloué sur un serveur déjà en cours d'exécution. Mesuré jusqu'à ce que le conteneur soit prêt, avant le lancement du moteur de jeu.
Déploiements démarrés par seconde, en moyenne sur un test de référence continu de 60 minutes. C'est le taux standard pour chaque jeu des studios confirmés ayant du trafic en production ; des taux plus élevés sont disponibles sur demande.
Sessions simultanées atteintes sur de véritables conteneurs de serveurs de jeu, à raison de 100 joueurs par serveur.
Ce à quoi nous nous engageons contractuellement pour notre orchestration, et ce que les moniteurs enregistrent.
Garanti par notre SLA. Taux de disponibilité mesuré sur les 90 derniers jours : 99,999 %.
Fournisseurs de services cloud et de serveurs dédiés (bare-metal) sous contrat acheminant le trafic de production. Le basculement est automatique.
L'état des composants en direct est publié sur status.edgegap.com.
Une entrée par métrique : ce qui est mesuré, comment et sur quelle période.
Un emplacement correspond à une cible de déploiement distincte : un site de centre de données chez l'un de nos fournisseurs d'infrastructure, dans lequel un conteneur de serveur de jeu peut être planifié à la demande. Les sites ne sont comptabilisés qu'une seule fois, quel que soit le nombre de fournisseurs présents dans la même zone métropolitaine, et uniquement lorsqu'ils acceptent des déploiements.
Retour à la métrique ↑Comptabilisé séparément des plus de 615 emplacements Edge Cloud, qui correspondent à de la capacité cloud à la demande : un emplacement Private Fleet est un site où un studio réserve des hôtes pour son usage exclusif. Publié en direct sur la page Fleet Manager. Chaque hôte Private Fleet inclut 6 To de trafic sortant par mois.
Retour à la métrique ↑Comptabilisé comme le nombre total de déploiements enregistrés depuis février 2019, y compris les déploiements qui n'ont pas pu démarrer, selon la même méthode que celle utilisée par nos concurrents.
Retour à la métrique ↑Démarrage à froid : provisionné à partir de zéro, et non alloué sur un serveur déjà en cours d'exécution. Mesuré jusqu'à ce que le conteneur soit prêt, avant le lancement du moteur de jeu.
Retour à la métrique ↑L'orchestrateur a démarré de véritables conteneurs de serveurs de jeu en continu pendant 60 minutes, avec une moyenne de 40 déploiements démarrés par seconde sur l'heure complète, comptés au démarrage du déploiement plutôt qu'à l'état prêt. Mesuré sur plus de 550 sites et 17 fournisseurs en novembre 2023. Le test de référence a été réalisé pour un seul jeu. La capacité étant allouée par jeu, chaque jeu de la plateforme peut évoluer à ce niveau de manière indépendante et simultanée. 40 par seconde est le taux standard. Les studios qui ont besoin de plus peuvent planifier un taux plus élevé avec nous : lors d'un test de charge client en octobre 2026, les déploiements ont culminé à 70 par seconde, avec 85 en une seule seconde, via la même API et le même ordonnanceur de production que tous nos clients, sans impact mesurable sur les autres clients. Comment nous avons mené ce test.
Retour à la métrique ↑En novembre 2023, la plateforme a maintenu 40 déploiements de serveurs de jeu par seconde pendant 60 minutes, répartis sur plus de 550 sites et 17 fournisseurs, atteignant ainsi 14 millions de sessions simultanées à raison de 100 joueurs par serveur. Les serveurs de jeu étaient de véritables conteneurs ; les clients joueurs étaient simulés. Le benchmark a été réalisé pour un seul jeu. La capacité étant allouée par jeu, chaque titre présent sur la plateforme peut évoluer à ce niveau de manière indépendante et simultanée.
Retour à la métrique ↑La disponibilité est garantie à 99,99 % selon notre SLA et mesurée en continu sur cinq composants surveillés indépendamment : le registre de conteneurs, le tableau de bord, l'API publique, la documentation publique et le site Web. Le taux de disponibilité mesuré sur les 90 derniers jours s'élève à 99,999 %. Les données en direct sont publiées sur status.edgegap.com.
Retour à la métrique ↑Fournisseurs distincts sous contrat et acheminant le trafic de production, comptabilisés au niveau de l'entité juridique. Le basculement entre les fournisseurs est automatique ; c'est le principe fondamental de l'architecture multi-cloud.
Retour à la métrique ↑Ce qui est examiné, à quelle fréquence et ce qui a sa propre date.
Les chiffres de la plateforme présentés sur cette page sont examinés et actualisés chaque trimestre. Les indicateurs issus de sources en direct (disponibilité et déploiements de serveurs de jeu) comportent leur propre date de référence et sont mis à jour au fil des mesures. Les résultats des bancs d'essai sont datés du test dont ils sont issus et ne sont pas réactualisés en tant que données en temps réel.
Edgegap est l'expert de l'hébergement et de l'orchestration. Notre plateforme est conçue sur mesure pour vous aider à accélérer votre processus de développement, ce qui vous permet de vous concentrer sur ce dans quoi vous excellez : le développement.
Ce n'est pas le cas, et la raison en est l'artefact. Ce que vous poussez est une image de conteneur standard qui ne contient aucun de nos éléments : pas de SDK serveur, pas de sidecar, pas d'appels de cycle de vie dans votre binaire. La même image s'exécute partout où un conteneur est accepté, qu'il s'agisse de votre propre cluster si vous le remontez ou d'un autre fournisseur tiers, et la seule intégration que vous auriez à défaire est un simple appel HTTP dans votre backend. La flexibilité pour laquelle vous avez gardé Agones reste également à vos côtés du côté de l'orchestration. Réservez de la puissance de calcul qui n'appartient qu'à vous avec Private Fleets, dans les emplacements de votre choix, ou exécutez sur un Edge Cloud multi-tenant avec vCPU et mémoire réservés et payez pour les déploiements que vous utilisez réellement, ou séparez les deux et déplacez la ligne dès que votre trafic évolue. Vous décidez où les serveurs s'exécutent et comment ils se mettent à l'échelle. Ce que vous transférez, c'est l'exploitation, pas le contrôle.
Des flottes privées, pour une capacité qui reste la vôtre : du bare metal dédié avec un hébergement sans frais de sortie (egress), dimensionné mensuellement plutôt qu'ajusté avec des réplicas et des politiques d'autoscaling. L'orchestration hybride les associe à l'Edge Cloud pour préserver la rentabilité de l'hébergement, sans rien à configurer : lorsqu'une Private Fleet est pleine, les déploiements basculent automatiquement sur l'Edge Cloud, chacun créé pour le match qui en a besoin, provisionné à partir de zéro en 2 secondes, valeur médiane, mesurée jusqu'à ce que le conteneur soit prêt, avant le démarrage du moteur de jeu. La marge tampon que vous conservez aujourd'hui pour couvrir le temps de provisionnement n'est plus nécessaire, ce qui représente également une grande partie des économies réalisées.
Ils s'en vont et rien de propriétaire ne les remplace. Ready(), Health(), Allocate(), Reserve() et Shutdown() disparaissent tous, tout comme le sidecar SDK dans les spécifications du pod et les variables de port GRPC et HTTP qu'il utilisait. Sur Edgegap, votre serveur lit son adresse IP publique et son mappage de ports à partir des variables d'environnement lors du déploiement, et il est prêt dès qu'il est à l'écoute. Les métadonnées de match que vous transportiez sous forme de labels ou d'annotations se transforment à la place en variables d'environnement lors de la demande de déploiement.
Tout converge vers un seul endpoint. Aujourd'hui, vous gérez des clusters dans chaque région, un allocateur placé devant eux, et une politique définissant quel cluster traite une requête. Avec Edgegap, vous envoyez une seule requête de déploiement contenant l'emplacement des joueurs, et celle-ci est assignée au meilleur emplacement disponible sur le réseau au moment de la demande. Il n'y a aucune topologie à maintenir, aucune politique inter-clusters à synchroniser, et aucune capacité par région à provisionner avant que la demande ne survienne. Si vous souhaitez disposer de capacité à des endroits spécifiques, c'est exactement le rôle des Private Fleets : du bare metal aux emplacements de votre choix, avec un débordement automatique vers l'Edge Cloud plutôt que vers un autre cluster vous appartenant.
Rien que sur le calcul, nous sommes extrêmement compétitifs, et vous pouvez le comparer à vos propres tarifs plutôt que de nous croire sur parole. Edge Cloud est à 0,00115 $ par vCPU et par minute, fractionnable à partir de 0,25 vCPU, à un tarif unique dans le monde entier, et les Private Fleets sont à 0,0261 $ par vCPU et par heure avec un hébergement sans frais de sortie (egress). Si vos tarifs cloud actuels sont proches des prix catalogue, l'écart est généralement considérable. Si vous avez bien négocié, la tarification au volume réduit cet écart et continue de diminuer à mesure que vous grandissez. Plus difficile à intégrer dans un tableur, mais généralement bien plus précieux : l'orchestration hybride permet de préserver la rentabilité de votre hébergement en combinant des Private Fleets bare metal avec Edge Cloud, et vous rééquilibrez les deux dès que votre trafic évolue, au lieu de payer toute l'année pour la capacité de pointe. Vient ensuite ce que vous cessez de maintenir. Votre intégration est déjà en place, ce coût appartient donc au passé, mais pas la maintenance. Une référence du secteur estime la maintenance continue entre 15 et 25 % du coût de développement initial par an, sans compter les travaux d'évolution qu'implique chaque nouvelle région, plateforme ou version de moteur. L'autoscaling, les analyses et le monitoring sont intégrés à la plateforme, ce qui permet d'optimiser les coûts et les performances directement depuis un tableau de bord plutôt que dans vos sprints. Modélisez votre propre trafic dans le calculateur de prix.
Oui, et plus que ce que vous pourriez imaginer. Vous conservez l'image de votre serveur de jeu et votre code réseau intacts. Vous gardez votre backend et le modèle d'allocation que vous avez conçu : une requête reçue, une adresse et un port renvoyés. Et vous conservez la capacité qui vous appartient, dans les emplacements de votre choix, grâce aux Private Fleets, ce qui est la partie de l'auto-hébergement qui mérite le plus d'être préservée : prévisible, dédiée et sans frais de transfert de données. Ce que vous ajoutez, c'est un orchestrateur que vous n'avez pas besoin de concevoir ni de maintenir, qui déploie déjà chaque jour des serveurs de jeu pour plus de 1 600 studios, et qui est amélioré à nos frais plutôt qu'aux vôtres. En général, les équipes commencent par orienter une région vers Edgegap et la faire tourner en parallèle de leur cluster existant pendant une semaine, puis transfèrent le reste une fois que tout se passe sans incident. Rien n'impose une transition brutale.