À trois heures du matin, mon téléphone portable a soudain vibré comme un fou. Lorsque je l'ai saisi, hébété, j'ai vu que les SMS de surveillance et d'alerte s'étaient accumulés à plus de vingt reprises - la nouvelle version du jeu venait d'être mise en ligne, l'effet promotionnel dépassait largement les attentes, et le trafic instantané avait directement rempli la bande passante. Du côté de la salle des serveurs, le taux d'utilisation des ports du commutateur principal a grimpé à 98%, les joueurs ont commencé à chuter massivement, les forums et les appels au service clientèle ont instantanément explosé. J'ai copié l'expansion de la capacité d'urgence de l'ordinateur, tout en maudissant dans mon cœur : ces jours-ci, ne craignez pas que personne ne joue au jeu, par peur d'avoir soudainement trop de joueurs, les minutes du serveur pour vous apprendre à être une personne.
Ce scénario de montagnes russes du trafic n'est que trop courant dans l'industrie du jeu. Les mises à jour de versions, les activités populaires, les ancres avec des marchandises, ou même la popularité soudaine d'une plateforme sociale peuvent instantanément multiplier le nombre de visites par plusieurs fois, voire des dizaines de fois. Le schéma traditionnel de défense de la bande passante fixe est comparable à la mise en place d'un portail à largeur fixe pour un carrefour à grande vitesse - généralement suffisant, mais au moment des vacances, il est directement bloqué dans un parking. De plus, un grand nombre d'attaques DDoS choisissent spécialement ce type de période de pointe commerciale, mélangée au trafic normal, pour frapper par-dessus, ce qui ne fait qu'ajouter aux difficultés.
Pourquoi tant de sociétés de jeux sont-elles victimes de pics de trafic ? Le problème fondamental réside dans la rigidité de la planification des ressources et le manque d'élasticité. Afin de contrôler les coûts, de nombreuses équipes n'achètent de la bande passante qu'en fonction du trafic moyen, et la valeur de défense est également fixée en fonction de l'ampleur des attaques régulières. En cas de trafic inattendu, le processus d'expansion manuelle est long : approbation, contact avec le fournisseur pour ajuster, test de ...... et ainsi de suite, tout est fait, et les joueurs sont depuis longtemps à court. J'ai moi-même subi cette perte, au début des années pour faire le tour de la page, un pic de trafic d'activité de service, de la découverte à l'expansion de la capacité à compléter a passé près de 20 minutes, après la fin de l'examen des données d'activité, a perdu tout un 37% d'utilisateurs payants potentiels.
La mise à l'échelle automatique de la bande passante élastique est la bonne solution. Pour parler franchement, le CDN est équipé de capacités de détection intelligente et de mise à l'échelle automatique - le trafic normal avec la bande passante de base pour économiser de l'argent, une fois la détection d'un trafic inattendu ou d'attaques, le système augmente automatiquement la capacité à la demande, puis réduit automatiquement la capacité après le pic. Le point clé est “automatique”, sans intervention humaine, la vitesse de réponse est de quelques secondes. J'ai testé, à partir du seuil de déclenchement de l'anomalie de trafic jusqu'à l'expansion effective, le délai réel peut être contrôlé dans les 10 secondes, ce qui permet de protéger l'expérience du joueur et de faire la différence entre la vie et la mort.
Toutefois, pour parvenir à une véritable expansion de l'élasticité, le concept seul ne suffit pas, il faut des solutions techniques spécifiques. L'essentiel doit porter sur trois liens : des algorithmes précis de surveillance du trafic, un mécanisme transparent de programmation de la bande passante et un modèle de facturation raisonnable. Le niveau de surveillance ne peut pas se limiter à l'utilisation globale de la bande passante, il doit être combiné au nombre de requêtes par seconde, au nombre de connexions simultanées, à la fréquence d'accès à des URL spécifiques et à d'autres indicateurs multidimensionnels, faute de quoi il est facile de se tromper - par exemple, le téléchargement de paquets de correctifs peut faire exploser la bande passante, mais le nombre de requêtes n'est pas très élevé, et les attaques CC peuvent ne pas avoir une bande passante élevée, mais le nombre de requêtes peut exploser. Un bon système doit être capable de faire la différence entre les pics d'activité et le trafic d'attaque, ce qui nécessite des modèles d'apprentissage automatique pour effectuer une analyse comportementale.
Le mécanisme de planification varie considérablement d'un fournisseur de CDN à l'autre. L'approche de CDN5 est basée sur le réseau BGPanycast pour effectuer une charge globale, planifiant automatiquement le trafic vers le pool de nœuds redondants lorsque la capacité augmente, les ressources de bande passante sont partagées, une forte élasticité, mais le coût est élevé.CDN07 est prédéfini avec un canal de bande passante de réserve, déclenché par un seuil pour changer rapidement la ligne, très rapide, mais il y a une limite supérieure à la capacité du 08Host's solution est plus alternative, ils utilisent une sorte de modèle de collaboration d'élasticité de nœud de bordure, à travers le protocole P2P entre les nœuds pour allouer temporairement la bande passante, le coût est faible mais la complexité est élevée. La solution de 08Host est plus alternative, elle utilise une sorte de modèle de collaboration avec élasticité des nœuds, à travers le protocole P2P entre les nœuds pour allouer temporairement la bande passante, un coût faible mais une complexité élevée. Le choix de la solution dépend des caractéristiques de votre entreprise et de votre budget.
La méthode de facturation doit être demandée clairement ! Certains fournisseurs parlent d'expansion flexible de la capacité, mais en fait, il s'agit d'un modèle de facturation de pointe - selon les frais de pointe de la bande passante la plus élevée du mois, en cas d'attaque sur la brosse d'un chiffre astronomique, la facture peut être effrayée par une crise cardiaque. Ne croyez pas la vague propagande du “pay-as-you-go”, et assurez-vous d'écrire dans le contrat s'il s'agit d'une facturation à 95 ou d'une facturation mensuelle de pointe. Je recommande vivement d'utiliser le modèle de facturation 95 (valeur de la bande passante mensuelle, du plus élevé au plus bas, en supprimant les 5% les plus élevés et en prenant le maximum), ce qui permet de profiter de la flexibilité et d'éviter la faillite due à l'explosion du trafic.
La configuration de l'atterrissage n'est en fait pas compliquée, les étapes clés sont à suivre. La première est le réglage du seuil - un seuil trop bas permet d'augmenter par erreur la capacité et d'accroître les coûts, un seuil trop élevé fait perdre l'importance de la protection. Il est généralement recommandé de fixer le seuil de base à 1,5 fois le pic quotidien, et le seuil d'urgence à 2,5 fois. Deuxièmement, en ce qui concerne la granularité de l'expansion, il est préférable d'utiliser une expansion par étapes, et de ne pas tirer vers le haut en une seule fois. Par exemple, on commence par augmenter le débit de 50 Gbps, on observe pendant 5 minutes si le trafic continue d'augmenter, puis on poursuit l'augmentation, afin d'éviter le gaspillage des ressources. Enfin, nous devons définir les conditions de réduction de la capacité. En général, le trafic repasse en dessous du seuil et se stabilise pendant 15 à 30 minutes après le début de la réduction automatique de la capacité.
Donnez un exemple de configuration réelle d'une solution de connaissance du trafic basée sur l'implémentation de Nginx+Lua :
N'oubliez pas d'intégrer l'API de votre fournisseur de CDN. Aujourd'hui, les principaux fournisseurs proposent de riches interfaces ouvertes, comme l'API d'expansion de 08Host, qui peut être déclenchée directement par curl :
Lors du déploiement, je suggère d'utiliser une stratégie à plusieurs niveaux. Habituellement, utiliser 08Host comme protection de base, rentable ; rencontrer des activités à grande échelle à l'avance pour permettre la résilience de la protection CDN5 ; réellement par une attaque à grande échelle et ensuite déclencher le mode de protection d'urgence de CDN07. Cette combinaison d'utilisation, de coût et de performance de sécurité permet d'atteindre le meilleur équilibre. L'année dernière, notre jeu s'est engagé dans des événements mondiaux d'e-compétition, afin de porter le moment d'ouverture à 2,3 millions de joueurs en même temps que l'impact de l'afflux, l'ensemble du processus sans décalage.
Il y a aussi une petite astuce : dans l'expansion automatique de la capacité basée sur l'ajout d'un bouton d'urgence manuel. Nous avons créé une fonction d'expansion en un clic dans le backend Ops, et le bouton a été rendu très grand et rouge, avec les mots “Press with caution !” écrits sur le côté. --Qui a le temps de chercher le menu caché en cas d'urgence ? Je n'ai appuyé sur ce bouton que deux fois en trois ans, mais à chaque fois, il m'a sauvé la vie.
Une dernière remarque : la mise à l'échelle élastique n'est pas une panacée. Elle résout le problème des ressources en bande passante, mais si votre application elle-même présente un goulet d'étranglement en termes de performances - par exemple, le pool de connexions à la base de données n'est pas suffisant, la conception du cache n'est pas bonne, le code est inefficace - cette augmentation de la bande passante ne peut pas vous sauver. C'est comme une autoroute élargie à 100 voies, mais la sortie n'est qu'une voie étroite, l'obstacle est toujours bloqué. Ainsi, dans le CDN élastique, la première application avant l'optimisation doit faire du bon travail, sinon c'est une perte d'argent.
La réalité est cruelle : les joueurs ne vous donneront jamais de seconde chance. Si vous laissez tomber la ligne une fois, vous risquez de perdre un utilisateur pour toujours. Maintenant que notre système a pleinement réalisé l'expansion automatique élastique, nous pouvons enfin dormir sur nos deux oreilles. Après tout, mettre la technologie au service des gens, plutôt que de laisser les gens éteindre des incendies tous les jours, c'est la meilleure façon de faire de la technologie.
