Fortes charges de la Coupe du monde 2018


La dernière Coupe du Monde de la FIFA 2018 en Russie a apporté de lourdes charges non seulement aux pôles de transport du pays, mais également à l'infrastructure informatique du plus grand diffuseur russe, qui a rendu les matchs disponibles sous forme de diffusion en ligne. Nous avons relevé avec intérêt un nouveau défi qui est venu aux serveurs desservis avec la fièvre du football.

Avant-propos: des charges élevées?


Les conversations sur la charge élevée commencent souvent par des réflexions sur le sujet, quelles charges peuvent à juste titre être considérées comme «élevées»: des milliers de requêtes par seconde pour la dynamique? Ou même un petit nombre de demandes par rapport aux ressources disponibles? Des millions de visiteurs par jour? Des centaines de nœuds de charge de travail dans un cluster? ..

Pour se faire une idée de "l'ampleur de la catastrophe", le fait que nous parlions d'utilisateurs visionnant simultanément l'émission, dont le nombre a atteint la barre des 2 millions , devrait suffire. Que s'est-il passé si vous regardez les retransmissions de matches «de l'intérieur», et comment avez-vous réussi à faire face à un trafic sans précédent?

Trois baleines


1. Architecture du site et systèmes de traduction


Le schéma général d'interaction entre l'utilisateur final et le système de traduction est réduit au schéma suivant:

  • L'utilisateur vient sur le site où le lecteur est lancé pour regarder la vidéo. Le lecteur lui-même est écrit en JavaScript et son chargement entraîne de nombreuses demandes de statistiques, ainsi que diverses API liées aux traductions.
  • Entre autres choses, il y a un appel à l'équilibreur pour une liste de lecture à lire.
  • Une liste de lecture est un ensemble constamment mis à jour de courts fragments vidéo qui sont mis en cache sur les serveurs CDN.
  • Lorsque vous regardez la vidéo d’un utilisateur en temps réel, diverses statistiques sont collectées, qui sont notamment prises en compte pour l’équilibrage de charge par CDN (ainsi que la bande passante disponible réelle).

L'architecture de distribution directe de la vidéo a été conçue et mise en œuvre par les forces internes des ingénieurs du client avant même le début de notre coopération. Plus tard, en plus du service lui-même, nous avons été engagés dans la conception et la mise en service de l'infrastructure de certains de ses composants, ainsi que du site lui-même, qui joue un rôle important dans le schéma global.

Le site, lancé en production il y a plusieurs années, est axé sur l'évolutivité horizontale - y compris de nombreux centres de données:



Le schéma présenté ici est simplifié et vise à démontrer la nature de l'évolutivité du site, dont les composants sont répartis sur différents centres de données.

2. CDN


Revenant à regarder réellement la vidéo, il est évident que la charge principale tombe sur les serveurs CDN. Dans les chiffres de la dernière Coupe du monde, nous parlons d'un trafic constant, mesuré en térabits par seconde . Et à bien des égards, le succès du travail de traductions avec des pics de charge est dû à la mise en cache sur le CDN de tout ce qui peut leur être transféré, et à la minimisation des coûts de ressources (réseau, CPU, RAM, ...) d'autres opérations.

De plus, un point important dans le travail avec CDN est l'interaction avec leur API pour obtenir des informations pertinentes sur la bande passante totale et disponible. Dans le système de diffusion, ces données sont utilisées pour distribuer de nouveaux téléspectateurs et redistribuer les actuels.

