Utilizamos tecnologia webRTC para comunicação de áudio e vídeo, em um projeto muito simples, onde seria possível criar uma sala em uma determinada URL, e duas pessoas conseguiam acessar a mesma URL e se ver e ouvir.

A tecnologia webrtc é bem recente, e a especificação só foi para o estágio “Recomendada” pelo W3C em 2021. Ela estabelece um protocolo de troca de dados, áudio e vídeo pela web.

Essa tecnologia pode ser utilizada de algumas maneiras diferentes, sendo as mais utilizadas:

• • Peer to peer (P2P) – As pessoas em uma sala de reunião se comunicam diretamente, sem trafegar os dados de áudio e vídeo por um servidor.
  • Usando um media server – Todos os participantes da sala enviam seu áudio e vídeo para um servidor, que então distribuí para os outros participantes.

Na nossa prova de conceito, iniciamos com conexões P2P, porém não foi possível avançar deste modo. Apesar de ter um custo de operação mais baixo por não precisar de servidores de mídia, essa solução não possibilita a gravação em servidores, dado que a transmissão de mídia não passa por servidor nenhum.

Precisamos então seguir para a abordagem de usar algum media server open source. Encontramos algumas alternativas: Kurento, Jitsi e Janus. Implementamos a primeira versão utilizando da nossa sala utilizando o Kurento.

Em 2 meses de projeto, tivemos um resultado satisfatório, com uma sala 100% funcional e com as reuniões sendo gravadas.  

Viabilidade técnica? Check!

Ok, conseguimos criar a tecnologia, mas vale a pena?

Para responder esta pergunta, precisamos entender dois principais fatores.

• • Custo com servidores
  • Custo com tráfego

Para entender estes pontos, precisamos saber quantas reuniões cada servidor é capaz de rodar em paralelo, e medir todo o tráfego de dados para conseguir entender quais seriam os custos de cloud.

Para isso criamos um subprojeto de teste de carga, que criava diversas salas de reunião, e acessava com vários navegadores abertos, transmitindo o vídeo gravado de uma webcam 720p, tudo isso utilizando o Selenium como tecnologia.

Subimos nossos servidores na Amazon AWS e também instâncias para serem “clientes” da sala de reunião, rodando nossos testes de carga.

Neste momento tivemos a primeira surpresa. Salas gravadas usando o Kurento como media server eram muito pesadas! Um servidor com duas CPUs e 4GB de ram conseguiria rodar apenas 4 reuniões em paralelo.

Para cumprir nosso objetivo de 300 reuniões simultâneas precisaríamos de cerca de 75 servidores.

De volta à estaca zero, tivemos que substituir o nosso media server escolhido. Em duas semanas estudamos os concorrentes do Kurento, escolhemos o Janus como alternativa, e implementamos todas as mudanças necessárias.

Rodamos o nosso teste de carga com o Janus e… Bingo! Com o mesmo servidor rodamos 114 reuniões simultâneas.

Custo com servidores? Check.

Com este estudo, identificamos que o projeto é viável financeiramente, porém ainda assim há margem para melhorias.

Estudamos diversos servidores de cloud, para entender os custos com tráfego, já que este poderia ser o maior custo para um projeto com essa escala.

Avaliamos os seguintes fornecedores:

• • Amazon AWS
  • Azure
  • Digital Ocean
  • Oracle cloud
  • E alguns provedores nacionais.

Como o maior requisito para que este projeto opere bem é link (upload e download), dado o massivo volume de dados que será trafegado, acabamos eliminando os provedores nacionais, pois eles não entregavam link rápido o suficiente.

Após profundo estudo da forma de cobrança e dos preços, decidimos implantar este projeto na Oracle Cloud, por possuir o menor custo por GB trafegado e também por oferecer 10 TB de tráfego gratuitamente todo mês.

De qualquer forma, para evitar o lock-in com alguma cloud, implementamos toda nossa solução de deploy com o Kubernetes, pois desta forma poderíamos migrar para uma cloud mais barata com facilidade caso os preços fossem reajustados.

Viabilidade econômica? Check.

O maior desafio deste tipo de projeto. Escalar este tipo de solução é muito mais difícil que escalar soluções web por alguns fatores:

• • As pessoas de uma mesma sala precisam ser direcionadas para o mesmo servidor.
  • Não podemos fazer um scale-down de um servidor se houver uma reunião acontecendo nele.
  • Estratégias padrão de distribuição de carga não funcionam neste tipo de solução, Ex: Round robin

Para conseguir fazer essa solução escalar, precisamos criar um mecanismo inventivo. Separamos nossa aplicação em alguns micro-serviços, sendo que o que nos permite escalabilidade é o agendador.

O agendador é um serviço que cria as salas de reunião no servidor adequado, e direciona todas as pessoas que tentam acessar a reunião para o mesmo servidor.

Para manter este mecanismo simples, utilizamos um pattern utilizado na própria implementação do Kubernetes, o Leader-elector.

Como funciona? O Agendador sempre direciona todas as reuniões para um único servidor de mídia: O servidor líder.

Assim o agendador pode ser simples e não precisa conhecer todos servidores que estão no ar. Toda vez que uma nova reunião precisa ser criada, ele cria no líder.

Toda vez que alguém quer acessar uma reunião em que já existe sala, o agendador consulta em qual servidor a reunião foi agendada, e redireciona o usuário.

Mas como sabemos quem é o líder?

Nós codificamos uma imagem docker de leader-elector. O leader-elector é um job em nodejs que fica competindo pela liderança. Este job roda como um sidecar do media server, para registrar o ip do media server como líder sempre que ele assume a liderança.

Criamos alguns critérios para decidir quem assume a liderança.

• • Uma instância pode se tornar líder quando possui pelo menos 70% de CPU livre, e o líder atual não renovou sua liderança.
  • Líderes renovam sua liderança se tiverem com uso de cpu abaixo de 85%.

O scaling da cloud sobe um servidor de media-server que irá competir pela liderança sempre que a média de uso de CPU maior que 70%, assim garantimos que todas reuniões serão agendadas instantaneamente, pois quando for necessário um novo media server, ele já está no ar.

Este mecanismo permite que os líderes se alternem se for necessário, e um novo líder recebe todas as reuniões novas, permitindo que o líder antigo seja desligado caso todas as reuniões nele sejam finalizadas, e não haja mais a necessidade de servidor extra.

Escalabilidade? Check!