O Edgemesh é um acelerador web P2P baseado no protocolo WebRTC. Ele alivia parte do tráfego normalmente tratado pelos CDNs tradicionais, usando caches do navegador através de uma rede P2P.
Eles liberaram a versão de produção nos últimos meses e compartilharam um pouco da experiência deles.
A tecnologia do Edgemesh depende de uma rede sobreposta que é criada pelos navegadores dos usuários finais usando o protocolo WebRTC. Os CDNs tradicionais distribuem seus servidores ao redor do globo para servir o conteúdo de acordo com a proximidade e assim diminuir a latência para os usuários finais. O Edgemesh, por sua vez, faz um cache do conteúdo no navegador do usuário, assim como os navegadores fazem, mas em uma camada secundária, e também permite que os navegadores conversem entre si para servir o conteúdo ao invés de buscá-lo em um CDN. Habilitar o Edgemesh envolve incluir um trecho de código Javascript na página. Em produção, isso significa que o Javascript client side do Edgemesh pode estar potencialmente em centenas de navegadores, ao redor de múltiplas regiões.
O Edgemesh usa containers de Docker como unidade básica de deploy. A infraestrutura roda na nuvem pública do Joyent rodando SmartOS, usando servidores físicos ao invés de máquinas virtuais. Para gerenciar os containers , ele utiliza o padrão Joyent Autopilot o que permite que o container tenha um alto nível de autonomia operacional. O banco de dados roda dentro do container utilizando o Triton. Informação sobre o estados, como arquivos da base de dados, arquivos de log e etc, são armazenados de forma estável com Joyent Manta contando com um backup secundário no Google Storage Platform.
O time de engenharia identificou alguns desafios primários antes de ir para produção em 1º de abril. Nestes desafios estão incluídos a habilidade em debugar erros em produção sem o input do clientes, lançar updates automáticos em janelas de tempo limitada, uma malha através de 500 redes, descarregar até 1 TB de dados na malha e abrangendo 50 países. Em 26 de maio, eles habilitaram todo tráfego pela malha. Após uma semana, mais de meio terabyte oriundo dos clientes para os servidores de origem foi diluído na malha, e o tempo médio de carregamento da página para o cliente final diminuiu em 33%. As métricas são continuamente monitoradas, incluindo o tamanho da malha e também o tempo de carregamento das páginas individualmente. Quando um cliente do Edgemesh recebe um erro, ele sai de cena e permite que o navegador reassuma as operações normais. Os dados do erro são coletados e reportados para a equipe do Edgemesh para análise.
Nos bastidores, a equipe usou três pontos como princípios orientadores para a implantação de seu software em produção. Os dois primeiros consistem em manter a consistência via automação e redução da superfície de ataque de entidades maliciosas por recriando periodicamente suas infraestruturas. A terceira, a escala econômica, começando a partir da infração menor possível, sendo esta uma consequência das duas primeiras.
O InfoQ entrou em contato com Jacob Loveless, CEO da Edgemesh, para entender mais sobre os desafios de DevOps enquanto colocavam o sistema em produção. Começamos perguntando que tipo de ferramentas de monitoração foi usada na infraestrutura de Docker. Loveless respondeu:
Usamos o Prometheus para estatísticas do sistema e temos um sistema interno que emite coisas como erros e tipos de mensagem (por exemplo: estatísticas do WebRTC dos clientes). Essas métricas são usadas para ajudar a determinar quando uma aplicação deve ser escalada.
Devido a natureza distribuída do Edgemesh em que a maior parte do código está no lado do cliente, garantir a saúde pré-produção é um desafio chave. Loveless explicou mais sobre seu ambiente de staging (pré-produção):
Temos um plataforma padrão para CI/CD em que fazemos nossas builds de Docker a fazemos deploy em ambiente de desenvolvimento. Quando chegamos ao ambiente de "staging" marcamos a imagem com uma tag staging, e essa imagem é posta no ar em um "estado limpo". Temos um data center que roda nossa pré-produção e esta atende aproximadamente 10% do tráfego global daquele data center. Quando nos sentimos confortáveis com o ambiente de pré-produção, modificamos a tag da imagem Docker para "master" a colocamos no ar em todos os data centers. Se precisamos realizar um rollback, simplesmente mudamos as tags das imagens Docker nos registros e tudo será resetado. Então, basicamente fazemos deploys todos os dias, mas na maioria das vezes não é uma versão nova. Diria que temos uma nova versão completa no ar entre 5 e 10 dias.
O "estado limpo" referido acima é a maneira que o Edgemesh faz para recriar seus contêineres todos os dias. Isso garante que eles irão se manter fiéis aos três princípios de deploy.
Permitindo que o ambiente de pré-produção receba dados de produção, atrelado a um mecanismo fácil de rollback, o Edgemesh simula parte da carga de produção e padrões de navegação que o código irá enfrentar quando for para o ar. Entretanto, isso normalmente não é suficiente, então, segundo Loveless, a estratégia consiste em "garantir que possamos mudar as versões do software em produção rapidamente".
Parte da estratégia de "estado limpo" é o reset diário do tamanho das instâncias que escalaram para seu tamanho original. Isso ocorre em um datacenter de cada vez. Se o datacenter está com um tráfego alto e o estado inicial não consegue lidar após o reinício, o Edgemesh deve garantir que o cliente não verá erros. Loveless explica como atingir esse objetivo:
Quando o datacenter A iniciar a restauração para o estado limpo, a primeira coisa que ele faz é se descadastrar das entradas de DNS. Nosso registros de DNS rodam com baixo TTLs (30 segundos) e uma pausa de cinco minutos garante que todo o tráfego seja redirecionado para B e C. Depois de cinco minutos, o datacenter A inicia em estado limpo. Quando ele volta a estar conectar, ele se registra novamente nos servidores DNS. Assim que ele começa a receber tráfego o datacenter B inicia a sua restauração para o estado limpo (B inicia quando A enviar uma mensagem avisando para B que ele está conectado novamente e recebendo tráfego). Durante a transição, os datacenters B e C irão escalar para lidar com o tráfego adicional.