Donc, si les serveurs CDN peuvent fournir suffisamment de bande passante à des millions de téléspectateurs Internet, alors quand des problèmes peuvent-ils se produire? Pendant le championnat, nous avons observé deux scénarios principaux:

  1. Pour une raison quelconque, il y a un décalage dans la diffusion.

    Par exemple, les paramètres du système ont tellement «joué» lors d'un match de championnat que le service de protection DDoS, qui ne s'attendait pas à une charge soudaine, a commencé à considérer ce qui se passait comme une attaque, bloquant la disponibilité des serveurs CDN l'un après l'autre ... jusqu'à ce qu'il soit informé que la situation était dans un sens extrême, mais toujours à plein temps (les conclusions nécessaires ont été tirées - dans les émissions suivantes, la situation ne s'est pas répétée).

    À de tels moments, tous les utilisateurs qui sont dépassés par un problème massif commencent à rafraîchir la page avec le lecteur.
  2. Un but marqué (en particulier le premier), en règle générale, provoque un afflux énorme de spectateurs dans un laps de temps limité.

    Si nous parlons de chiffres plus spécifiques, un tel afflux s'est élevé à des centaines de milliers d'utilisateurs en 1-1,5 minutes.

Ces deux cas ont généré de fortes pointes dans les demandes de contenu de site dynamique qui devaient être gérées par les ressources disponibles. Comment ces problèmes ont-ils été suivis et résolus?

3. Surveillance et statistiques en temps réel


Il est possible de plaisanter avec un degré de vérité significatif que pendant toute la durée du championnat, nous avons eu un poste spécial, dont les tâches comprenaient l'observation attentive du football sur le lieu de travail. Bien sûr, il ne s'agissait pas tant du football en tant que tel, mais de la réaction rapide à tout incident provoqué par des matches ou d'autres circonstances ...

Quelles sont les «autres circonstances»? Lors de tels événements publics, même l'influence de la météo est perceptible. Voici deux exemples du championnat que nous avons rencontré:

  1. Lorsqu'un orage a commencé pendant l'un des matches, les fournisseurs de télévision par satellite ont eu des problèmes d'équipement (ils n'ont pas pu envoyer de signal). Cela a entraîné une augmentation sensible du trafic (environ 10%) en peu de temps, car à la recherche d'une solution alternative urgente, les téléspectateurs ont commencé à se connecter massivement en ligne et à continuer à y naviguer.
  2. Quand il a commencé à pleuvoir pendant le match final, un petit saut (environ 3%) dans la déconnexion et la reconnexion des utilisateurs (après environ 5 minutes) était perceptible. Dans ce cas, aucun problème n'a été observé dans l'émission elle-même, c'est-à-dire que les raisons du saut n'avaient pas de base technique. L'hypothèse est que les spectateurs qui ont regardé le football dans la rue (comme moi-même) sont entrés dans la salle à cause de la pluie, et pendant cette brève période, ils ont été déconnectés de l'émission.

Revenant au sujet de la surveillance elle-même - pendant toute la durée du championnat, la pratique de réunions régulières (après chaque diffusion de pointe) a été prise comme norme avec les développeurs, qui ont analysé toutes les situations critiques (ou proches de celles-ci) et leurs conséquences - afin de minimiser les problèmes potentiels dans la prochaine fois. Quels serveurs / services étaient à la limite? Quelles requêtes étaient particulièrement exigeantes? Quelles demandes peuvent être supprimées (transférées sur CDN pour mettre en cache pendant quelques secondes)? Quelles demandes peuvent être mises en cache plus longtemps (toutes les 3 minutes, pas par minute)? Que se passera-t-il avec l'augmentation prévue du nombre de téléspectateurs, car la Russie jouera? ..

En parlant de Russie. Comme vous pouvez le deviner, en moyenne plusieurs fois plus de personnes sont venues aux matches avec l'équipe nationale russe que les autres. Et plus notre équipe montait dans le classement du tournoi, plus il était difficile de combiner notre joie dans cette affaire avec l'exécution de tâches immédiates - parce que tout était compliqué par la croissance inlassable du public. Malgré le fait que le système a été conçu pour supporter des charges énormes, dans le cadre d'un horaire de travail normal, elles ne se produisent pas si souvent (moins de 10 fois par an) ... et dans le cas de la Coupe du monde, nous avons observé des pics de charge presque quotidiens pendant un mois. L'avantage de ce mode, cependant, était les larges possibilités de détection de goulots d'étranglement réels qui ne sont détectés qu'aux moments de telles charges.

Donc, si une partie des problèmes purement techniques a été supprimée par les graphiques standard des systèmes de surveillance, alors dans la solution de problèmes plus complexes et / ou orientés vers la logique métier, les réalisations du projet sous le nom interne parlant de "statistiques en temps réel" ont joué un rôle important.

Statistiques en temps réel


