Comment nous avons aidé CDN MegaFon.TV à ne pas participer à la Coupe du monde 2018

En 2016, nous avons parlé de la façon dont MegaFon.TV a fait face à tous ceux qui voulaient regarder la nouvelle saison de Game of Thrones. Le développement du service ne s'est pas arrêté là, et à la mi-2017, nous devions faire face à des charges plusieurs fois plus. Dans cet article, nous expliquerons comment une croissance aussi rapide nous a inspiré à changer radicalement l'approche de l'organisation du CDN et comment cette nouvelle approche a été testée par la Coupe du monde.

En bref sur MegaFon.TV

MegaFon.TV est un service OTT pour visualiser divers contenus vidéo - films, émissions de télévision, chaînes de télévision et programmes enregistrés. Grâce à MegaFon.TV, l'accès au contenu peut être obtenu sur pratiquement n'importe quel appareil: sur les téléphones et tablettes avec iOS et Android, sur les téléviseurs intelligents LG, Samsung, Philips, Panasonic de différentes années de sortie, avec tout un zoo OS (Apple TV, Android TV), dans navigateurs de bureau sous Windows, MacOS, Linux, dans les navigateurs mobiles sur iOS et Android, et même sur des appareils exotiques tels que STB et les projecteurs Android pour enfants. Il n'y a pratiquement aucune restriction sur les appareils - seule la disponibilité d'Internet avec une bande passante de 700 Kbps est importante. À propos de la façon dont nous avons organisé la prise en charge de tant d'appareils, il y aura un article distinct à l'avenir.
La plupart des utilisateurs du service sont des abonnés MegaFon, ce qui s’explique par des offres rentables (et le plus souvent même gratuites) incluses dans le plan tarifaire de l’abonné. Bien que nous notons également une augmentation significative du nombre d'utilisateurs d'autres opérateurs. Conformément à cette distribution, 80% du trafic MegaFon.TV est consommé au sein du réseau MegaFon.

Sur le plan architectural, depuis le lancement du service, le contenu a été distribué via CDN. Nous avons un poste séparé dédié au travail de ce CDN. Dans ce document, nous avons expliqué comment cela nous a permis de gérer le trafic de pointe qui est allé au service fin 2016, lors de la sortie de la nouvelle saison de Game of Thrones. Dans cet article, nous parlerons du développement ultérieur de MegaFon.TV et des nouvelles aventures qui sont tombées sur le service avec la Coupe du Monde 2018.

Croissance des services. Et des problèmes

Par rapport aux événements du dernier message, fin 2017, le nombre d'utilisateurs de Megafon.TV a augmenté à plusieurs reprises, les films et les séries sont également devenus un ordre de grandeur plus important. De nouvelles fonctionnalités ont été lancées, de nouveaux packages sont apparus, disponibles «par abonnement». Les pics de trafic depuis le «Game of Thrones» que nous voyons aujourd'hui chaque jour, la proportion de films et d'émissions de télévision dans le flux total n'a cessé d'augmenter.

Parallèlement à cela, des problèmes ont commencé avec la redistribution du trafic. Notre surveillance, configurée pour télécharger des segments pour différents types de trafic dans différents formats, a de plus en plus commencé à produire des erreurs lors du téléchargement de segments vidéo par timeout. Dans le service MegaFon.TV, la longueur du morceau est de 8 secondes. Si le bloc n'a pas le temps de se charger en 8 secondes, des erreurs peuvent se produire.

Le pic d'erreurs devait survenir aux heures les plus chargées. Comment cela devrait-il affecter les utilisateurs? Au minimum, ils ont pu observer une détérioration de la qualité vidéo. Il n'est pas toujours perceptible à l'œil nu, en raison d'un nombre suffisamment important de profils multi-bitrate. Dans le pire des cas, la vidéo se fige.

La recherche du problème a commencé. Presque immédiatement, il est devenu clair qu'une erreur de rebond se produit sur les serveurs EDGE de CDN. Ici, nous devons faire une petite digression et dire comment les serveurs fonctionnent avec le trafic en direct et VOD. Le schéma est un peu différent. Un utilisateur qui vient sur le serveur EDGE pour du contenu (une liste de lecture ou un morceau), s'il y a du contenu dans le cache, le récupère à partir de là. Sinon, le serveur EDGE recherche du contenu sur Origin, en chargeant le canal principal. Avec une liste de lecture ou un morceau, l'en - tête Cache-Control: max-age est donné, qui indique au serveur EDGE combien de cache une unité de contenu particulière. La différence entre LIVE et VOD réside dans le temps nécessaire pour mettre en cache des morceaux. Pour les morceaux en direct, une courte durée de mise en cache est définie, généralement de 30 secondes à plusieurs minutes - cela est dû au court temps de pertinence du contenu en direct. Ce cache est stocké dans la RAM, car vous devez constamment donner des morceaux et réécrire le cache. Pour les morceaux VOD, plus de temps est défini, de plusieurs heures à des semaines et même des mois - en fonction de la taille de la bibliothèque de contenu et de la répartition de ses vues entre les utilisateurs. Quant aux listes de lecture, elles sont généralement mises en cache en moins de deux secondes, ou elles ne le sont pas du tout. Il convient de préciser que nous ne parlons que du soi-disant mode PULL de CDN, dans lequel nos serveurs fonctionnaient. L'utilisation du mode PUSH dans notre cas ne serait pas entièrement justifiée.

