Wideokomunikacja to główny sposób komunikacji nauczyciela i studenta na platformie Vimbox. Od dawna zrezygnowaliśmy z Skype'a, przetestowaliśmy kilka zewnętrznych rozwiązań i ostatecznie zatrzymaliśmy się na połączeniu WebRTC - Janus-gateway. Przez jakiś czas byliśmy zadowoleni, ale pewne negatywne aspekty nadal się pojawiały. W efekcie stworzono oddział zajmujący się wideo.
Poprosiłem Kirilla Rogovogo, szefa nowego działu, o opowiedzenie o ewolucji wideokomunikacji w Skyeng, napotkanych problemach, rozwiązaniach oraz obejściach, które ostatecznie zastosowaliśmy. Mamy nadzieję, że artykuł będzie pomocny dla firm, które również wprowadzają wideokomunikację przez aplikację webową.
Historia
Latem 2017 roku szef działu rozwoju Skyeng, Siergiej Safonow, wystąpił na Backend Conf z prezentacją o tym, jak "zrezygnowaliśmy z Skype'a i wdrożyliśmy WebRTC". Chętni mogą obejrzeć nagranie wystąpienia pod (~45 min), a tutaj krótko przedstawiam jego istotę.
Dla szkoły Skyeng wideokomunikacja zawsze była priorytetowym sposobem komunikacji nauczyciel-uczeń. Na początku używaliśmy „Skype'a”, ale z wielu powodów był on zupełnie nieadekwatny, przede wszystkim z powodu braku logów i niemożności integracji bezpośrednio w aplikacji webowej. Dlatego przeprowadzaliśmy różne eksperymenty.
Właściwie, nasze wymagania dotyczące wideokomunikacji były mniej więcej takie:
— stabilność;
— niska cena za lekcję;
— nagrywanie lekcji;
— śledzenie, kto ile mówi (ważne dla nas, aby uczniowie mówili więcej niż nauczyciele);
— liniowe skalowanie;
— możliwość używania zarówno UDP, jak i TCP.
Pierwszym rozwiązaniem w 2013 roku, które spróbowaliśmy wdrożyć, był Tokbox. Wszystko działało dobrze, ale okazało się bardzo kosztowne – 113 rubli za lekcję – co zjadało zyski.
Następnie w 2015 roku zintegrowaliśmy Voximplant. Tutaj była potrzebna funkcja śledzenia, kto ile mówi, a jednocześnie rozwiązanie było znacznie tańsze: w przypadku nagrywania tylko dźwięku wynosiło 20 rubli za lekcję. Jednak działało tylko przez UDP, nie potrafiło przełączać się na TCP. Mimo to, około 40% uczniów korzystało z tego rozwiązania.
Po roku zaczęliśmy pozyskiwać klientów korporacyjnych z ich specyficznymi wymaganiami. Na przykład, wszystko musi działać przez przeglądarkę, w firmie dozwolone są tylko http i https; tzn. żadnych „Skype'ów” i UDP. Klienci korporacyjni = pieniądze, więc wróciliśmy do Tokbox, ale problem z ceną pozostał.
Rozwiązanie — WebRTC i Janus
Podjęliśmy decyzję o użyciu . Jest odpowiedzialna za nawiązywanie połączenia, kodowanie i dekodowanie strumieni, synchronizację ścieżek i kontrolę jakości z obsługą problemów sieciowych. Z naszej strony musimy zapewnić odczyt strumieni z kamery i mikrofonu, wyświetlanie wideo, zarządzanie połączeniem, nawiązywanie połączeń WebRTC i przesyłanie do nich strumieni, a także przesyłanie wiadomości sygnalizacyjnych między klientami w celu nawiązania połączenia (WebRTC opisuje tylko format danych, a nie mechanizm ich przesyłania). W przypadku, gdy klienci są za NAT, WebRTC łączy się z serwerami STUN, jeśli to nie pomaga, z serwerami TURN.
Zwykłe połączenie p2p nie wystarcza, ponieważ chcemy nagrywać lekcje do dalszej analizy w przypadku skarg. Dlatego przesyłamy strumienie WebRTC przez retransmiter . W rezultacie klienci nie znają swoich adresów, widząc tylko adres serwera Janus; pełni on również funkcje serwera sygnalizacyjnego. Janus ma wiele potrzebnych nam funkcji: automatycznie przechodzi do TCP, jeśli klient ma zablokowane UDP; potrafi nagrywać strumienie zarówno UDP, jak i TCP; jest skalowalny; ma nawet wbudowany plugin do testów echa. W razie potrzeby automatycznie łączone są serwery STUN i TURN od Twilio.
Latem 2017 roku mieliśmy dwa serwery Janus oraz dodatkowy serwer do przetwarzania nagranych surowych plików audio i wideo, aby nie obciążać procesorów głównych. Podczas łączenia serwery Janus były wybierane na zasadzie parzystości-nieparzystości (numer połączenia). W tamtym czasie to wystarczało, według naszych odczuć dawało to około czterokrotny zapas mocy, wskaźnik wdrożenia wynosił około 80. Przy tym cena zmniejszyła się do około 2 rubli za lekcję, plus rozwój i wsparcie.
Powrót do tematu wideokomunikacji
Ciągle monitorujemy opinie uczniów i nauczycieli, aby na czas wykrywać i rozwiązywać problemy. Do lata 2018 roku jakość połączenia znalazła się na czołowej pozycji wśród skarg. Z jednej strony oznaczało to, że skutecznie poradziliśmy sobie z innymi niedociągnięciami. Z drugiej strony, należy szybko coś zrobić: w przypadku przerwania lekcji ryzykujemy utratę jej wartości, czasami wraz z wartością zakupu kolejnego pakietu, a w przypadku przerwania lekcji wprowadzającej – wręcz utratę potencjalnego klienta.
W tym czasie wideokonferencje wciąż były w trybie MVP. Mówiąc prościej, uruchomiliśmy, działało, raz skalowaliśmy, zrozumieliśmy, jak to zrobić - i wszystko było w porządku. If it works, don’t fix it. Nikt celowo nie zajmował się jakością połączeń. Do sierpnia stało się jasne, że tak dalej być nie może, i uruchomiliśmy osobny dział, aby zrozumieć, co dokładnie jest nie tak z WebRTC i Janusem.
Na wejściu ten dział otrzymał: rozwiązanie MVP, brak metryk, brak celów, brak procesów poprawy, a 7% nauczycieli narzeka na jakość połączenia (dane dotyczące uczniów również były niedostępne).
Nowy dział bierze się do pracy
Zespół wygląda mniej więcej tak:
- Kierownik działu, który jest również głównym programistą.
- QA pomagają testować zmiany, szukać nowych sposobów na stworzenie niestabilnych warunków dla połączeń, zgłaszać problemy z linii frontu.
- Analityk nieustannie szuka różnych korelacji w danych technicznych, ulepsza analizę opinii użytkowników, sprawdza wyniki eksperymentów.
- Menadżer produktu pomaga w ogólnym kierunku i alokacji zasobów na eksperymenty.
- Przy samym programowaniu i pokrewnych zadaniach często pomaga drugi programista.
Na początek skonfigurowaliśmy stosunkowo niezawodną metrykę, która śledziła zmiany ocen jakości połączenia (średnia na dzień, tydzień, miesiąc). W tym momencie były to oceny od nauczycieli, w późniejszym czasie dodano oceny od studentów. Następnie zaczęliśmy formułować hipotezy dotyczące tego, co nie działa, poprawiać i obserwować zmiany w dynamice. Przeszliśmy do tzw. niskowiszących owoców: na przykład wymieniliśmy kodek vp8 na vp9, a wyniki się poprawiły. Próbowaliśmy bawić się ustawieniami Janusa, przeprowadzać różne eksperymenty – w większości przypadków nie prowadziły one do żadnych rezultatów.
Na drugim etapie pojawiła się hipoteza: WebRTC to rozwiązanie peer-to-peer, a my używamy serwera pośredniego. Być może problem kryje się tutaj? Zaczęliśmy badać ten temat i znaleźliśmy dotąd najbardziej znaczącą poprawę.
W tamtym momencie serwer był wybierany z puli według dość prymitywnego algorytmu: każdy miał swój "ciężar", zależny od łącza i mocy, a my staraliśmy się wysłać użytkownika do tego, gdzie "ciężar" był większy, nie zwracając uwagi na to, gdzie geograficznie znajduje się użytkownik. W rezultacie nauczyciel z Petersburga mógł komunikować się z uczniem z Syberii przez Moskwę, a nie przez nasz serwer Janus w Sankt Petersburgu.
Algorytm został zmodyfikowany: teraz, gdy użytkownik otwiera naszą platformę, za pomocą Ajaxu zbieramy pingi od niego do wszystkich serwerów. Przy nawiązywaniu połączenia wybieramy parę pingów (nauczyciel-serwer i uczeń-serwer) z najmniejszą sumą. Mniejszy ping – mniejsze odległość sieciowa do serwera; mniejsza odległość — mniejsze prawdopodobieństwo utraty pakietów; utrata pakietów — największy negatywny czynnik w wideo połączeniach. Udział negatywnych doświadczeń w ciągu trzech miesięcy spadł dwukrotnie (dla uczciwości warto dodać, że w tym czasie przeprowadzano również inne eksperymenty, ale ten zapewne miał największy wpływ).
Niedawno odkryliśmy jeszcze jedną nieoczywistą, ale z pewnością ważną rzecz: zamiast jednego mocnego serwera Janus na szybkim łączu, lepiej mieć dwa prostsze z nieco niższą przepustowością. Okazało się to po tym, jak kupiliśmy właśnie mocne maszyny, mając nadzieję, że pomieszczą jak najwięcej sal (sesji połączeń) jednocześnie. Serwery mają limit przepustowości, który możemy dokładnie przełożyć na liczbę sal — wiemy, ile można otworzyć, na przykład, na 300 Mbit/s. Gdy na serwerze otworzy się zbyt wiele sal — przestajemy go wybierać do nowych zajęć, dopóki obciążenie nie spadnie. Idea polegała na tym, że kupując mocną maszynę, maksymalnie obciążymy jej łącze, aby w końcu dotrzeć do procesora i pamięci, a nie do przepustowości. Okazało się jednak, że po otwarciu określonej liczby sal (420), mimo że obciążenie procesora, pamięci i dysku jest jeszcze dalekie od limitów, zaczynają napływać negatywne zgłoszenia do wsparcia technicznego. Wygląda na to, że coś staje się gorsze wewnątrz Janus, być może są tam też jakieś ograniczenia. Zaczęliśmy eksperymentować, obniżyliśmy limit przepustowości z 300 do 200 Mbit/s, problemy zniknęły. Teraz kupiliśmy od razu trzy nowe serwery z niewielkimi limitami i parametrami, myślimy, że to doprowadzi do stabilnej poprawy jakości połączeń. Oczywiście nie zajmowaliśmy się zgłębianiem, na czym polegał problem, kostki to nasza specjalność. W obronie powiedzmy, że w tym momencie należało jak najszybciej rozwiązać pilny problem, a nie robić to ładnie; poza tym Janus to dla nas czarna skrzynka napisana w C, grzebanie w tym jest bardzo kosztowne.
A w czasie tego procesu:
- aktualizowaliśmy wszystkie zależności, które można było zaktualizować, zarówno na serwerze, jak i na kliencie (to też były eksperymenty, śledziliśmy efekty);
- naprawiliśmy wszystkie wykryte błędy, dotyczące konkretnych przypadków, na przykład gdy połączenie się przerywało i nie odnawiało automatycznie;
- przeprowadziliśmy wiele spotkań z firmami zajmującymi się wideokomunikacją oraz z osobami znajomymi z naszymi problemami: streamującymi gry, organizującymi webinaria; wypróbowaliśmy wszystko, co nam się wydawało przydatne;
- przeprowadziliśmy przegląd techniczny sprzętu i jakości połączeń u nauczycieli, od których napływało najwięcej skarg.
Przeprowadzone eksperymenty oraz wprowadzone zmiany pozwoliły obniżyć niezadowolenie z połączeń wśród nauczycieli z 7,1% w styczniu 2018 do 2,5% w styczniu 2019.
Co dalej
Stabilizacja naszej platformy Vimbox jest jednym z głównych projektów firmy na rok 2019. Mamy wielkie nadzieje, że uda nam się utrzymać dynamikę i więcej nie zobaczyć połączeń wideo na szczycie skarg. Rozumiemy, że znaczna część tych skarg jest związana z opóźnieniami komputerów i internetu użytkowników, ale musimy zidentyfikować tę część i rozwiązać wszystko inne. Wszystko inne to problem techniczny, który, wydaje się, powinniśmy umieć rozwiązać.
Główna trudność polega na tym, że nie wiemy, do jakiego poziomu w ogóle możliwe jest podniesienie jakości. Określenie tego sufitu to nasza główna zadanie. Dlatego zaplanowano dwa eksperymenty:
- porównanie wideo przez Janus z tradycyjnym p2p w warunkach bojowych. Ten eksperyment już został przeprowadzony, nie stwierdzono statystycznie istotnych różnic między naszym rozwiązaniem a p2p;
- wdrożenie (drogi) usług od firm, które zarabiają wyłącznie na rozwiązaniach w zakresie połączeń wideo, i porównanie ilości negatywnych doświadczeń z nimi z tymi, które już mamy.
Te dwa eksperymenty pozwolą nam określić osiągalny cel i skupić się na nim.
Ponadto istnieje szereg zadań rozwiązywanych na bieżąco:
- tworzymy techniczną metrykę jakości połączenia zamiast subiektywnych opinii;
- prowadzimy bardziej szczegółowe logi sesji, aby dokładniej analizować występujące awarie, zrozumieć, kiedy i gdzie miały miejsce, jakie na pierwszy rzut oka niezwiązane zdarzenia miały miejsce w tym momencie;
- przygotowujemy automatyczny test jakości połączenia przed zajęciami, a także umożliwimy klientowi manualne przetestowanie połączenia, aby zmniejszyć liczbę negatywnych doświadczeń spowodowanych jego sprzętem i łączem;
- opracujemy i będziemy przeprowadzać więcej testów obciążeniowych połączeń wideo w słabych warunkach, z zmienną utratą pakietów itp.;
- zmieniamy zachowanie serwerów w przypadku problemów w celu zwiększenia odporności na awarie;
- będziemy ostrzegać użytkownika, jeśli ma jakiekolwiek problemy z połączeniem, tak jak robi to 'Skype', aby zrozumiał, że problem leży po jego stronie.
Od kwietnia dział wideokomunikacji staje się pełnoprawnym oddzielnym projektem w Skyeng, zajmującym się własnym produktem, a nie tylko częścią Vimbox. Oznacza to, że zaczynamy poszukiwania osób na . Jak zawsze .
. Oczywiście kontynuujemy aktywną komunikację z ludźmi i firmami zajmującymi się wideokomunikacją. Jeśli chcesz wymienić się z nami doświadczeniami — z przyjemnością! Komentuj, kontaktuj się — odpowiemy wszystkim.
Źródło: habr.com
