Voisin bruyant
Un voisin bruyant (noisy neighbour) est un autre locataire sur un matériel partagé dont la charge peut ralentir votre charge de travail lorsque l'hôte n'impose pas à chaque locataire ses propres limites. Dans l'hébergement de jeux, c'est l'argument le plus souvent avancé pour migrer les serveurs vers des machines entières : matériel propre, serveurs dédiés (bare metal) loués ou instances cloud d'hyperscaleurs. Sur un hôte de conteneurs qui applique des budgets de processeur et de mémoire, chaque serveur de jeu conserve les ressources qui lui ont été attribuées : un voisin qui dépasse son budget est bridé ou arrêté, et seule sa propre partie est affectée.
Aussi appelé
voisin bruyant
,
Le problème du voisin bruyant est-il exclusif au cloud partagé ?
Le problème des voisins bruyants est généralement invoqué pour abandonner les ressources partagées au profit de machines dédiées. Certains fournisseurs de serveurs dédiés (bare metal) en font le cœur de leur argumentaire : « Pour un serveur de jeu, un voisin bruyant peut provoquer des pics de décalage inexplicables, des taux de rafraîchissement (tick rates) plus lents et un gameplay incohérent » (Hivelocity, décembre 2025).
Cet argument omet un détail. Un hébergeur de serveurs de jeu gère rarement une seule partie. Une machine dédiée dotée de dizaines de cœurs exécute souvent des dizaines de parties côte à côte, et chacune d'elles est un voisin pour les autres. Le studio possède l'ensemble de ces parties, mais la congestion qu'il cherchait à fuir est toujours présente sur la machine, provenant cette fois de sa propre partie la plus active.
La question n'est donc pas de savoir si un hôte est partagé. Chaque flotte orchestrée partage ses hôtes, même lorsqu'un seul studio possède l'ensemble de la capacité. La question est de savoir si chaque serveur de l'hôte respecte son propre budget de ressources.
Un voisin bruyant peut-il ralentir votre serveur de jeu ?
Pas sur un hôte de conteneur qui impose des limites, quel que soit le voisin, y compris votre propre studio. Lorsqu'un serveur de match démarre, il reçoit un budget de processeur (CPU) et de mémoire, et le noyau de l'hôte maintient chaque conteneur au sien par le biais de groupes de contrôle (documentation Docker).
Processeur (CPU). Un voisin qui tente d'utiliser plus que sa part est limité à sa propre limite. Il ne peut pas s'approprier le processeur attribué à votre serveur.
Mémoire. Un voisin qui dépasse sa limite de mémoire est arrêté. Son match se termine ; le vôtre continue de tourner.
Pour un serveur de jeu, le budget qui importe est le temps par tick. Un serveur de 128 Hz dispose d'environ 7,8 millisecondes pour terminer chaque tick. Avec une allocation imposée, cette fenêtre dépend du budget et du code de votre propre serveur, et reste la même quel que soit le reste de ce que l'hôte exécute.
Ainsi, si le temps de tick augmente sous la charge, le premier endroit où regarder est la limite de votre propre serveur : une allocation de processeur définie avant la dernière mise à jour du contenu, ou une limite de mémoire dimensionnée pour un match moyen plutôt que pour un match complet. La section Colocation traite de son dimensionnement.
Combien cela coûte-t-il d'éviter les voisins ?
Passer à des machines dédiées ne supprime pas les voisins ; cela en fait simplement les vôtres. Ce que cela change, c'est la facture :
Capacité inutilisée. Une machine réservée est payée entre les pics d'activité, la nuit et après la semaine de lancement. Le calcul des heures pleines sur serveur dédié physique (bare metal) s'applique.
Moins de localisations. Chaque région ajoutée signifie une autre machine dimensionnée pour votre propre pic d'activité. Ainsi, les studios qui conservent des machines dédiées ont tendance à desservir moins de régions, et davantage de joueurs se connectent de plus loin.
La capacité partagée et orchestrée répartit ces deux coûts sur chaque jeu qui l'utilise, tout en maintenant chaque serveur dans les limites de son budget. L'Edge Cloud d'Edgegap exécute chaque serveur de jeu dans son propre conteneur avec des limites strictes de processeur et de mémoire, de sorte que la charge d'un voisin reste dans le budget de ce voisin. Il fonctionne dans plus de 615 localisations réparties chez plus de 17 fournisseurs d'infrastructures, facturé à 0,00115 $ par vCPU par minute (données de la plateforme, 18 septembre 2026).
Est-ce que les plus grandes flottes partagent des hébergeurs ?
Oui. Dans le système Borg de Google, 98 % des machines au sein des cellules partagées exécutent côte à côte des tâches de production et de traitement par lots (batch), chaque tâche se trouvant « au sein d'un conteneur de ressources basé sur les cgroups Linux », et les tâches sensibles à la latence peuvent réserver des cœurs de processeur physique entiers (Verma et al., EuroSys 2015).
Heracles, également développé par Google, exécutait des services critiques en matière de latence, notamment la recherche web, sur des hôtes partagés avec des tâches de traitement par lots. Il a atteint des « taux d'utilisation moyens des serveurs de 90 % sans violation des limites de latence dans l'ensemble des scénarios de charge et de colocalisation » (Lo et al., ISCA 2015).
Un mot de notre sponsor (nous-mêmes !)
Une région est une supposition quant à l'endroit où se trouveront vos joueurs. L'Edge Cloud d'Edgegap est un réseau distribué et multi-cloud de plus de 615 emplacements répartis sur plus de 17 fournisseurs, disponible sur demande. Chaque serveur se lance au meilleur emplacement disponible sur le réseau au début du match, et non dans la région la plus proche parmi une poignée d'options.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
L'isolation est le produit
Nous déployons quotidiennement des serveurs de jeux pour des millions de joueurs (chiffre interne Edgegap, T3 2026), avec 135 millions de déploiements depuis février 2019 (données de la plateforme, 18 septembre 2026). Chaque serveur fonctionne dans la limite de son propre budget de processeur (CPU) et de mémoire, sur des hôtes partagés avec d'autres matchs et les jeux d'autres studios. Un voisin ne peut pas s'approprier ce budget ; sa charge s'arrête à la sienne.
Ainsi, lorsqu'un studio nous signale qu'un match a subi des saccades sous la charge, nous examinons d'abord le budget de ce serveur. Un temps de cycle (tick time) fluctue généralement à cause d'une limite de mémoire calibrée pour un match calme, ou d'une allocation de processeur définie avant une mise à jour de contenu.
Le partage est ce qui permet de rapprocher les serveurs d'un petit jeu de ses joueurs, avec une facturation à la minute. L'isolation est ce qui permet à chaque match de rester indépendant, avec un impact nul sur tous les autres jeux utilisant l'orchestration d'Edgegap.
,