Mais revenons à trouver le problème. Comme nous l'avons déjà remarqué, tous les serveurs ont simultanément travaillé sur le retour des deux types de contenus. Dans le même temps, les serveurs eux-mêmes avaient une configuration différente. En conséquence, certaines machines ont été surchargées à l'aide d'IOPS. Les morceaux n'ont pas eu le temps d'écrire / lire en raison des faibles performances, de la quantité, du volume des disques et de la grande bibliothèque de contenu. D'un autre côté, les machines plus puissantes qui ont reçu plus de trafic ont commencé à échouer lors de l'utilisation du processeur. Les ressources CPU ont été dépensées pour la maintenance du trafic SSL et des morceaux fournis via https, tandis que les IOPS sur les disques ont à peine atteint 35%.

Ce qu'il fallait, c'était un schéma qui, à moindre coût, permettrait d'utiliser de façon optimale les capacités disponibles. De plus, six mois plus tard, la Coupe du monde devait commencer, et selon les calculs préliminaires, les pics de trafic en direct auraient dû être multipliés par six ...

Nouvelle approche de CDN

Après avoir analysé le problème, nous avons décidé de séparer la VOD et le trafic en direct selon différents PAD composés de serveurs avec différentes configurations. Et créez également une fonction de distribution du trafic et de son équilibrage entre différents groupes de serveurs. Il y avait au total trois de ces groupes:

• Serveurs avec un grand nombre de disques hautes performances les mieux adaptés à la mise en cache du contenu VOD. En fait, les disques SSD RI de la capacité maximale seraient les mieux adaptés, mais il n'y en avait pas, et il faudrait trop de budget pour acheter la bonne quantité. Finalement, il a été décidé d'utiliser le meilleur qui soit. Chaque serveur contenait huit disques SAS 1 To 10 000 en RAID5. A partir de ces serveurs, VOD_PAD a été compilé.
  
• Serveurs avec une grande quantité de RAM pour mettre en cache tous les formats possibles pour la livraison de morceaux en direct, avec des processeurs capables de gérer le trafic SSL et des interfaces réseau "épaisses". Nous avons utilisé la configuration suivante: 2 processeurs de 8 cœurs / 192 Go de RAM / 4 interfaces de 10 Go. À partir de ces serveurs, EDGE_PAD a été compilé.
  
• Le groupe de serveurs restant n'est pas en mesure de gérer le trafic VOD, mais convient aux petits volumes de contenu en direct. Ils peuvent être utilisés comme réserve. À partir des serveurs, RESERVE_PAD a été compilé.
  

La répartition était la suivante:

Un module logique spécial était chargé de choisir le PAD dont l'utilisateur était censé recevoir le contenu. Voici ses tâches:

• Analysez l'URL, appliquez le schéma ci-dessus pour chaque demande de flux et émettez le PAD requis
  
