A comunicação por vídeo é a principal forma de comunicação entre professor e aluno na plataforma Vimbox. Desistimos do Skype há muito tempo, tentamos várias soluções de terceiros e eventualmente optamos pela combinação WebRTC - Janus-gateway. Durante algum tempo ficamos satisfeitos com tudo, mas ainda assim alguns aspectos negativos continuaram a surgir. Como resultado, uma direção de vídeo separada foi criada.
Pedi a Kirill Rogovoy, chefe da nova direção, que falasse sobre a evolução da comunicação por vídeo na Skyeng, os problemas descobertos, as soluções e as muletas que finalmente utilizamos. Esperamos que o artigo seja útil para empresas que também criam vídeos por conta própria por meio de um aplicativo web.
Um pouco de história
No verão de 2017, o chefe de desenvolvimento do Skyeng, Sergey Safonov, falou na Backend Conf com uma história sobre como “abandonamos o Skype e implementamos o WebRTC”. Os interessados podem assistir à gravação do discurso em (~45 min), e aqui descreverei brevemente sua essência.
Para a Skyeng School, a videocomunicação sempre foi uma forma prioritária de comunicação entre professor e aluno. No início, foi utilizado o Skype, mas categoricamente não foi satisfatório por uma série de razões, principalmente devido à falta de logs e à impossibilidade de integração direta na aplicação web. Portanto, realizamos todos os tipos de experimentos.
Na verdade, nossos requisitos para comunicação por vídeo eram aproximadamente os seguintes:
— estabilidade;
— preço baixo por aula;
— gravação de aulas;
— acompanhar quem fala quanto (é importante para nós que os alunos falem mais do que o professor durante as aulas);
— escala linear;
- capacidade de usar UDP e TCP.
A primeira tentativa foi implementar o Tokbox em 2013. Tudo estava bem, mas acabou sendo muito caro - 113 rublos por aula - e consumiu o lucro.
Então, em 2015, a Voximplant foi integrada. Aqui estava a função que precisávamos para rastrear quem falava quanto e, ao mesmo tempo, a solução era muito mais barata: se apenas o áudio fosse gravado, custava 20 rublos por aula. No entanto, só funcionava via UDP e não podia mudar para TCP. Porém, cerca de 40% dos alunos acabaram utilizando.
Um ano depois, começamos a ter clientes corporativos com necessidades específicas. Por exemplo, tudo deve funcionar através de um navegador, a empresa só abre http e https; ou seja, sem Skype ou UDP. Clientes corporativos = dinheiro, então voltaram para a Tokbox, mas o problema do preço não desapareceu.
Solução - WebRTC e Janus
Decidi usar . É responsável por estabelecer uma conexão, codificar e decodificar fluxos, sincronizar trilhas e controlar a qualidade com tratamento de falhas de rede. De nossa parte, devemos garantir a leitura de streams da câmera e do microfone, a extração de vídeo, o gerenciamento da conexão, o estabelecimento de uma conexão WebRTC e a transmissão de streams para ela, bem como a transmissão de mensagens de sinalização entre clientes para estabelecer uma conexão (o próprio WebRTC descreve apenas o formato de dados, mas não seu mecanismo de transferência). Se os clientes estiverem atrás de NAT, o WebRTC conecta os servidores STUN; se isso não ajudar, os servidores TURN.
Uma conexão p2p regular não é suficiente para nós, pois queremos gravar aulas para posterior análise em caso de reclamações. Portanto, enviamos fluxos WebRTC através de um relé . Como resultado, os clientes não conhecem os endereços uns dos outros, vendo apenas o endereço do servidor Janus; ele também executa as funções de um servidor de sinal. Janus tem muitos dos recursos que precisamos: muda automaticamente para TCP se o cliente tiver o UDP bloqueado; pode gravar fluxos UDP e TCP; escalável; Existe até um plugin integrado para testes de eco. Se necessário, os servidores STUN e TURN da Twilio são conectados automaticamente.
No verão de 2017, tínhamos dois servidores Janus em execução, além de um servidor adicional para processamento de arquivos brutos de áudio e vídeo gravados, para não ocupar os processadores dos principais. Ao conectar, os servidores Janus foram selecionados de forma ímpar ou par (número de conexão). Naquela época isso bastava, segundo nossos sentimentos, dava uma margem de segurança aproximadamente quatro vezes maior, o percentual de implementação era de cerca de 80. Ao mesmo tempo, o preço foi reduzido para ~2 rublos por aula, mais desenvolvimento e suporte.
Voltando ao tópico da comunicação por vídeo
Monitoramos constantemente o feedback de alunos e professores para identificar e corrigir problemas em tempo hábil. No verão de 2018, a qualidade das chamadas estava firmemente em primeiro lugar entre as reclamações. Por um lado, isto significou que havíamos superado com sucesso outras deficiências. Por outro lado, era preciso fazer algo com urgência: se a aula fosse interrompida corremos o risco de perder o seu valor, às vezes junto com o custo de aquisição do próximo pacote, e se a aula introdutória fosse interrompida corremos o risco de perder um potencial cliente completamente.
Naquela época, nossa comunicação por vídeo ainda estava no modo MVP. Simplificando, eles lançaram, funcionou, escalaram uma vez, entenderam como fazer - bem, ótimo. Se funcionar, não conserte. Ninguém abordou deliberadamente a questão da qualidade da comunicação. Em agosto, ficou claro que isso não poderia continuar e lançamos uma direção separada para descobrir o que havia de errado com o WebRTC e o Janus.
Na entrada, essa direção recebeu: solução MVP, sem métricas, sem metas, sem processos de melhoria, enquanto 7% dos professores reclamam da qualidade da comunicação (também não havia dados sobre os alunos).
Uma nova direção está em andamento
O comando é mais ou menos assim:
- O chefe do departamento, que também é o principal desenvolvedor.
- O controle de qualidade ajuda a testar alterações, procura novas maneiras de criar condições de comunicação instáveis e relata problemas na linha de frente.
- O analista procura constantemente diversas correlações nos dados técnicos, melhora a análise do feedback do usuário e verifica os resultados dos experimentos.
- O gerente de produto ajuda na direção geral e na alocação de recursos para experimentos.
- Um segundo desenvolvedor geralmente ajuda na programação e nas tarefas relacionadas.
Para começar, configuramos uma métrica relativamente confiável que rastreou as mudanças nas avaliações de qualidade da comunicação (média ao longo de dias, semanas, meses). Naquela época, eram notas dos professores; posteriormente, notas dos alunos foram acrescentadas a elas. Então eles começaram a construir hipóteses sobre o que estava funcionando errado, corrigi-lo e observar as mudanças na dinâmica. Optamos pelo que está mais fácil: por exemplo, substituímos o codec vp8 pelo vp9, o desempenho melhorou. Tentamos brincar com as configurações do Janus e realizar outros experimentos - na maioria dos casos, eles não levaram a nada.
Na segunda etapa, surgiu uma hipótese: o WebRTC é uma solução peer-to-peer e usamos um servidor no meio. Talvez o problema esteja aqui? Começamos a cavar e encontramos a melhoria mais significativa até agora.
Naquele momento, um servidor do pool foi selecionado usando um algoritmo um tanto estúpido: cada um tinha seu “peso”, dependendo do canal e da potência, e tentamos enviar o usuário para aquele com maior “peso”, sem prestando atenção à localização geográfica do usuário. Como resultado, um professor de São Petersburgo poderia se comunicar com um aluno da Sibéria através de Moscou, e não através de nosso servidor Janus em São Petersburgo.
O algoritmo foi refeito: agora, quando um usuário abre nossa plataforma, coletamos pings dele para todos os servidores utilizando Ajax. Ao estabelecer uma conexão, selecionamos um par de pings (servidor-professor e servidor-aluno) com menor quantidade. Menos ping significa menos distância da rede até o servidor; distância mais curta significa menor probabilidade de perda de pacotes; A perda de pacotes é o maior fator negativo na comunicação por vídeo. A percentagem de negatividade caiu para metade em três meses (para ser justo, outras experiências foram realizadas nesta altura, mas esta quase certamente teve o maior impacto).
Recentemente descobrimos outra coisa não óbvia, mas aparentemente importante: em vez de um servidor Janus poderoso em um canal espesso, é melhor ter dois servidores mais simples com largura de banda menor. Isso ficou claro depois que compramos máquinas poderosas na esperança de amontoar o máximo de salas (sessões de comunicação) nelas ao mesmo tempo. Os servidores têm um limite de largura de banda, que podemos traduzir com precisão no número de salas – sabemos quantas podem ser abertas, por exemplo, a 300 Mbit/s. Assim que houver muitas salas abertas em um servidor, deixamos de escolhê-lo para novas atividades até que a carga diminua. A ideia era que, tendo comprado uma máquina potente, carregássemos o canal nela ao máximo, para que no final ficasse limitado pelo processador e pela memória, e não pela largura de banda. Mas descobriu-se que depois de um certo número de salas abertas (420), apesar de a carga do processador, memória e disco ainda estar muito longe dos limites, a negatividade começa a chegar ao suporte técnico. Aparentemente, algo está piorando dentro de Janus, talvez haja algumas restrições aí também. Começamos a experimentar, reduzimos o limite de largura de banda de 300 para 200 Mbit/s e os problemas desapareceram. Agora que compramos três novos servidores de uma só vez com limites e características baixas, pensamos que isso levará a uma melhoria estável na qualidade da comunicação. É claro que não tentamos descobrir o que estava acontecendo ali; nossas muletas são tudo. Em nossa defesa, digamos que naquele momento era necessário resolver o problema premente o mais rápido possível, e não fazê-lo lindamente; além disso, Janus para nós é uma caixa preta escrita em C, é muito caro mexer nela.
Bem, no processo nós:
- atualizou todas as dependências que poderiam ser atualizadas, tanto no servidor quanto no cliente (também foram experimentos, monitoramos os resultados);
- corrigidos todos os bugs identificados relacionados a casos específicos, por exemplo, quando a conexão caiu e não foi restaurada automaticamente;
- Realizamos muitas reuniões com empresas que trabalham na área de videocomunicações e familiarizadas com os nossos problemas: streaming de jogos, organização de webinars; tentamos tudo o que nos pareceu útil;
- Realizei uma revisão técnica do hardware e da qualidade da comunicação dos professores, de quem vieram mais reclamações.
As experiências e alterações posteriores permitiram reduzir a insatisfação com a comunicação entre os professores de 7,1% em janeiro de 2018 para 2,5% em janeiro de 2019.
Qual é o próximo
A estabilização da nossa plataforma Vimbox é um dos principais projetos da empresa para 2019. Temos grandes esperanças de que seremos capazes de manter o ímpeto e não ver mais a comunicação por vídeo nas principais reclamações. Entendemos que parte significativa dessas reclamações está relacionada a atrasos nos computadores e na Internet dos usuários, mas devemos apurar essa parte e resolver o restante. Todo o resto é um problema técnico, parece que devemos ser capazes de lidar com isso.
A principal dificuldade é que não sabemos até que ponto é realmente possível melhorar a qualidade. Descobrir esse teto é a tarefa principal. Portanto, dois experimentos foram planejados:
- compare o vídeo via Janus com p2p normal em condições de combate. Este experimento já foi realizado, nenhuma diferença estatisticamente significativa foi encontrada entre nossa solução e p2p;
- Vamos fornecer serviços (caros) de empresas que ganham dinheiro exclusivamente com soluções de videocomunicação e comparar a quantidade de negatividade delas com a existente.
Esses dois experimentos nos permitirão identificar uma meta alcançável e focar nela.
Além disso, há uma série de tarefas que podem ser resolvidas rotineiramente:
- Criamos uma métrica técnica de qualidade da comunicação em vez de avaliações subjetivas;
- Fazemos logs de sessão mais detalhados para analisar com mais precisão as falhas que ocorrem, entender quando e onde exatamente elas ocorreram e quais eventos aparentemente não relacionados ocorreram naquele momento;
- Preparamos um teste automático de qualidade de conexão antes da aula, e também damos ao cliente a oportunidade de testar manualmente a conexão para reduzir a quantidade de negatividade causada por seu hardware e canal;
- desenvolveremos e realizaremos mais testes de carga de comunicação de vídeo em condições precárias, com perda variável de pacotes, etc.;
- alteramos o comportamento dos servidores em caso de problemas para aumentar a tolerância a falhas;
- Avisaremos o usuário se houver algum problema com sua conexão, como faz o Skype, para que ele entenda que o problema está do seu lado.
Desde abril, a direção de comunicação de vídeo tornou-se um projeto separado de pleno direito dentro da Skyeng, lidando com seu próprio produto, e não apenas com uma parte do Vimbox. Isso significa que estamos começando a procurar pessoas em . Bem, como sempre .
E, claro, continuamos a comunicar ativamente com pessoas e empresas que trabalham com videocomunicações. Se você quiser trocar experiências conosco, teremos o maior prazer! Comente, entre em contato - responderemos a todos.
Fonte: habr.com