A videoconferência é o principal meio de comunicação entre professores e alunos na plataforma Vimbox. Abandonamos o Skype há muito tempo, testamos várias soluções de terceiros e, por fim, decidimos pela combinação WebRTC - Janus-gateway. Por um tempo, ficamos satisfeitos, mas algumas questões negativas continuaram surgindo. Como resultado, foi criada uma direção separada para o vídeo.
Pedi a Kirill Rogovoy, líder da nova direção, que falasse sobre a evolução da videoconferência na Skyeng, os problemas encontrados, as soluções e os imprevistos que acabamos aplicando. Esperamos que o artigo seja útil para empresas que também estão integrando vídeo em suas aplicações web.
Um pouco de história
No verão de 2017, o chefe de desenvolvimento da Skyeng, Sergey Safonov, apresentou na Backend Conf sobre como "abandonamos o Skype e implementamos o WebRTC". Aqueles que desejarem podem assistir à gravação da apresentação em (~45 min), e aqui vou resumir seu conteúdo.
Para a escola Skyeng, a videoconferência sempre foi a forma prioritária de comunicação professor-aluno. No início, utilizava-se o Skype, mas ele não atendia de maneira satisfatória por uma série de razões, principalmente pela falta de logs e a impossibilidade de integração diretamente na aplicação web. Portanto, realizamos várias experiências.
Essencialmente, nossos requisitos para a videoconferência eram aproximadamente os seguintes:
— estabilidade;
— baixo custo por aula;
— gravação das aulas;
— monitoração de quem fala mais (para nós, é importante que os alunos falem mais que os professores durante as aulas);
— escalabilidade linear;
— a possibilidade de usar tanto UDP quanto TCP.
O primeiro a ser tentado, em 2013, foi o Tokbox. Tudo estava bem, mas era muito caro - 113 rublos por aula - e isso consumia o lucro.
Depois, em 2015, integramos o Voximplant. Aqui havia a função necessária de monitoramento de quem fala mais, e a solução era significativamente mais barata: ao gravar apenas o áudio, saía a 20 rublos por aula. No entanto, funcionava apenas via UDP, não conseguia mudar para TCP. Mesmo assim, no final, cerca de 40% dos alunos utilizavam.
Depois de um ano, começamos a ter clientes corporativos com suas exigências específicas. Por exemplo, tudo deve funcionar através do navegador, na empresa estão disponíveis apenas http e https; ou seja, nada de 'Skypes' e UDP. Clientes corporativos = dinheiro, por isso voltamos para Tokbox, mas o problema do preço persistiu.
A solução — WebRTC e Janus
Decidimos usar . Ela gerencia a conexão, a codificação e decodificação dos fluxos, a sincronização das trilhas e o controle de qualidade com o tratamento de falhas de rede. De nossa parte, precisamos garantir a captura dos fluxos da câmera e do microfone, a renderização do vídeo, o gerenciamento da conexão, a configuração da conexão WebRTC e a transmissão de fluxos para ela, assim como a transmissão de mensagens de sinalização entre os clientes para estabelecer a conexão (o WebRTC em si descreve apenas o formato dos dados, mas não o mecanismo de transmissão). Caso os clientes estejam por trás de um NAT, o WebRTC conecta servidores STUN, e se isso não ajudar, servidores TURN.
Uma conexão p2p comum não é suficiente, pois queremos gravar as aulas para análise futura em caso de reclamações. Portanto, enviamos os fluxos WebRTC através de um retransmissor . Como resultado, os clientes não conhecem os endereços uns dos outros, vendo apenas o endereço do servidor Janus; este também desempenha as funções de servidor de sinalização. O Janus possui muitas funcionalidades que precisamos: muda automaticamente para TCP se o UDP do cliente estiver bloqueado; consegue gravar fluxos tanto em UDP quanto em TCP; é escalável; há até um plugin embutido para testes de eco. Se necessário, conectam-se automaticamente servidores STUN e TURN da Twilio.
No verão de 2017, operávamos com dois servidores Janus mais um servidor adicional para processar os arquivos brutos gravados de áudio e vídeo, para não sobrecarregar os CPUs dos principais. Na conexão, os servidores Janus eram escolhidos com base no princípio par-ímpar (número de conexão). Naquele momento, isso era suficiente e, segundo nossas percepções, oferecia uma margem de segurança de aproximadamente quatro vezes, com uma taxa de implementação em torno de 80. Com isso, o custo foi reduzido para cerca de 2 rublos por aula, além do desenvolvimento e manutenção.
Voltando ao tema da videoconferência
Estamos constantemente monitorando o feedback de alunos e professores para identificar e mitigar problemas a tempo. No verão de 2018, a qualidade da conexão se tornou a principal reclamação. Por um lado, isso significava que tínhamos lidado com outras deficiências. Por outro lado, era necessário agir rapidamente: com uma aula interrompida, corremos o risco de perder seu valor, às vezes junto com o valor da compra do próximo pacote, e com a interrupção de uma aula introdutória, corremos o risco de perder um cliente em potencial.
Naquela época, nosso sistema de videoconferência ainda estava em modo MVP. Em termos simples, lançamos, funcionou, escalamos uma vez, entendemos como fazer isso – e isso foi bom. If it works, don’t fix it. Ninguém estava focado na questão da qualidade da conexão. Em agosto, ficou claro que isso não poderia continuar, e lançamos uma nova equipe para entender o que estava errado com o WebRTC e o Janus.
Essa nova equipe começou com: solução MVP, sem métricas, sem objetivos, sem processos de melhoria, sendo que 7% dos professores reclamavam da qualidade da conexão (não havia dados sobre os alunos, também).
A nova equipe começa a trabalhar
A equipe se parece aproximadamente com isso:
- Líder da equipe, que também é o principal desenvolvedor.
- Os QA ajudam a testar as mudanças, buscam novas maneiras de criar condições instáveis para a conexão e relatam problemas da linha de frente.
- O analista busca constantemente diferentes correlações nos dados técnicos, melhora a análise do feedback dos usuários e verifica os resultados dos experimentos.
- O gerente de produto ajuda na direção geral e na alocação de recursos para experimentos.
- Outro desenvolvedor frequentemente ajuda com a programação e tarefas relacionadas.
Para começar, configuramos uma métrica relativamente confiável que monitorava mudanças nas avaliações da qualidade da conexão (média por dias, semanas, meses). Naquele momento, eram avaliações de professores, posteriormente adicionamos avaliações de alunos. Então, começamos a formular hipóteses sobre o que não estava funcionando, corrigir e observar as mudanças na dinâmica. Fomos pelos frutos mais fáceis: por exemplo, substituímos o codec vp8 pelo vp9, e os indicadores melhoraram. Tentamos ajustar as configurações do Janus, realizar outros experimentos – na maioria das vezes sem resultados.
Na segunda etapa, surgiu a hipótese: WebRTC é uma solução peer-to-peer, enquanto nós usamos um servidor no meio. Poderia a solução estar aqui? Começamos a investigar e encontramos a mais significativa melhoria até agora.
Naquele momento, o servidor era selecionado de um pool por um algoritmo bastante simples: cada um tinha seu próprio "peso", dependendo da largura de banda e potência, e tentávamos enviar o usuário para aquele com "peso" maior, sem prestar atenção em onde o usuário estava geograficamente. Como resultado, um professor de São Petersburgo podia se comunicar com um aluno da Sibéria através de Moscovo, e não pelo nosso servidor Janus em SPb.
Reformulamos o algoritmo: agora, quando o usuário abre nossa plataforma, coletamos pings de Ajax dele para todos os servidores. Ao estabelecer a conexão, escolhemos um par de pings (professor-servidor e aluno-servidor) com a menor soma. Menor ping significa menor distância de rede até o servidor; menor distância resulta em menor chance de perda de pacotes; a perda de pacotes é o maior fator negativo em comunicação por vídeo. A parte negativa caiu pela metade em três meses (para ser justo, outros experimentos foram realizados nesse período, mas este quase certamente teve o maior impacto).
Recentemente, descobrimos mais uma coisa não evidente, mas aparentemente importante: em vez de um servidor Janus poderoso em uma conexão robusta, é melhor ter dois servidores mais simples com uma largura de banda um pouco menor. Isso foi descoberto após adquirirmos essas máquinas potentes na esperança de acomodar o maior número possível de salas (sessões de comunicação) ao mesmo tempo. Os servidores possuem um limite de largura de banda, que podemos converter com precisão em um número de salas — sabemos quantas podem ser abertas, por exemplo, em 300 Mbps. Assim que muitas salas estão abertas no servidor, deixamos de utilizá-lo para novas sessões até que a carga diminua. A ideia era que, ao comprar uma máquina poderosa, carregaríamos a conexão ao máximo, para finalmente esbarrar no processador e na memória, e não na largura de banda. Mas percebemos que, após certo número de salas abertas (420), mesmo com a carga de CPU, memória e disco ainda longe dos limites, surgem reclamações na assistência técnica. Claramente, algo piora dentro do Janus, talvez existam limitações também lá. Começamos a experimentar, reduzimos o limite de largura de banda de 300 para 200 Mbps e os problemas desapareceram. Agora adquirimos três novos servidores com limites e especificações mais baixos, acreditamos que isso resultará em uma melhoria estável na qualidade da comunicação. Investigarmos o que realmente aconteceu não foi uma prioridade, improvisamos — essa é a nossa abordagem. Justificamos que naquele momento precisávamos resolver a questão de forma rápida, e não bonita; além disso, o Janus para nós é uma caixa-preta programada em C, mexer com isso é muito caro.
Assim, no processo, nós:
- atualizamos todas as dependências que podíamos atualizar, tanto no servidor quanto no cliente (também foram experimentos, monitoramos os resultados);
- corrigimos todos os bugs identificados relacionados a casos específicos, por exemplo, quando a conexão caía e não se recuperava automaticamente;
- realizamos uma série de reuniões com empresas que trabalham na área de videoconferência e estão familiarizadas com nossos problemas: que transmitem jogos, organizam webinars; testamos tudo o que nos pareceu útil;
- fizemos uma revisão técnica do hardware e da qualidade da comunicação com os professores de quem recebemos mais reclamações.
Os experimentos realizados e as mudanças 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 que conseguiremos manter a dinâmica e não veremos mais a videoconferência no topo das reclamações. Entendemos que uma parte significativa dessas reclamações está relacionada aos lags dos computadores e da internet dos usuários, mas precisamos identificar essa parte e resolver o restante. O resto é um problema técnico, parece que devemos ser capazes de lidar com isso.
A principal dificuldade é que não sabemos até que nível é realmente possível aumentar a qualidade. Determinar esse teto é a principal tarefa. Portanto, dois experimentos foram planejados:
- comparar o vídeo via Janus com o convencional p2p em condições reais de operação. Este experimento já foi realizado e nenhuma diferença estatisticamente significativa foi descoberta entre nossa solução e o p2p;
- testar (serviços caros) de empresas que lucram exclusivamente com soluções de videoconferência e comparar a quantidade de feedback negativo deles com a existente.
Esses dois experimentos nos permitirão determinar uma meta alcançável e nos concentrar nela.
Além disso, há uma série de tarefas sendo resolvidas no dia a dia:
- criamos uma métrica técnica de qualidade da comunicação em vez de depender de feedbacks subjetivos;
- produzimos logs de sessão mais detalhados para analisar mais precisamente as falhas que ocorrem, entendendo quando e onde exatamente aconteceram, e quais eventos aparentemente não relacionados ocorreram nesse momento;
- preparamos um teste automático de qualidade da comunicação antes da aula, e também daremos ao cliente a oportunidade de testar a comunicação manualmente, a fim de reduzir a quantidade de feedback negativo causado pelo seu hardware e canal;
- desenvolveremos e realizaremos mais testes de carga da videoconferência em condições adversas, com perda de pacotes variável, etc.;
- mudamos o comportamento dos servidores em caso de problemas para aumentar a resiliência;
- avisaremos o usuário se houver algo errado com a comunicação, assim como faz o 'Skype', para que ele entenda que o problema está do seu lado.
A partir de abril, a direção de videoconferência torna-se um projeto separado e completo dentro da Skyeng, focando em seu próprio produto, não apenas parte do Vimbox. Isso significa que começamos a buscar pessoas para . E como sempre .
. E, é claro, continuamos a nos comunicar ativamente com pessoas e empresas que trabalham com videoconferência. Se você quiser compartilhar experiência conosco — ficaremos felizes! Comente, entre em contato — responderemos a todos.
Fonte: habr.com
