Komunikacja wideo to główny sposób komunikacji nauczyciela z uczniem na platformie Vimbox. Dawno temu zrezygnowaliśmy ze Skype'a, wypróbowaliśmy kilka rozwiązań innych firm i ostatecznie zdecydowaliśmy się na kombinację WebRTC - Janus-gateway. Przez jakiś czas byliśmy ze wszystkiego zadowoleni, ale nadal pojawiały się pewne negatywne aspekty. W rezultacie powstał odrębny kierunek wideo.
Poprosiłem Kirilla Rogovoya, szefa nowego kierunku, aby opowiedział o ewolucji komunikacji wideo w Skyeng, odkrytych problemach, rozwiązaniach i kulach, z których ostatecznie skorzystaliśmy. Mamy nadzieję, że artykuł będzie przydatny dla firm, które również samodzielnie tworzą wideo za pomocą aplikacji internetowej.
Trochę historii
Latem 2017 roku szef rozwoju Skyeng, Sergey Safonov, podczas Backend Conf opowiadał o tym, jak „porzuciliśmy Skype'a i wdrożyliśmy WebRTC”. Zainteresowani mogą obejrzeć nagranie wystąpienia pod adresem (~45 min), i tutaj pokrótce nakreślę jego istotę.
Dla szkoły Skyeng komunikacja wideo zawsze była priorytetowym sposobem komunikacji nauczyciel-uczeń. Na początku korzystano ze Skype'a, ale kategorycznie nie był on zadowalający z wielu powodów, przede wszystkim ze względu na brak logów i brak możliwości integracji bezpośrednio z aplikacją webową. Dlatego przeprowadzaliśmy różnego rodzaju eksperymenty.
Właściwie nasze wymagania dotyczące komunikacji wideo były w przybliżeniu następujące:
— stabilność;
— niska cena za lekcję;
— nagrywanie lekcji;
— śledzenie, kto ile mówi (dla nas ważne jest, aby na lekcjach uczniowie mówili więcej niż nauczyciel);
— skalowanie liniowe;
- możliwość korzystania zarówno z protokołu UDP, jak i TCP.
Pierwszą próbą było wdrożenie Tokboxa w 2013 roku. Wszystko było dobrze, ale okazało się bardzo drogie - 113 rubli za lekcję - i pochłonęło zysk.
Następnie w 2015 roku zintegrowano Voximplant. Tutaj była funkcja, której potrzebowaliśmy, aby śledzić, kto ile mówił, a jednocześnie rozwiązanie było znacznie tańsze: jeśli nagrywano tylko dźwięk, kosztowało to 20 rubli za lekcję. Jednak działało tylko przez UDP i nie mogło przełączyć się na TCP. Jednak około 40% uczniów ostatecznie z niego skorzystało.
Rok później zaczęliśmy mieć klientów korporacyjnych z własnymi, specyficznymi wymaganiami. Przykładowo wszystko powinno działać poprzez przeglądarkę, firma otwiera tylko http i https; tj. brak Skype lub UDP. Klienci korporacyjni = pieniądze, więc wrócili do Tokboxa, ale problem ceny nie zniknął.
Rozwiązanie - WebRTC i Janus
Zdecydowałem się skorzystać . Odpowiada za nawiązanie połączenia, kodowanie i dekodowanie strumieni, synchronizację ścieżek oraz kontrolę jakości z obsługą usterek sieciowych. Ze swojej strony musimy zapewnić odczyt strumieni z kamery i mikrofonu, rysowanie wideo, zarządzanie połączeniem, nawiązanie połączenia WebRTC i przesyłanie do niego strumieni, a także przesyłanie komunikatów sygnalizacyjnych pomiędzy klientami w celu nawiązania połączenia (sam WebRTC opisuje jedynie format danych, ale nie jego mechanizm przesyłania). Jeśli klienci znajdują się za NAT, WebRTC łączy serwery STUN; jeśli to nie pomoże, serwery TURN.
Zwykłe połączenie p2p jest dla nas niewystarczające, ponieważ chcemy nagrać lekcje do dalszej analizy w przypadku reklamacji. Dlatego wysyłamy strumienie WebRTC przez przekaźnik . W rezultacie klienci nie znają swoich adresów, widzą jedynie adres serwera Janus; pełni także funkcje serwera sygnałowego. Janus ma wiele potrzebnych nam funkcji: automatycznie przełącza się na TCP, jeśli klient ma zablokowany UDP; może nagrywać zarówno strumienie UDP, jak i TCP; skalowalny; Istnieje nawet wbudowana wtyczka do testów echa. W razie potrzeby serwery STUN i TURN z Twilio są automatycznie łączone.
Latem 2017 roku mieliśmy uruchomione dwa serwery Janus, plus dodatkowy serwer do przetwarzania nagranych surowych plików audio i wideo, tak aby nie zajmować procesorów głównych. Podczas łączenia serwery Janus zostały wybrane na zasadzie nieparzystej i parzystej (numer połączenia). Na tamte czasy to wystarczyło, według naszych odczuć, dawało około czterokrotny margines bezpieczeństwa, procent realizacji wynosił około 80. Jednocześnie obniżono cenę do ~2 rubli za lekcję plus rozwój i wsparcie.
Wracając do tematu komunikacji wideo
Stale monitorujemy opinie uczniów i nauczycieli, aby w odpowiednim czasie identyfikować i naprawiać problemy. Latem 2018 r. jakość połączeń zdecydowanie zajmowała pierwsze miejsce wśród skarg. Z jednej strony oznaczało to, że udało nam się pokonać inne niedociągnięcia. Z drugiej strony trzeba było coś pilnie zrobić: jeśli lekcja zostanie zakłócona, ryzykujemy utratę jej wartości, czasami wraz z kosztami zakupu kolejnego pakietu, a jeśli lekcja wprowadzająca zostanie zakłócona, ryzykujemy utratę potencjalnego klienta całkowicie.
W tym czasie nasza komunikacja wideo była jeszcze w trybie MVP. Mówiąc najprościej, uruchomili to, zadziałało, raz przeskalowali, zrozumieli, jak to zrobić – cóż, świetnie. Jeśli to działa, nie naprawiaj tego. Nikt celowo nie zajął się kwestią jakości komunikacji. W sierpniu stało się jasne, że nie można tego kontynuować, dlatego opracowaliśmy odrębny kierunek, aby dowiedzieć się, co jest nie tak z WebRTC i Janusem.
Na wejściu ten kierunek otrzymał: rozwiązanie MVP, brak metryk, brak celów, brak procesów doskonalenia, a 7% nauczycieli narzeka na jakość komunikacji (nie było też danych o uczniach).
Trwa realizacja nowego kierunku
Polecenie wygląda mniej więcej tak:
- Kierownik działu, który jest jednocześnie głównym programistą.
- Kontrola jakości pomaga testować zmiany, szuka nowych sposobów na stworzenie niestabilnych warunków komunikacji i zgłasza problemy z pierwszej linii.
- Analityk stale szuka różnych korelacji w danych technicznych, usprawnia analizę opinii użytkowników i sprawdza wyniki eksperymentów.
- Menedżer produktu pomaga w ogólnym kierowaniu i alokacji zasobów do eksperymentów.
- Drugi programista często pomaga w programowaniu i zadaniach pokrewnych.
Na początek stworzyliśmy stosunkowo niezawodny wskaźnik, który śledził zmiany w ocenach jakości komunikacji (średnia z dni, tygodni, miesięcy). Były to wówczas oceny nauczycieli, później dodano do nich oceny uczniów. Następnie zaczęli budować hipotezy na temat tego, co działa nieprawidłowo, poprawiać to i przyglądać się zmianom dynamiki. Poszliśmy na nisko wiszące owoce: na przykład zastąpiliśmy kodek vp8 vp9, wydajność poprawiła się. Próbowaliśmy bawić się ustawieniami Janusa i przeprowadzać inne eksperymenty - w większości przypadków nie prowadziły one do niczego.
W drugim etapie pojawiła się hipoteza: WebRTC jest rozwiązaniem peer-to-peer, a my korzystamy z serwera pośrodku. Być może problem leży tutaj? Zaczęliśmy kopać i znaleźliśmy jak dotąd najbardziej znaczącą poprawę.
W tym momencie serwer z puli został wybrany dość głupim algorytmem: każdy miał swoją „wagę”, w zależności od kanału i mocy, a my staraliśmy się wysłać użytkownika do tego, który ma największą „wagę”, bez zwracając uwagę na lokalizację geograficzną użytkownika. Dzięki temu nauczyciel z Petersburga mógł komunikować się z uczniem z Syberii przez Moskwę, a nie przez nasz serwer Janus w Petersburgu.
Algorytm został przerobiony: teraz, gdy użytkownik otworzy naszą platformę, zbieramy od niego pingi do wszystkich serwerów korzystających z Ajaxu. Nawiązując połączenie wybieramy parę pingów (nauczyciel-serwer i uczeń-serwer) o najmniejszej wartości. Mniejszy ping oznacza mniejszą odległość sieciową od serwera; mniejsza odległość oznacza mniejsze prawdopodobieństwo utraty pakietów; Utrata pakietów jest największym negatywnym czynnikiem w komunikacji wideo. Udział negatywności spadł o połowę w ciągu trzech miesięcy (co prawda, w tym czasie przeprowadzono inne eksperymenty, ale ten prawie na pewno wywarł największy wpływ).
Niedawno odkryliśmy kolejną nieoczywistą, ale pozornie istotną rzecz: zamiast jednego potężnego serwera Janus na grubym kanale, lepiej mieć dwa prostsze, o cieńszej przepustowości. Stało się to jasne, gdy kupiliśmy potężne maszyny w nadziei, że upchną w nich jak najwięcej pokoi (sesji komunikacyjnych) w tym samym czasie. Serwery mają limit przepustowości, który możemy dokładnie przełożyć na ilość pokoi - wiemy ile można otworzyć np. przy 300 Mbit/s. Gdy na serwerze otwartych jest zbyt wiele pokoi, przestajemy wybierać go do nowych aktywności, do czasu aż obciążenie się zmniejszy. Pomysł był taki, że kupując potężną maszynę, maksymalnie załadujemy do niej kanał, tak aby ostatecznie był on ograniczony procesorem i pamięcią, a nie przepustowością. Okazało się jednak, że po określonej liczbie otwartych pokoi (420), pomimo faktu, że obciążenie procesora, pamięci i dysku jest nadal bardzo dalekie od limitów, do pomocy technicznej zaczynają docierać negatywy. Widocznie w Janusie coś się dzieje, być może i tam są jakieś ograniczenia. Zaczęliśmy eksperymentować, obniżyliśmy limit przepustowości z 300 do 200 Mbit/s i problemy zniknęły. Teraz kupiliśmy od razu trzy nowe serwery z niskimi limitami i charakterystykami, uważamy, że doprowadzi to do stabilnej poprawy jakości komunikacji. Oczywiście nie próbowaliśmy dowiedzieć się, co się tam dzieje, wszystko załatwiliśmy o kulach. Na naszą obronę powiedzmy, że w tamtym momencie trzeba było jak najszybciej rozwiązać palący problem, a nie zrobić tego pięknie; poza tym Janus dla nas to czarna skrzynka napisana w C, majstrowanie przy niej jest bardzo kosztowne.
Cóż, w trakcie tego procesu:
- zaktualizowałem wszystkie zależności, które dało się zaktualizować, zarówno na serwerze, jak i na kliencie (to też były eksperymenty, monitorowaliśmy wyniki);
- naprawiono wszystkie zidentyfikowane błędy związane z konkretnymi przypadkami, np. gdy połączenie zostało zerwane i nie zostało automatycznie przywrócone;
- Odbyliśmy wiele spotkań z firmami zajmującymi się komunikacją wideo i zaznajomionymi z naszymi problemami: streaming gier, organizacja webinarów; próbowaliśmy wszystkiego, co wydawało nam się przydatne;
- Przeprowadzono przegląd techniczny sprzętu i jakości komunikacji nauczycieli, od których wpłynęło najwięcej skarg.
Przeprowadzone eksperymenty i późniejsze zmiany pozwoliły zmniejszyć niezadowolenie z komunikacji wśród nauczycieli z 7,1% w styczniu 2018 r. do 2,5% w styczniu 2019 r.
Co dalej
Stabilizacja naszej platformy Vimbox to jeden z głównych projektów firmy na rok 2019. Mamy nadzieję, że uda nam się utrzymać dynamikę i nie będziemy już widzieć komunikacji wideo w czołówce skarg. Rozumiemy, że znaczna część tych reklamacji dotyczy opóźnień w komputerach użytkowników i Internecie, ale tę część musimy ustalić, a resztę rozwiązać. Cała reszta to problem techniczny, wydaje się, że powinniśmy sobie z tym poradzić.
Główna trudność polega na tym, że nie wiemy, do jakiego poziomu faktycznie możliwa jest poprawa jakości. Znalezienie tego sufitu jest głównym zadaniem. W związku z tym zaplanowano dwa eksperymenty:
- porównaj wideo przez Janus ze zwykłym p2p w warunkach bojowych. Eksperyment ten został już przeprowadzony, nie stwierdzono istotnej statystycznie różnicy pomiędzy naszym rozwiązaniem a rozwiązaniem p2p;
- Dostarczajmy (drogie) usługi firm, które zarabiają wyłącznie na rozwiązaniach komunikacji wideo i porównujmy ilość negatywności z nich z istniejącą.
Te dwa eksperymenty pozwolą nam zidentyfikować możliwy do osiągnięcia cel i skupić się na nim.
Ponadto istnieje szereg zadań, które można rozwiązać rutynowo:
- Zamiast subiektywnych recenzji tworzymy techniczny miernik jakości komunikacji;
- Tworzymy bardziej szczegółowe logi sesji, aby dokładniej przeanalizować występujące awarie, zrozumieć kiedy i gdzie dokładnie one wystąpiły oraz jakie z pozoru niepowiązane ze sobą zdarzenia miały w danym momencie miejsce;
- Przed lekcją przygotowujemy automatyczny test jakości połączenia, a także dajemy klientowi możliwość ręcznego przetestowania połączenia, aby zmniejszyć ilość negatywów powodowanych przez jego sprzęt i kanał;
- opracujemy i przeprowadzimy więcej testów obciążenia komunikacji wideo w złych warunkach, ze zmienną utratą pakietów itp.;
- zmieniamy zachowanie serwerów w przypadku problemów, aby zwiększyć odporność na awarie;
- Ostrzeżemy użytkownika, jeśli w ogóle coś będzie nie tak z jego połączeniem, tak jak robi to Skype, aby zrozumiał, że problem leży po jego stronie.
Od kwietnia kierunek komunikacji wideo stał się pełnoprawnym, odrębnym projektem w Skyeng, zajmującym się własnym produktem, a nie tylko częścią Vimbox. Oznacza to, że zaczynamy szukać osób na . Cóż, jak zawsze .
I oczywiście nadal aktywnie komunikujemy się z osobami i firmami zajmującymi się komunikacją wideo. Jeśli chcesz wymienić się z nami doświadczeniami, będzie nam miło! Skomentuj, skontaktuj się z nami - odpowiemy na każde pytanie.
Źródło: www.habr.com