Videokommunikation ist der Hauptweg der Interaktion zwischen Lehrenden und Studierenden auf der Plattform Vimbox. Wir haben Skype bereits vor einiger Zeit aufgegeben, diverse Drittanbieter-Lösungen getestet und schließlich auf die Kombination WebRTC – Janus-Gateway gesetzt. Eine Zeit lang waren wir mit dieser Lösung zufrieden, doch einige negative Aspekte traten weiterhin auf. Daher wurde ein eigenes Team für Videotechnologie ins Leben gerufen.
Ich habe Kirill Rogovoy, den Leiter dieses neuen Teams, gebeten, über die Entwicklung der Videokommunikation bei Skyeng, die entdeckten Probleme, Lösungen und die Umgehungen zu berichten, die wir letztendlich eingesetzt haben. Wir hoffen, dass dieser Artikel für Unternehmen, die ebenfalls Videokommunikation über Webanwendungen implementieren, von Nutzen sein wird.
Ein wenig Geschichte
Im Sommer 2017 hielt der Entwicklungsleiter von Skyeng, Sergey Safonov, einen Vortrag auf der Backend Conf, in dem er erläuterte, wie wir "Skype aufgegeben und WebRTC implementiert haben". Interessierte können sich die Aufzeichnung des Vortrags untersehen (ca. 45 Minuten), und hier fasse ich die wesentlichen Punkte zusammen.
Für die Skyeng-Schule war Videoverbindung schon immer die bevorzugte Kommunikationsmethode zwischen Lehrer und Schüler. Anfangs nutzten wir Skype, aber das war aus mehreren Gründen nicht zufriedenstellend, vor allem wegen des Fehlens von Protokollen und der Unmöglichkeit, es direkt in die Webanwendung zu integrieren. Daher haben wir verschiedene Experimente durchgeführt.
Unsere Anforderungen an die Videoverbindung waren im Grunde genommen folgende:
— Stabilität;
— niedrige Kosten pro Unterrichtseinheit;
— Aufzeichnung der Unterrichtseinheiten;
— Verfolgung, wer wie viel spricht (uns ist wichtig, dass die Schüler während der Lektionen mehr sprechen als der Lehrer);
— lineare Skalierbarkeit;
— die Möglichkeit, sowohl UDP als auch TCP zu verwenden.
Als erstes haben wir 2013 Tokbox getestet. Es war ganz gut, aber es war sehr teuer – 113 Rubel pro Lektion – und hat unsere Gewinne geschmälert.
Dann haben wir 2015 Voximplant integriert. Hier gab es die erforderliche Funktion zur Überwachung, wer wie viel spricht, und die Lösung war deutlich günstiger: Bei der reinen Audioaufnahme kostete es nur 20 Rubel pro Lektion. Allerdings funktionierte es nur über UDP und konnte nicht auf TCP umschalten. Trotzdem nutzten letztendlich rund 40 % der Schüler dieses System.
Nach einem Jahr begannen bei uns Corporate-Kunden mit spezifischen Anforderungen aufzutauchen. Zum Beispiel muss alles über den Browser funktionieren; im Unternehmen sind nur http und https erlaubt, also keine „Skypes“ oder UDP. Corporate-Kunden = Geld, deshalb haben wir zu Tokbox zurückgekehrt, aber das Preisproblem besteht weiterhin.
Die Lösung — WebRTC und Janus
Wir haben beschlossen, . Diese ist verantwortlich für die Verbindungseinrichtung, die Codierung und Decodierung von Streams, die Synchronisierung der Kanäle und die Qualitätskontrolle sowie die Verarbeitung von Netzwerkproblemen. Von unserer Seite müssen wir den Zugriff auf Streams von Kamera und Mikrofon gewährleisten, das Video rendern, die Verbindung steuern, die WebRTC-Verbindung aufbauen und die Streams übertragen sowie die Signalisierungsnachrichten zwischen den Clients austauschen, um die Verbindung herzustellen (WebRTC beschreibt nur das Datenformat, jedoch nicht den Übertragungsmechanismus). Falls sich die Clients hinter einem NAT befinden, verbindet sich WebRTC mit STUN-Servern; wenn das nicht hilft, werden TURN-Server verwendet.
Eine einfache P2P-Verbindung reicht uns nicht aus, da wir die Lektionen zur späteren Analyse im Falle von Beschwerden aufzeichnen möchten. Daher leiten wir die WebRTC-Streams über einen Relaisserver. . Dadurch wissen die Kunden nicht, wo sich die anderen befinden, da sie nur die Adresse des Janus-Servers sehen, der auch die Funktionen eines Signalisierungsservers übernimmt. Janus bietet viele nützliche Funktionen: er wechselt automatisch zu TCP, wenn UDP beim Client blockiert ist; er kann sowohl UDP- als auch TCP-Streams aufzeichnen; er ist skalierbar; es gibt sogar ein eingebautes Plugin für Echo-Tests. Bei Bedarf werden automatisch STUN- und TURN-Server von Twilio verbunden.
Im Sommer 2017 betrieben wir zwei Janus-Server sowie einen zusätzlichen Server zur Verarbeitung der aufgenommenen Rohdateien von Audio und Video, um die Hauptprozessoren nicht zu belasten. Bei der Verbindung wurden die Janus-Server nach dem Prinzip gerade-ungerade (Verbindungsnummer) ausgewählt. Zu diesem Zeitpunkt war dies ausreichend, wir schätzten, dass es einen ungefähr vierfachen Spielraum bot, und die Implementierungsquote betrug etwa 80. Gleichzeitig sank der Preis auf etwa 2 Rubel pro Lektion, zuzüglich Entwicklung und Support.
Zurück zum Thema Videoübertragung
Wir überwachen ständig das Feedback von Schülern und Lehrern, um Probleme frühzeitig zu erkennen und zu beheben. Bis zum Sommer 2018 war die Verbindungsqualität ganz oben auf der Liste der Beschwerden. Einerseits bedeutete dies, dass wir andere Mängel erfolgreich beheben konnten. Andererseits musste dringend etwas unternommen werden: Bei einer Unterrichtsstörung riskieren wir, dessen Wert zu verlieren, manchmal sogar zusammen mit dem Preis für das nächste Paket; bei einem Ausfall der Einführungssitzung könnten wir sogar einen potenziellen Kunden verlieren.
Zu diesem Zeitpunkt befand sich unser Videochat weiterhin im MVP-Status. Einfach gesagt, wir haben es gestartet, es hat funktioniert, wir haben es einmal skaliert, und das war's. If it works, don’t fix it. Niemand hat gezielt die Frage der Verbindungsqualität behandelt. Im August wurde klar, dass es so nicht weitergehen kann, und wir haben eine separate Abteilung gegründet, um herauszufinden, was bei unserem WebRTC und Janus nicht stimmt.
Dieses neue Team erhielt: ein MVP, keine Metriken, keine Ziele, keine Verbesserungsprozesse, während 7% der Lehrer über die Verbindungsqualität klagten (Daten zu den Schülern lagen ebenfalls nicht vor).
Eine neue Abteilung wird eingerichtet.
Das Team sieht folgendermaßen aus:
- Leiter der Abteilung, gleichzeitig Hauptentwickler.
- QA-Teams helfen dabei, Änderungen zu testen, suchen nach neuen Wegen, instabile Verbindungsbedingungen zu schaffen, und melden Probleme an der Frontlinie.
- Der Analyst sucht ständig nach verschiedenen Korrelationen in den technischen Daten, verbessert die Analyse des Nutzer-Feedbacks und überprüft die Ergebnisse von Experimenten.
- Der Produktmanager unterstützt bei der allgemeinen Richtung und der Zuteilung von Ressourcen für Experimente.
- Bei der Programmierung und verwandten Aufgaben hilft oft ein zweiter Entwickler.
Zunächst haben wir eine relativ zuverlässige Metrik entwickelt, die die Veränderungen der Verbindungsqualität bewertete (durchschnittlich nach Tagen, Wochen, Monaten). Zu diesem Zeitpunkt beruhten diese Bewertungen auf Lehrerrückmeldungen, später wurden auch die Bewertungen der Studierenden hinzugefügt. Daraufhin haben wir Hypothesen aufgestellt, um herauszufinden, was nicht funktioniert – Fehler behoben und die Entwicklungen analysiert. Wir haben mit einfacheren Lösungen begonnen: Zum Beispiel haben wir den Codec VP8 durch VP9 ersetzt, was zu einer Verbesserung der Werte führte. Wir haben die Janus-Einstellungen angepasst und andere Experimente durchgeführt, die in den meisten Fällen jedoch keine nennenswerten Ergebnisse lieferten.
In der zweiten Phase kam die Hypothese auf: WebRTC ist eine Peer-to-Peer-Lösung, und wir nutzen einen Server dazwischen. Vielleicht liegt das Problem hier? Wir begannen zu recherchieren und fanden hier die bislang signifikanteste Verbesserung.
Zu diesem Zeitpunkt wurde der Server aus dem Pool nach einem eher simplen Algorithmus ausgewählt: Jeder hatte ein eigenes "Gewicht", das von der Bandbreite und der Leistung abhängt, und wir versuchten, den Benutzer zu dem Server mit dem höheren "Gewicht" zu leiten, ohne auf die geografische Lage des Benutzers zu achten. Das führte dazu, dass ein Lehrer aus Sankt Petersburg mit einem Schüler aus Sibirien über Moskau kommunizieren konnte, anstatt über unseren Janus-Server in St. Petersburg.
Der Algorithmus wurde überarbeitet: Jetzt, wenn ein Benutzer unsere Plattform öffnet, sammeln wir mit Hilfe von Ajax die Ping-Zeiten zu allen Servern. Bei der Herstellung einer Verbindung wählen wir das Paar von Pings (Lehrer-Server und Schüler-Server) mit der geringsten Summe aus. Ein niedrigerer Ping bedeutet eine kürzere Netzwerklatenz zum Server; kürzere Distanzen verringern die Wahrscheinlichkeit von Paketverlusten; Paketverluste sind der größte negative Faktor in der Videoverbindung. Der Anteil an negativem Feedback ist in den letzten drei Monaten um die Hälfte gesunken (nebenbei sei erwähnt, dass in dieser Zeit auch andere Experimente durchgeführt wurden, aber dieses hatte mit Sicherheit den größten Einfluss).
Kürzlich haben wir eine weitere offensichtliche, aber offenbar wichtige Erkenntnis gewonnen: Anstelle eines leistungsstarken Janus-Servers auf einem dicken Kanal sind zwei einfachere Server mit geringerer Bandbreite besser. Dies stellte sich heraus, nachdem wir leistungsstarke Maschinen gekauft hatten, in der Hoffnung, so viele Räume (Kommunikationssitzungen) wie möglich gleichzeitig unterzubringen. Die Server haben eine Bandbreitenbegrenzung, die wir genau in die Anzahl der Räume umrechnen können – wir wissen, wie viele wir beispielsweise bei 300 Mbit/s öffnen können. Sobald auf dem Server zu viele Räume geöffnet sind, hören wir auf, ihn für neue Sitzungen zu wählen, bis die Last sinkt. Die Idee war, dass wir mit einem leistungsstarken Server den Kanal maximal auslasten, um letztendlich an die CPU- und RAM-Grenzen zu stoßen und nicht an die Bandbreite. Aber es stellte sich heraus, dass nach einer bestimmten Anzahl von geöffneten Räumen (420), obwohl die Auslastung von CPU, RAM und Disk noch weit von den Grenzen entfernt ist, der technischen Unterstützung negative Rückmeldungen erreichen. Offenbar verschlechtert sich etwas innerhalb von Janus, möglicherweise gibt es dort ebenfalls Einschränkungen. Wir begannen mit Experimenten und reduzierten die Bandbreitenbegrenzung von 300 auf 200 Mbit/s, und die Probleme verschwanden. Jetzt haben wir gleich drei neue Server mit geringeren Begrenzungen und Eigenschaften gekauft und glauben, dass dies zu einer stabilen Verbesserung der Verbindungsqualität führen wird. Wir haben uns natürlich nicht weiter damit beschäftigt, worum es da ging; Improvisation ist unser Alles. Zu unserer Verteidigung sei gesagt, dass wir in diesem Moment das dringende Problem so schnell wie möglich lösen mussten und nicht darauf bedacht waren, es schön zu machen; außerdem ist Janus für uns ein schwarzes Kästchen, das in C geschrieben ist, und es ist sehr teuer, darin zu schrauben.
Während des Prozesses haben wir:
- alle aktualisierbaren Abhängigkeiten auf dem Server sowie auf der Client-Seite aktualisiert (dabei handelte es sich ebenfalls um Experimente, deren Ergebnisse wir verfolgt haben);
- alle identifizierten Bugs behoben, die sich auf spezifische Fälle bezogen, beispielsweise wenn die Verbindung abbrach und sich nicht automatisch wiederherstellte;
- zahlreiche Besprechungen mit Unternehmen abgehalten, die im Bereich Videoübertragung tätig sind und mit unseren Herausforderungen vertraut sind: Streaming-Dienste für Spiele, Durchführung von Webinaren; alles ausprobiert, was uns nützlich erschien;
- eine technische Überprüfung der Hardware und der Verbindungsqualität bei den Lehrern durchgeführt, von denen die meisten Beschwerden kamen.
Die durchgeführten Experimente und die darauf folgenden Veränderungen ermöglichten es, die Unzufriedenheit mit der Verbindung unter den Lehrern von 7,1 % im Januar 2018 auf 2,5 % im Januar 2019 zu senken.
Was kommt als Nächstes
Die Stabilisierung unserer Plattform Vimbox ist eines der wichtigsten Projekte unseres Unternehmens für 2019. Wir haben große Hoffnungen, die Dynamik aufrechtzuerhalten und die Videokonferenzproblematik nicht mehr unter den häufigsten Beschwerden zu finden. Uns ist bewusst, dass ein erheblicher Teil dieser Beschwerden auf Verzögerungen bei den Computern und dem Internet der Nutzer zurückzuführen ist, aber wir müssen diesen Anteil identifizieren und alle anderen Probleme lösen. Alle weiteren Herausforderungen sind technischer Natur, und wir sollten in der Lage sein, diese zu bewältigen.
Die Hauptschwierigkeit besteht darin, dass wir nicht wissen, auf welches Niveau die Qualität überhaupt realistisch gesteigert werden kann. Die Feststellung dieser Obergrenze ist die zentrale Aufgabe. Daher haben wir zwei Experimente geplant:
- Wir werden Video über Janus unter realen Bedingungen mit herkömmlichem P2P vergleichen. Dieses Experiment wurde bereits durchgeführt, und es gab keinen statistisch signifikanten Unterschied zwischen unserer Lösung und P2P;
- Wir werden (teure) Dienste von Unternehmen implementieren, die ausschließlich auf Videokommunikationslösungen spezialisiert sind, und die Menge an negativen Rückmeldungen von diesen mit den bestehenden vergleichen.
Diese beiden Experimente werden es uns ermöglichen, ein erreichbares Ziel zu definieren und uns darauf zu konzentrieren.
Darüber hinaus gibt es eine Reihe von Aufgaben, die im regulären Arbeitsablauf angegangen werden:
- Wir erstellen technische Metriken zur Verbindungsqualität anstelle subjektiver Bewertungen;
- Wir erstellen detailliertere Sitzungsprotokolle, um die auftretenden Störungen präziser zu analysieren, zu verstehen, wann und wo genau sie aufgetreten sind und welche auf den ersten Blick nicht zusammenhängenden Ereignisse in diesem Moment stattfanden;
- Wir bereiten einen automatischen Qualitätstest der Verbindung vor dem Unterricht vor und geben dem Kunden die Möglichkeit, die Verbindung manuell zu testen, um die negative Wahrnehmung zu verringern, die durch seine Hardware und den Kanal verursacht wird;
- Wir entwickeln und führen mehr Lasttests für die Videokommunikation unter schlechten Bedingungen mit variablen Paketverlusten usw. durch;
- Wir ändern das Verhalten der Server bei Problemen, um die Fehlertoleranz zu erhöhen;
- Wir werden den Nutzer warnen, wenn er Probleme mit der Verbindung hat, wie es beispielsweise bei "Skype" der Fall ist, damit er erkennt, dass das Problem auf seiner Seite liegt.
Seit April wird der Bereich Videokommunikation zu einem vollwertigen separaten Projekt innerhalb von Skyeng, das sich mit seinem eigenen Produkt beschäftigt und nicht nur Teil von Vimbox ist. Das bedeutet, dass wir nach Personen suchen, die . Und wie immer .
Natürlich stehen wir weiterhin aktiv im Austausch mit Personen und Unternehmen, die im Bereich Videokommunikation tätig sind. Wenn Sie Ihre Erfahrungen mit uns teilen möchten, freuen wir uns! Kommentieren Sie, nehmen Sie Kontakt auf – wir antworten allen.
Quelle: habr.com
