As videochamadas são a principal forma de comunicação entre professores e alunos na plataforma Vimbox. Abandonamos o Skype há muito tempo, tentamos várias soluções de terceiros e, finalmente, decidimos por um monte de WebRTC - Janus-gateway. Por um tempo, tudo correu bem conosco, mas alguns pontos negativos continuaram a surgir. Como resultado, uma direção de vídeo separada foi criada.
Pedi a Kirill Rogovoy, chefe da nova direção, para falar sobre a evolução das comunicações por vídeo em Skyeng, os problemas, soluções e muletas que eventualmente aplicamos. Esperamos que este artigo seja útil para empresas que também fazem vídeos por meio de um aplicativo da web.
Um pouco de história
No verão de 2017, Sergey Safonov, chefe de desenvolvimento da Skyeng, falou no Backend Conf sobre como "abandonamos o Skype e implementamos o WebRTC". Quem desejar pode ver a gravação da performance por referência (~ 45 min), mas aqui descreverei brevemente sua essência.
Para a Skyeng, a comunicação por vídeo sempre foi um método prioritário de comunicação professor-aluno. No início, o Skype era usado, mas categoricamente não era adequado por várias razões, principalmente devido à falta de logs e à incapacidade de integrar diretamente no aplicativo da web. Portanto, realizamos todos os tipos de experimentos.
Na verdade, os requisitos para comunicação por vídeo eram aproximadamente os seguintes:
- estabilidade;
- preço baixo por aula;
- aulas de gravação;
- rastrear quem diz quanto (é importante para nós que os alunos falem mais na sala de aula que o professor);
- escala linear;
- A capacidade de usar UDP e TCP.
O primeiro em 2013 tentou implementar o Tokbox. Tudo estava bem, mas ficou muito caro - 113 rublos por aula - e consumiu o lucro.
Então, em 2015, o Voximplant foi integrado. Aqui estava a função de rastreamento de que precisávamos, que diz quanto e, ao mesmo tempo, a solução era muito mais barata: desde que apenas o som fosse gravado, 20 rublos por lição eram lançados. No entanto, funcionou apenas através do UDP; mudar para o TCP não era uma habilidade. No entanto, no final, cerca de 40% dos estudantes o usaram.
Um ano depois, os clientes corporativos começaram a aparecer com seus requisitos específicos. Por exemplo, tudo deve funcionar através de um navegador, apenas http e https estão abertos na empresa; isto é, sem Skype e UDP. Clientes corporativos = dinheiro, então eles retornaram à Tokbox, mas o problema dos preços não desapareceu.
Solução - WebRTC e Janus
Decidimos usar a plataforma do navegador para WebRTC de comunicação de vídeo ponto a ponto . Ela é responsável por estabelecer conexões, codificar e decodificar fluxos, sincronizar trilhas e controle de qualidade com falhas na rede de processamento. Da nossa parte, devemos garantir que os fluxos da câmera e do microfone sejam lidos, que o vídeo seja desenhado, que a conexão seja estabelecida, que a conexão WebRTC seja estabelecida e que os fluxos sejam transmitidos a ela, bem como a transmissão de mensagens de sinal entre os clientes para estabelecer a conexão (o próprio WebRTC descreve apenas o formato dos dados, mas não o mecanismo deles). transmissão). Caso os clientes estejam atrás do NAT, o WebRTC conecta os servidores STUN, se isso não ajudar, os servidores TURN.
A conexão p2p usual não é suficiente para nós, porque queremos registrar lições para uma análise mais aprofundada em caso de reclamações. Portanto, enviamos fluxos WebRTC através do repetidor Janus Gateway do Meetecho . Como resultado, os clientes não sabem os endereços um do outro, vendo apenas o endereço do servidor Janus; Ele também executa as funções de um servidor de sinal. O Janus possui muitos recursos que precisamos: ele muda automaticamente para o TCP se o UDP estiver bloqueado no cliente; capaz de gravar fluxos de UDP e TCP; escalável; existe até um plug-in embutido para testes de eco. Se necessário, os servidores STUN e TURN do Twilio são conectados automaticamente.
No verão de 2017, tínhamos dois servidores Janus, além de um servidor adicional para o processamento de arquivos de áudio e vídeo brutos gravados, para não ocupar os principais processadores. Ao conectar, os servidores Janus foram selecionados com base no número ímpar de conexões (número da conexão). Naquele momento, isso era suficiente, de acordo com nossos sentimentos, fornecia cerca de quatro vezes a margem de segurança, o percentual de implementação era de cerca de 80. Ao mesmo tempo, o preço caiu para ~ 2 rublos por aula, além de desenvolvimento e suporte.
Voltar ao tópico de vídeo chamada
Monitoramos constantemente o feedback de alunos e professores, a fim de identificar e parar os problemas a tempo. No verão de 2018, em primeiro lugar entre as reclamações, a qualidade da comunicação estava entrincheirada com confiança. Por um lado, isso significava que havíamos lidado com sucesso com outras deficiências. Por outro lado, havia uma necessidade urgente de fazer algo: se a lição for perdida, corremos o risco de perder seu custo, às vezes juntamente com o custo de compra do próximo pacote, e se a lição introdutória for perdida, perdemos o cliente em potencial.
Naquela época, a comunicação por vídeo ainda estava no modo MVP. Simplificando, eles lançaram, funcionaram, redimensionaram uma vez, descobriram como fazê-lo - bem, isso é legal. Se funcionar, não conserte. Ninguém deliberadamente lidou com a questão da qualidade da comunicação. Em agosto, ficou claro que isso não poderia continuar mais e lançamos uma área separada para descobrir o que estava acontecendo 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 é tomada para o trabalho
O comando é mais ou menos assim:
- O chefe da direção, ele é o principal desenvolvedor.
- O controle de qualidade ajuda a testar mudanças, procura novas maneiras de criar condições instáveis para a comunicação, relata problemas pela linha de frente.
- O analista está constantemente procurando diferentes correlações nos dados técnicos, melhora a análise do feedback do usuário, verifica os resultados das experiências.
- O gerente de produto ajuda na direção geral e na alocação de recursos para experimentos.
- Com a programação em si e tarefas relacionadas, um segundo desenvolvedor geralmente ajuda.
Para começar, configuramos uma métrica relativamente confiável que rastreia as alterações na avaliação da qualidade da comunicação (média por dias, semanas, meses). Naquela época, essas eram notas de professores e outras notas de alunos foram adicionadas a elas. Então eles começaram a construir hipóteses do que não está funcionando, para corrigir e observar as mudanças na dinâmica. Optamos por frutas pouco exigentes: por exemplo, substituímos o codec vp8 pelo vp9, o desempenho melhorou. Tentamos brincar com as configurações do Janus, realizar outras experiências - na maioria dos casos, sem sucesso.
No segundo estágio, surgiu uma hipótese: o WebRTC é uma solução ponto a ponto e usamos o servidor no meio. Talvez o problema esteja aqui? Eles começaram a cavar e encontraram aqui a melhoria mais significativa até agora.
Naquele momento, o servidor do pool foi selecionado de acordo com um algoritmo bastante estúpido: cada um tinha seu próprio "peso", dependendo do canal e da potência, e tentamos enviar o usuário para aquele em que o "peso" é maior, sem prestar atenção à localização geográfica do usuário. . Como resultado, um professor de São Petersburgo poderia se comunicar com um estudante da Sibéria por meio de Moscou, e não através do nosso servidor Janus em São Petersburgo.
O algoritmo foi refeito: agora, quando o usuário abre nossa plataforma, usamos o Ajax para coletar pings dele em todos os servidores. Ao estabelecer uma conexão, selecionamos um par de pings (professor-servidor e aluno-servidor) com a menor quantidade. Menos ping - menos distância da rede do servidor; menor distância - menor chance de perda de pacotes; a perda de pacotes é o maior fator negativo nas chamadas de vídeo. A parcela de negatividade caiu duas vezes em três meses (para ser justo, outros experimentos também foram realizados nesse período, mas este quase certamente afetou mais).
Recentemente, descobrimos outra coisa não óbvia, mas aparentemente importante: em vez de um poderoso servidor Janus em um canal espesso, dois são mais simples, com uma largura de banda melhor. Isso aconteceu depois que compramos máquinas poderosas na esperança de encher o maior número possível de salas (sessões de comunicação) 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 quanto você pode abrir, por exemplo, a 300 Mbps. Assim que muitas salas estiverem abertas no servidor, paramos de escolhê-la para novas atividades até que a carga diminua. A idéia era que, depois de comprar uma máquina poderosa, carregaremos o canal ao máximo para que, no final, repouse no processador e na memória, e não na largura de banda. Porém, depois de um certo número de salas abertas (420), apesar de a carga no processador, memória e disco ainda estar muito longe dos limites, a negatividade começa a se transformar em suporte técnico. Aparentemente, algo está piorando dentro de Janus, talvez haja algumas restrições também. Eles começaram a experimentar, reduziram o limite de largura de banda de 300 para 200 Mbps, os problemas desapareceram. Agora que compramos três novos servidores ao mesmo tempo com baixos limites e características, acreditamos que isso levará a uma melhoria estável na qualidade da comunicação. É claro que não começamos a descobrir qual era o problema, as muletas eram nossas. Em nossa defesa, dizemos que naquele momento era necessário resolver o problema urgente o mais rápido possível, e não fazê-lo lindamente; Além disso, Janus é uma caixa preta para nós, escrita em C, e é muito caro cavá-la.
Bem, no processo, nós:
- atualizou todas as dependências que poderiam ser atualizadas, tanto no servidor quanto no cliente (essas também foram experiências, acompanhadas do resultado);
- corrigidos todos os erros identificados relacionados a casos específicos, por exemplo, quando a conexão caiu e não foi restaurada automaticamente;
- tivemos muitas reuniões com empresas que trabalham no campo das comunicações por vídeo e familiarizadas com nossos problemas: jogos em fluxo, webinars de host; testou tudo o que parecia útil para nós;
- realizaram uma revisão técnica do ferro e a qualidade da comunicação com os professores, de onde vieram as queixas.
As experiências e as alterações subsequentes 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.
O que vem a seguir
A estabilização da nossa plataforma Vimbox é um dos principais projetos da empresa para 2019. Temos grandes esperanças de conseguir manter o ritmo e não ver mais a comunicação por vídeo nas principais reclamações. Entendemos que uma parte significativa dessas reclamações está relacionada aos atrasos dos computadores e à Internet dos usuários, mas devemos determinar essa parte e resolver todo o resto. Tudo o resto é um problema técnico, parece que deveríamos ser capazes de lidar com isso.
A principal dificuldade é que não sabemos em que nível é geralmente realista melhorar a qualidade. O esclarecimento desse teto é a principal tarefa. Portanto, dois experimentos foram planejados:
- Compare o vídeo via Janus com o p2p comum em combate. Esse experimento já foi realizado; não foi encontrada diferença estatisticamente significante entre nossa solução e p2p;
- forneceremos serviços (caros) de empresas que ganham exclusivamente em soluções de comunicação por vídeo e compararemos a quantidade negativa deles com a existente.
Esses dois experimentos nos permitem determinar um objetivo alcançável e nos concentrar nele.
Além disso, existem várias tarefas resolvidas na ordem de trabalho:
- criamos uma métrica técnica de qualidade da comunicação em vez de análises subjetivas;
- fazemos registros de sessão mais detalhados para analisar com mais precisão as falhas ocorridas, para entender quando e onde exatamente elas ocorreram, que eventos aparentemente não relacionados ocorreram naquele momento;
- estamos preparando um teste automático da qualidade da comunicação antes da aula e também permitiremos que o cliente teste manualmente a conexão, a fim de reduzir a quantidade de negativos causados por seu ferro e canal;
- Vamos desenvolver e conduzir mais testes de estresse de comunicações por vídeo em condições precárias, com perda de pacotes variável, etc;
- Alteramos o comportamento dos servidores em caso de problemas para aumentar a tolerância a falhas;
- avisaremos o usuário se ele tiver algo errado com a conexão, como o mesmo Skype faz, para que ele entenda que o problema está do seu lado.
Desde abril, a direção de comunicação por vídeo tornou-se um projeto separado dentro da Skyeng, envolvido em seu próprio produto, não apenas uma parte da Vimbox. E isso significa que estamos começando a procurar pessoas para trabalhar com vídeo no modo de tempo integral . Bem, como sempre, estamos procurando muitas pessoas boas .
Bem, é claro, continuamos a nos comunicar ativamente com pessoas e empresas que trabalham com comunicações por vídeo. Se você deseja trocar experiência conosco, ficaremos felizes! Comente, entre em contato - responderemos a todos.