• Pour supprimer la charge des interfaces EDGE_PAD toutes les 5 minutes ( et c'était notre erreur ), et lorsque la limite est atteinte, basculez le trafic excédentaire sur RESERVE_PAD. Pour soulager la charge, un petit script perl a été écrit qui a renvoyé les données suivantes:
  - horodatage - date et heure de mise à jour des données de chargement (au format RFC 3339);
  - total_bandwidth - charge d'interface actuelle (total), Kbps;
  - rx_bandwidth - charge d'interface actuelle (trafic entrant), Kbps;
  - tx_badwidth - charge d'interface actuelle (trafic sortant), Kbps.
  
• Dirigez le trafic en mode manuel vers n'importe quel serveur PAD ou Origin en cas de situations imprévues, ou si nécessaire, travaillez sur l'un des PAD. La configuration était sur le serveur au format yaml et permettait de prendre tout le trafic vers le PAD souhaité, ou le trafic selon l'un des paramètres:
  - Type de contenu
  - cryptage du trafic
  - Trafic payant
  - type d'appareil
  - Type de liste de lecture
  - Région
  

Les serveurs d'origine ont un SSD en sous-effectif. Malheureusement, lors du basculement du trafic vers Origin, HIT_RATE sur les morceaux VOD laissait beaucoup à désirer (environ 30%), mais ils ont accompli leur tâche, nous n'avons donc observé aucun problème avec les conditionneurs de paquets dans CNN.

Comme il y avait peu de serveurs pour la configuration EDGE_PAD, il a été décidé de les allouer dans les régions avec la plus grande part de trafic - Moscou et la région de la Volga. Avec l'aide de GeoDNS, le trafic a été envoyé à la région de la Volga à partir des régions des districts fédéraux de la Volga et de l'Oural. Le hub de Moscou a servi le reste. Nous n'aimions pas vraiment l'idée de livrer du trafic vers la Sibérie et l'Extrême-Orient depuis Moscou, mais au total, ces régions représentent environ 1/20 de tout le trafic, et les canaux de MegaFon se sont avérés assez larges pour de tels volumes.
Après l'élaboration du plan, les travaux suivants ont été effectués:

• En deux semaines, développé la fonctionnalité de commutation de CDN
  
• Il a fallu un mois pour installer et configurer les serveurs EDGE_PAD, ainsi que pour étendre les canaux pour eux
  
• Il a fallu deux semaines pour diviser le groupe de serveurs actuel en deux parties, plus deux semaines supplémentaires pour appliquer les paramètres à tous les serveurs du réseau et à l'équipement du serveur
  
• Et, enfin, la semaine a été consacrée aux tests (malheureusement pas sous charge, ce qui a ensuite affecté)
  

Il s'est avéré paralléliser une partie du travail, et finalement cela a pris six semaines.

Premiers résultats et plans futurs

Après réglage, les performances globales du système étaient de 250 Go / s. La solution avec le transfert du trafic VOD vers des serveurs séparés a immédiatement montré son efficacité après son déploiement en production. Depuis le début de la Coupe du monde, il n'y a eu aucun problème de trafic VOD. Plusieurs fois, pour diverses raisons, j'ai dû basculer le trafic VOD vers Origin, mais en principe, ils ont également fait face. Ce schéma n'est peut-être pas très efficace en raison de la très faible utilisation du cache, car nous forçons les SSD à écraser constamment le contenu. Mais le circuit fonctionne.

Quant au trafic en direct, les volumes correspondants pour tester notre décision sont apparus avec le début de la Coupe du Monde. Les problèmes ont commencé lorsque la deuxième fois que nous avons dû faire face à un changement de trafic lorsque nous avons atteint la limite lors du match Russie-Egypte. Lorsque la commutation du trafic a fonctionné, tout s'est déversé sur le PAD de sauvegarde. Au cours de ces cinq minutes, le nombre de demandes (courbe de croissance) a été si élevé que le CDN de sauvegarde s'est bouché complètement et a commencé à verser des erreurs. Dans le même temps, le PAD principal a été libéré pendant cette période et a commencé à rester un peu inactif:



3 conclusions en ont été tirées:

1. Cinq minutes, c'est encore trop. Il a été décidé de réduire la période de déchargement à 30 secondes. Par conséquent, le trafic sur le PAD de secours a cessé d'augmenter de façon spasmodique:
   
   
2. Il est nécessaire au minimum de transférer les utilisateurs entre les PAD chaque fois que le commutateur est déclenché. Cela devrait fournir une fluidité supplémentaire de commutation. Nous avons décidé d'attribuer un cookie à chaque utilisateur (ou plutôt à l'appareil), selon lequel le module responsable de la distribution comprend si l'utilisateur doit rester sur le PAD actuel ou si un changement doit être effectué. Ici, la technologie peut être à la discrétion de celui qui la met en œuvre. Par conséquent, nous ne perdons pas de trafic sur le PAD principal.
   
3. Le seuil de commutation a été défini trop bas, en conséquence, le trafic sur le PAD de secours a augmenté comme une avalanche. Dans notre cas, il s'agissait d'une réassurance - nous n'étions pas complètement sûrs d'avoir fait le bon réglage du serveur (l'idée pour laquelle, soit dit en passant, a été empruntée à Habr). Le seuil a été augmenté pour les performances physiques des interfaces réseau.
   

Les améliorations ont pris trois jours, et déjà lors du match Russie-Croatie, nous avons vérifié si notre optimisation fonctionnait. En général, le résultat nous a plu. À son apogée, le système a traité 215 Gbit / s de trafic mixte. Ce n'était pas une limite théorique sur les performances du système - nous avions encore une marge substantielle. Si nécessaire, nous pouvons maintenant connecter n'importe quel CDN externe, si nécessaire, et y "éliminer" le trafic excédentaire. Un tel modèle est bon lorsque vous ne voulez pas payer de l'argent solide chaque mois pour utiliser le CDN de quelqu'un d'autre.

Nos plans comprennent la poursuite du développement de CDN. Pour commencer, je voudrais étendre le schéma EDGE_PAD à tous les districts fédéraux - cela conduira à une moindre utilisation des canaux. Des tests de circuit de redondance VOD_PAD sont également en cours, et certains des résultats semblent maintenant assez impressionnants.

En général, tout ce qui a été fait au cours de la dernière année m'amène à penser que le CDN du service qui distribue du contenu vidéo est un must have. Et même pas parce qu'il vous permet d'économiser beaucoup d'argent, mais plutôt parce que le CDN devient une partie du service lui-même, affecte directement la qualité et la fonctionnalité. Dans de telles circonstances, le donner entre de mauvaises mains est au moins déraisonnable.