La visioconférence est le principal moyen de communication entre l'enseignant et l'étudiant sur la plateforme Vimbox. Nous avons longtemps abandonné Skype, testé plusieurs solutions tierces et finalement nous nous sommes arrêtés sur l'association WebRTC - Janus-gateway. Pendant un certain temps, tout allait bien, mais certains problèmes négatifs continuaient à survenir. Finalement, une direction distincte pour la vidéo a été créée.
J'ai demandé à Kirill Rogovoy, le responsable de la nouvelle direction, de parler de l'évolution de la visioconférence chez Skyeng, des problèmes détectés, des solutions et des astuces que nous avons finalement adoptées. Nous espérons que cet article sera utile pour les entreprises qui mettent également en place des vidéos via une application web.
Un peu d'histoire
À l'été 2017, le responsable du développement de Skyeng, Sergey Safonov, a pris la parole lors de la Backend Conf pour raconter comment nous avons "abandonner Skype et introduit WebRTC". Ceux qui le souhaitent peuvent voir l'enregistrement de sa présentation à (~45 min), et ici je vais en résumer l'essence.
Pour l'école Skyeng, la visioconférence a toujours été le moyen de communication prioritaire entre l'enseignant et l'élève. Au début, nous utilisions "Skype", mais il ne répondait absolument pas à nos besoins pour un certain nombre de raisons, principalement en raison de l'absence de journaux et de l'impossibilité d'intégration directement dans l'application web. Nous avons donc mené divers expérimentations.
En fait, nos exigences pour la visioconférence étaient à peu près les suivantes :
— stabilité ;
— coût bas par cours ;
— enregistrement des cours ;
— suivi de qui parle combien (il est important pour nous que les élèves parlent plus que l'enseignant pendant les cours) ;
— mise à l'échelle linéaire ;
— possibilité d'utiliser à la fois UDP et TCP.
Nous avons d'abord essayé d'intégrer Tokbox en 2013. Tout allait bien, mais cela revenait très cher - 113 roubles par leçon - et réduisait les bénéfices.
Ensuite, en 2015, nous avons intégré Voximplant. Ce service offrait la fonction nécessaire pour suivre qui parle combien, et de plus, la solution était beaucoup moins coûteuse : avec l'enregistrement seulement audio, cela coûtait 20 roubles par cours. Cependant, il ne fonctionnait qu'avec UDP et ne pouvait pas passer à TCP. Néanmoins, environ 40 % des élèves l'utilisaient finalement.
Au bout d'un an, nous avons commencé à attirer des clients corporatifs avec des exigences spécifiques. Par exemple, tout doit fonctionner via le navigateur, la société n'ouvre que http et https ; c'est-à-dire pas de « Skype » ni de UDP. Les clients corporatifs = argent, donc nous sommes revenus à Tokbox, mais le problème du prix est resté.
La solution — WebRTC et Janus
Nous avons décidé d'utiliser . Elle est responsable de l'établissement des connexions, de l'encodage et du décodage des flux, de la synchronisation des pistes et du contrôle de qualité avec le traitement des problèmes de réseau. De notre côté, nous devons assurer la lecture des flux de la caméra et du microphone, le rendu vidéo, la gestion des connexions, l'établissement de la connexion WebRTC et le passage des flux à celle-ci, ainsi que l'échange de messages de signalisation entre les clients pour établir la connexion (WebRTC ne décrit que le format des données, mais pas le mécanisme de leur transmission). Si les clients se trouvent derrière un NAT, WebRTC se connecte à des serveurs STUN ; si cela ne fonctionne pas, des serveurs TURN.
Une simple connexion p2p ne nous suffit pas, car nous voulons enregistrer les leçons pour une analyse ultérieure en cas de plaintes. Ainsi, nous envoyons les flux WebRTC via un relais . Ainsi, les clients ne connaissent pas les adresses des autres, ne voyant que l'adresse du serveur Janus ; celui-ci remplit également les fonctions de serveur de signalisation. Janus a de nombreuses fonctionnalités dont nous avons besoin : il passe automatiquement en TCP si UDP est bloqué chez le client ; il peut enregistrer des flux en UDP et en TCP ; il est scalable ; et il y a même un plugin intégré pour les tests d'écho. Si nécessaire, les serveurs STUN et TURN de Twilio se connectent automatiquement.
À l'été 2017, nous avions deux serveurs Janus plus un serveur supplémentaire pour traiter les fichiers bruts audio et vidéo enregistrés, afin de ne pas utiliser les processeurs des serveurs principaux. Lors de la connexion, les serveurs Janus étaient sélectionnés selon le principe pair-impair (numéro de connexion). À cette époque, cela était suffisant, selon nos estimations, cela offrait environ quatre fois la marge de sécurité, le taux d'implémentation était d'environ 80. Le prix a été réduit à environ 2 roubles par leçon, plus le développement et la maintenance.
Retour au sujet de la vidéoconférence
Nous surveillons en permanence les retours des élèves et des enseignants afin de détecter et d'éliminer les problèmes à temps. À l'été 2018, la qualité de la connexion s'est clairement imposée comme la principale plainte. D'une part, cela signifiait que nous avions réussi à surmonter d'autres défauts. D'autre part, il fallait agir rapidement : en cas d'interruption d'un cours, nous risquons de perdre son coût, parfois avec celui de l'achat du prochain package, et en cas d'interruption d'une séance d'introduction, de perdre complètement un client potentiel.
À ce moment-là, notre vidéoconférence fonctionnait toujours en mode MVP. Autrement dit, nous avons lancé, cela a fonctionné, nous l'avons mis à l'échelle une fois, compris comment le faire - et tant mieux. If it works, don’t fix it. Personne ne s'occupait spécifiquement de la qualité de la connexion. En août, il est devenu clair que cela ne pouvait plus continuer ainsi, et nous avons lancé une direction distincte pour comprendre ce qui n'allait pas avec WebRTC et Janus.
En entrée, cette direction a reçu : une solution MVP, pas de métriques, pas d'objectifs, pas de processus d'amélioration, sachant que 7 % des enseignants se plaignaient de la qualité de la connexion (il n'y avait pas de données sur les élèves non plus).
La nouvelle direction se met au travail
L'équipe est à peu près comme suit :
- Responsable de la direction, également principal développeur.
- Les QA aident à tester les modifications, cherchent de nouvelles façons de créer des conditions instables pour la connexion, signalent les problèmes de la ligne de front.
- L'analyste recherche constamment différentes corrélations dans les données techniques, améliore l'analyse des retours des utilisateurs, vérifie les résultats des expérimentations.
- Le chef de produit aide avec l'orientation générale et l'allocation des ressources pour les expérimentations.
- Pour la programmation et les tâches connexes, un deuxième développeur aide souvent.
Pour commencer, nous avons mis en place une métrique relativement fiable qui suivait les changements dans l'évaluation de la qualité de la connexion (moyenne par jours, semaines, mois). À ce moment-là, il s'agissait d'évaluations des enseignants, qui ont ensuite été complétées par celles des étudiants. Nous avons ensuite commencé à formuler des hypothèses sur ce qui ne fonctionnait pas, à corriger et à observer les changements dans la dynamique. Nous avons commencé par des fruits à portée de main : par exemple, nous avons remplacé le codec vp8 par vp9, les résultats se sont améliorés. Nous avons essayé de jouer avec les réglages de Janus, de réaliser d'autres expériences - qui dans la plupart des cas n'ont rien donné.
À la deuxième étape, une hypothèse est apparue : WebRTC est une solution peer-to-peer, tandis que nous utilisons un serveur au milieu. Peut-être que le problème se situe ici ? Nous avons commencé à creuser et avons trouvé ici une amélioration significative.
À ce moment-là, le serveur était sélectionné à partir du pool selon un algorithme assez basique : chacun avait son propre « poids », dépendant de la bande passante et de la puissance, et nous essayions d'envoyer l'utilisateur vers celui où le « poids » était le plus élevé, sans prêter attention à l'emplacement géographique de l'utilisateur. En conséquence, un enseignant de Saint-Pétersbourg pouvait communiquer avec un élève de Sibérie via Moscou, et non pas via notre serveur Janus à Saint-Pétersbourg.
L'algorithme a été remodelé : maintenant, lorsque l'utilisateur ouvre notre plateforme, nous collectons à l'aide d'Ajax des pings depuis lui vers tous les serveurs. Lors de l'établissement de la connexion, nous choisissons une paire de pings (enseignant-serveur et élève-serveur) avec la somme la plus faible. Un ping plus faible signifie une distance réseau plus courte vers le serveur ; une distance plus courte signifie une probabilité plus faible de perte de paquets ; la perte de paquets est le facteur négatif le plus important dans la communication vidéo. Le taux de négativité a été réduit de moitié en trois mois (pour être juste, d'autres expériences ont eu lieu pendant cette période, mais celle-ci a presque certainement eu le plus d'impact).
Nous avons récemment découvert une autre chose évidente, mais apparemment importante : plutôt qu'un seul serveur Janus puissant sur une bande passante élevée, il est préférable d'avoir deux serveurs plus modestes avec une bande passante un peu plus faible. Cela s'est avéré après que nous avons acquis des machines puissantes dans l'espoir d'y intégrer autant de salles (sessions de communication) que possible en même temps. Les serveurs ont une limite de bande passante que nous pouvons traduire précisément en nombre de salles — nous savons combien nous pouvons ouvrir, par exemple, sur 300 Mbit/s. Dès que trop de salles sont ouvertes sur le serveur, nous cesserons de le sélectionner pour de nouvelles sessions tant que la charge ne diminuera pas. L'idée était qu'en achetant une machine puissante, nous surchargerions le canal au maximum, afin d'atteindre finalement les limites du processeur et de la mémoire, et non de la bande passante. Mais il s'est avéré qu'après un certain nombre de salles ouvertes (420), bien que l'utilisation du processeur, de la mémoire et du disque soit encore loin des limites, le support technique commence à recevoir des réclamations. Apparemment, quelque chose se dégrade au sein de Janus, peut-être qu'il y a aussi des limitations. Nous avons commencé à expérimenter, réduisant la limite de bande passante de 300 à 200 Mbit/s, et les problèmes ont disparu. Nous avons maintenant acheté trois nouveaux serveurs avec des limites et des caractéristiques modestes, pensant que cela conduira à une amélioration stable de la qualité de la communication. Nous n'avons bien sûr pas cherché à comprendre ce qui s'était passé, les béquilles sont notre seule solution. Pour notre défense, nous dirons qu'il fallait résoudre rapidement un problème urgent, plutôt que de le faire de manière esthétique ; de plus, Janus est pour nous une boîte noire écrite en C, s'y pencher coûte très cher.
Et pendant ce temps, nous :
- avons mis à jour toutes les dépendances possibles, tant sur le serveur que sur le client (ce furent aussi des expériences, nous avons surveillé les résultats) ;
- avons corrigé tous les bugs identifiés concernant des cas spécifiques, par exemple, lorsque la connexion tombait et ne se rétablissait pas automatiquement ;
- avons eu de nombreuses rencontres avec des entreprises travaillant dans le domaine de la visioconférence et familiarisées avec nos problèmes : streaming de jeux, organisation de webinaires ; nous avons testé tout ce qui nous semblait utile ;
- avons réalisé une révision technique du matériel et de la qualité de la communication auprès des enseignants ayant reçu le plus de plaintes.
Les expériences menées et les changements qui en ont résulté ont permis de réduire le mécontentement concernant la connexion parmi les enseignants, passant de 7,1 % en janvier 2018 à 2,5 % en janvier 2019.
Que faire ensuite
La stabilisation de notre plateforme Vimbox est l'un des projets principaux de l'entreprise pour 2019. Nous avons de grands espoirs de maintenir cette dynamique et de ne plus voir les problèmes de vidéoconférence en tête des plaintes. Nous comprenons qu'une part importante de ces plaintes est liée aux lenteurs des ordinateurs et d'Internet des utilisateurs, mais nous devons identifier cette part et résoudre le reste. Tout le reste est un problème technique, et il semble que nous devrions être capables de le gérer.
La principale difficulté réside dans le fait que nous ne savons pas jusqu'à quel niveau il est réellement possible d'améliorer la qualité. Déterminer ce plafond est notre tâche principale. C'est pourquoi deux expériences ont été prévues :
- comparer la vidéo via Janus avec le p2p classique en conditions réelles. Cette expérience a déjà été réalisée et aucune différence statistiquement significative n'a été trouvée entre notre solution et le p2p ;
- nous allons mettre en place des services (coûteux) de sociétés qui gagnent exclusivement sur des solutions de vidéoconférence et comparer le niveau de mécontentement qu'ils génèrent avec celui que nous avons.
Ces deux expériences nous permettront de définir un objectif atteignable et de nous y concentrer.
De plus, il y a plusieurs tâches résolues de manière opérationnelle :
- nous créons une métrique technique de qualité de connexion au lieu d'avis subjectifs ;
- nous générons des journaux de session plus détaillés afin d'analyser avec précision les pannes qui surviennent, de comprendre quand et où elles se produisent, et quels événements apparemment non liés ont eu lieu à ce moment-là ;
- nous préparons un test automatique de qualité de connexion avant le cours et offrons également au client la possibilité de tester manuellement la connexion afin de réduire le nombre de plaintes causées par son matériel et sa bande passante ;
- nous développerons et effectuerons davantage de tests de charge de vidéoconférence dans de mauvaises conditions, avec perte de paquets variable, etc. ;
- nous modifions le comportement des serveurs en cas de problème pour augmenter la résilience ;
- nous avertirons l'utilisateur s'il y a un problème général avec sa connexion, comme le fait par exemple Skype, afin qu'il comprenne que le problème vient de son côté.
À partir d'avril, la direction des communications vidéo devient un projet à part entière au sein de Skyeng, travaillant sur son propre produit, et ne se limite plus simplement à Vimbox. Cela signifie que nous commençons à chercher des personnes pour . Comme toujours, .
Et bien sûr, nous continuons à communiquer activement avec des personnes et des entreprises travaillant dans le domaine des communications vidéo. Si vous souhaitez échanger des expériences avec nous, nous serons ravis ! N'hésitez pas à commenter ou à nous contacter — nous répondrons à tous.
Source : habr.com
