Videozvuk je hlavním způsobem komunikace učitele a studenta na platformě Vimbox. Dávno jsme opustili Skype, vyzkoušeli jsme několik externích řešení a nakonec jsme se rozhodli pro kombinaci WebRTC a Janus-gateway. Nějakou dobu jsme byli spokojeni, ale některé negativní momenty se stále objevovaly. Nakonec bylo vytvořeno samostatné oddělení pro video.
Požádal jsem Kirilla Rogovského, vedoucího nového oddělení, aby nám vyprávěl o evoluci videozvuku v Skyeng, o zjištěných problémech, řešeních a improvizacích, které jsme nakonec použili. Doufáme, že článek bude užitečný také pro firmy, které se snaží zavést video přes webovou aplikaci.
Trocha historie
V létě 2017 se šéf vývoje Skyeng Sergey Safonov představil na Backend Conf s prezentací o tom, jak jsme "opustili Skype a implementovali WebRTC". Ti, kdo mají zájem, si mohou záznam jeho vystoupení prohlédnout na (~45 min), a zde stručně shrnu jeho obsah.
Pro školu Skyeng byla videokomunikace vždy prioritním způsobem komunikace učitel-žák. Zpočátku jsme používali Skype, ale ten nám z mnoha důvodů zcela nevyhovoval, zejména kvůli absenci logů a nemožnosti integrace přímo do webové aplikace. Proto jsme prováděli různé experimenty.
Požadavky na videokomunikaci jsme měli přibližně následující:
— stabilita;
— nízká cena za lekci;
— nahrávání lekcí;
— sledování, kolik kdo mluví (je pro nás důležité, aby studenti mluvili víc než učitel během lekcí);
— lineární škálovatelnost;
— možnost používat jak UDP, tak TCP.
Prvním krokem v roce 2013 bylo pokusit se implementovat Tokbox. Všechno fungovalo dobře, ale bylo to velmi drahé – 113 rublů za lekci – a to výrazně snižovalo zisk.
Pak v roce 2015 jsme integrovali Voximplant. Toto řešení mělo potřebnou funkci sledování, kdo kolik mluví, a zároveň bylo výrazně levnější: s podmínkou nahrávání pouze zvuku to vyšlo na 20 rublů za lekci. Fungovalo to však pouze přes UDP, přepnout na TCP to neumělo. Přesto ho nakonec používalo kolem 40 % studentů.
Po roce jsme začali mít firemní klienty se svými specifickými požadavky. Například vše musí fungovat přes prohlížeč, v společnosti jsou otevřeny pouze http a https; t. j. žádné „Skype“ a UDP. Firemní klienti = peníze, proto jsme se vrátili k Tokboxu, ale problém s cenou nezmizel.
Řešení — WebRTC a Janus
Rozhodli jsme se použít . Ta zajišťuje navázání spojení, kódování a dekódování toků, synchronizaci stop a kontrolu kvality s řešením síťových problémů. Na naší straně musíme zajistit načítání toků z kamery a mikrofonu, vykreslování videa, správu spojení, nastavení WebRTC připojení a předávání mu toků, stejně jako předávání signálních zpráv mezi klienty pro navázání spojení (sám WebRTC popisuje pouze formát dat, nikoli mechanismus jejich přenosu). V případě, že se klienti nacházejí za NAT, WebRTC připojuje STUN servery, pokud to nepomáhá, pak TURN servery.
Obvyklé p2p spojení nám nestačí, protože chceme nahrávat lekce pro další analýzu v případě stížností. Proto posíláme toky WebRTC přes retranslátor . V důsledku toho klienti neznají adresy jeden druhého, vidí pouze adresu serveru Janus; ten zároveň plní funkce signálního serveru. Janus má mnoho požadovaných funkcí: automaticky přechází do TCP, pokud je UDP u klienta blokováno; umí nahrávat toky jak UDP, tak TCP; je škálovatelný; dokonce má vestavěný plugin pro echo testy. V případě potřeby se automaticky připojují STUN a TURN servery od Twilio.
V létě roku 2017 jsme měli v provozu dva servery Janus plus další server pro zpracování nahraných surových souborů audio a video, abychom nezatěžovali procesory hlavních. Při připojení byly servery Janus vybírány na základě principu sudý - lichý (číslo spojení). V té době to stačilo, podle našich pocitů to poskytovalo přibližně čtyřnásobné rezervy, míra implementace byla kolem 80. Cena se přitom snížila na ~2 rubly za lekci, plus vývoj a údržba.
Návrat k tématu videohovoru
Stále monitorujeme zpětnou vazbu od studentů a učitelů, abychom včas identifikovali a řešili problémy. K létu 2018 se kvalitní připojení stalo nejčastější stížností. Na jedné straně to znamenalo, že jsme úspěšně vyřešili jiné nedostatky. Na straně druhé bylo třeba okamžitě něco udělat: při přerušení lekce riskujeme ztrátu její hodnoty, někdy spolu se ztrátou hodnoty nákupu dalšího balíčku a při přerušení úvodní lekce dokonce ztrátu potenciálního klienta.
V té době byla naše videokomunikace stále v režimu MVP. Jinými slovy, spustili jsme to, fungovalo to, jednou jsme to rozšířili, pochopili jsme, jak to dělat – a to je skvělé. If it works, don’t fix it. Nikdo se cíleně nezabýval otázkou kvality připojení. V srpnu bylo jasné, že to takhle nemůže pokračovat, a spustili jsme samostatnou oblast, abychom zjistili, co vlastně není v pořádku s WebRTC a Janus.
Na začátku tato oblast dostala: řešení MVP, žádné metriky, žádné cíle, žádné procesy pro zlepšení a přitom 7% učitelů si stěžovalo na kvalitu připojení (nebyly žádné údaje o studentech).
Nová oblast se pustila do práce
Tým vypadá přibližně takto:
- Vedoucí oblasti, zároveň hlavní vývojář.
- QA pomáhají testovat změny, hledají nové způsoby, jak vytvářet nestabilní podmínky pro připojení a hlásí problémy z fronty.
- Analytik neustále hledá různé korelace v technických datech, zlepšuje analýzu zpětné vazby uživatelů a kontroluje výsledky experimentů.
- Produktový manažer pomáhá s celkovým směrem a alokací zdrojů pro experimenty.
- S vlastním programováním a souvisejícími úkoly často pomáhá druhý vývojář.
Na začátku jsme nastavili relativně spolehlivou metriku, která sledovala změny hodnocení kvality připojení (průměr přes dny, týdny, měsíce). V té době to byly hodnocení od učitelů, později se k nim přidala hodnocení od studentů. Dále jsme začali formulovat hypotézy, co nefunguje, opravovat a sledovat změny v dynamice. Šli jsme po snadných řešeních: například jsme vyměnili kodek vp8 za vp9, ukazatele se zlepšily. Zkoušeli jsme experimentovat s nastavením Janus, prováděli další experimenty, které většinou ničemu nepřivedly.
Ve druhé fázi se objevila hypotéza: WebRTC je peer-to-peer řešení, ale my používáme server uprostřed. Možná problém spočívá právě zde? Začali jsme to zkoumat a našli jsme zatím nejvýznamnější zlepšení.
V té době se server z poolu vybíral podle docela primitivního algoritmu: každý server měl svou „váhu“, která závisela na kanálu a výkonu, a my jsme se snažili poslat uživatele na ten, kde byla „váha“ vyšší, aniž bychom brali v úvahu geografickou polohu uživatele. Výsledkem bylo, že učitel z Petrohradu mohl komunikovat se studentem ze Sibiře přes Moskvu, místo aby použil náš Janus server v SPb.
Algoritmus byl přepracován: nyní, když uživatel otevře naši platformu, shromažďujeme pomocí Ajaxu pingi od něj do všech serverů. Při navazování spojení vybíráme dvojici pingů (učitel-server a student-server) s nejmenším součtem. Menší ping znamená menší síťovou vzdálenost k serveru; menší vzdálenost — nižší pravděpodobnost ztráty paketů; ztráta paketů je největší negativní faktor ve videokonferencích. Procento negativních zkušeností za tři měsíce kleslo na polovinu (pro objektivnost, v této době probíhaly i další experimenty, ale tento měl téměř jistě největší dopad).
Nedávno jsme objevili ještě jednu nečekanou, ale zjevně důležitou věc: místo jednoho výkonného serveru Janus na silném kanálu je lepší mít dva jednodušší s nižší propustností. K tomu jsme došli poté, co jsme zakoupili právě výkonné stroje s nadějí, že do nich nahrneme co nejvíce místností (komunikací) najednou. Servery mají limit propustnosti, který můžeme přesně převést na počet místností – víme, kolik jich můžeme otevřít například na 300 mbits/s. Jakmile je na serveru otevřeno příliš mnoho místností, přestáváme ho vybírat pro nové relace, dokud se zatížení nesníží. Myšlenka byla v tom, že když koupíme výkonný stroj, zatížíme kanál na maximum, abychom se dostali k procesoru a paměti, a ne k propustnosti. Ale ukázalo se, že po určitém počtu otevřených místností (420), přestože zatížení procesoru, paměti a disku je stále daleko od limitů, začíná chodit negativní zpětná vazba na technickou podporu. Zjevně se něco zhoršuje uvnitř Janus, možná tam také existují nějaká omezení. Začali jsme experimentovat, snížili jsme limit propustnosti z 300 na 200 mbits/s a problémy zmizely. Nyní jsme zakoupili hned tři nové servery s nízkými limity a parametry, myslíme si, že to povede k stabilnímu zlepšení kvality spojení. Rozplétat, co tam bylo špatně, jsme samozřejmě nechtěli, improvizace je to naše. K obraně říkáme, že v tu chvíli bylo potřeba co nejrychleji vyřešit aktuální problém, ne to udělat pěkně; navíc Janus je pro nás černá skříňka napsaná v C, dosahovat v ní je velmi nákladné.
A během toho jsme:
- aktualizovali všechny závislosti, které šlo aktualizovat, jak na serveru, tak na klientovi (to byly také experimenty, sledovali jsme výsledky);
- opravili všechny objevené chyby týkající se konkrétních případů, například když spojení spadlo a neobnovilo se automaticky;
- uskutečnili jsme množství schůzek s firmami pracujícími v oblasti videokomunikace a obeznámenými s našimi problémy: streamingovými hrami, organizujícími webináře; vyzkoušeli jsme všechno, co se nám zdálo užitečné;
- provedli jsme technickou revizi hardwaru a kvality spojení u učitelů, od kterých přicházely největší stížnosti.
Experimenty a následné změny umožnily snížit nespokojenost s komunikací mezi učiteli z 7,1 % v lednu 2018 na 2,5 % v lednu 2019.
Co dál
Stabilizace naší platformy Vimbox je jedním z hlavních projektů společnosti na rok 2019. Máme velká očekávání, že se nám podaří udržet dynamiku a více neuvidíme videokomunikaci na vrcholu stížností. Chápeme, že významná část těchto stížností souvisí se zpožděním počítačů a internetu uživatelů, ale musíme tuto část určit a vyřešit vše ostatní. Všechno ostatní je technický problém, se kterým bychom měli umět zacházet.
Hlavní složitostí je, že nevíme, na jakou úroveň je vůbec reálné zvýšit kvalitu. Zjištění této hranice je hlavním úkolem. Proto byly naplánovány dva experimenty:
- porovnat video přes Janus s běžným p2p v provozních podmínkách. Tento experiment byl již proveden, žádný statisticky významný rozdíl mezi naším řešením a p2p nebyl nalezen;
- nasadíme (drahé) služby od společností, které vydělávají výhradně na řešeních v oblasti videokomunikace, a porovnáme množství negativních reakcí od nich s těmi, které máme.
Tyto dva experimenty nám umožní určit dosažitelný cíl a soustředit se na něj.
Kromě toho existuje řada úkolů řešených v pracovním procesu:
- vytváříme technickou metrikou kvality spojení místo subjektivních hodnocení;
- vytváříme podrobnější logy relací, abychom přesněji analyzovali vzniklé poruchy, chápali, kdy a kde přesně k nim došlo, a jaké na první pohled nesouvisející události se v tu chvíli odehrály;
- připravujeme automatický test kvality spojení před lekcí a také dáme možnost klientovi ručně otestovat spojení, abychom snížili množství negativity způsobené jeho hardwarem a kanálem;
- vyvineme a budeme provádět více zátěžových testů videokomunikace v špatných podmínkách, s proměnlivým ztrátou paketů atd.;
- měníme chování serverů v případě problémů pro zvýšení odolnosti;
- budeme varovat uživatele, pokud má něco špatně se spojení, jak to dělá například 'Skype', aby chápal, že problém je na jeho straně.
Od dubna se oblast videokonferencí stává plnohodnotným samostatným projektem v rámci Skyeng, který se zabývá vlastním produktem, nikoli pouze součástí Vimboxu. To znamená, že začínáme hledat lidi na . A jako obvykle .
. A samozřejmě, nadále aktivně komunikujeme s lidmi a firmami, které se zabývají videokonferencemi. Pokud chcete vyměnit zkušenosti s námi — rádi vás uslyšíme! Komentujte, kontaktujte nás — odpovíme všem.
Zdroj: habr.com