Cette composante importante de l'infrastructure de diffusion Internet a été conçue et mise en œuvre par nos efforts pour fournir un outil de veille stratégique pour les données techniques collectées auprès des joueurs dans lesquelles les utilisateurs regardent des vidéos. À la base, c'est un système de journalisation qui:

  • recueille toutes sortes de données disponibles sur les utilisateurs (navigateur, IP, etc. - pour simplifier, nous pouvons dire que ce sont les caractéristiques que nous avons utilisées pour examiner les statistiques sur l'audience du site);
  • les complète avec des données techniques sur la diffusion (débit binaire, etc.) et les événements / problèmes survenus (commutation CDN, pannes de visualisation ...);
  • fournit à l'équilibreur des données pour un équilibrage de charge optimal sur les serveurs CDN (en fonction des caractéristiques de chaque utilisateur);
  • envoie les alertes nécessaires aux ingénieurs de garde et crée des graphiques commerciaux utiles.

Le dernier point est le plus intéressant, car:

  1. Les alertes de ce système de statistiques sont un élément clé du suivi qui vous permet de vous «tenir au courant» des indicateurs pratiques lors des diffusions. En les analysant (dans un lieu où l'automatisation ne suffit pas), le préposé prend les décisions appropriées pour améliorer la qualité de service en temps réel. Par exemple:
    • De nombreux utilisateurs sont-ils passés du même serveur CDN? Il doit être temporairement désactivé de la rotation (ou contactez le fournisseur pour une réponse rapide).
    • Les utilisateurs ont-ils commencé à rencontrer d'énormes problèmes pour regarder des vidéos? Il est temps d'analyser d'urgence les causes.
  2. Les graphiques sont des statistiques commerciales en temps réel qui vous permettent de répondre à des questions clés, telles que:
    • Combien d'utilisateurs ont regardé la diffusion de dernière minute?
    • Quel pourcentage d'utilisateurs a eu des problèmes à la dernière minute et quelle était leur nature?

    Étant donné que des événements similaires ont le même profil de graphique, le graphique lui-même vous permet de prédire la croissance du nombre d'utilisateurs au cours des prochaines minutes et de prendre des mesures proactives si nécessaire.

Étant donné que ces statistiques fonctionnent en temps réel et sont essentielles pour la qualité de l'ensemble du service, même la simple visualisation de vidéos par nature par des millions d'utilisateurs ne se résume pas à leur distribuer du contenu via CDN. Le SGBD ClickHouse permet d'obtenir un enregistrement rapide des nouvelles données de nombreux joueurs (nous parlons de dizaines de milliers de requêtes par seconde pour l'enregistrement sur chaque serveur), et le Grafana habituel est utilisé pour les graphiques.


Illustration du ratio de téléspectateurs de la vidéo en ligne avant, pendant et après le match

Soit dit en passant : une solution de contournement intéressante lors des pics de charge consistait à désactiver HTTPS (en faveur de HTTP) pour les demandes du système de statistiques, ce qui a entraîné une double réduction de la charge du processeur sur certains serveurs.

Résumé


Le succès des diffusions en ligne d'un événement d'une telle ampleur (même YouTube TV n'a pas toujours fait face aux charges!) A été fourni par trois facteurs clés:

  1. architecture compétente (pour le système de diffusion et le site), qui, même sans l'utilisation de systèmes modernes comme Kubernetes, était initialement orientée vers des charges élevées, une évolutivité et une disponibilité pour des rafales importantes;
  2. Serveurs CDN avec une bande passante suffisante;
  3. une surveillance spécialisée qui a permis: a) de suivre les problèmes en temps réel, b) de fournir les informations nécessaires pour les éviter à l'avenir.

Bien qu'il y ait en fait plus de facteurs ... et l'un d'entre eux, peut-être, est capable de dépasser tous les facteurs techniques - humains. Le rôle le plus important a été joué par des spécialistes qui ont non seulement réussi à faire et à lier tout ce qui est nécessaire sur le plan technique, mais aussi à obtenir inlassablement des résultats, ce que je tiens particulièrement à souligner les mérites de la gestion du client.

PS sur les Kubernetes mentionnés ... une histoire que de nombreux lecteurs de notre blog s'attendaient à voir. Le processus de migration du système de radiodiffusion vers celui-ci a déjà commencé, mais pendant la Coupe du monde, ces développements n'étaient pas encore impliqués.

PPS


Lisez aussi dans notre blog:

Source: https://habr.com/ru/post/fr417083/


All Articles