Desafio – Em 2020, durante a pandemia CoVid-19, a demanda pelo serviço de videoconferência criptografado de 8×8 aumentou exponencialmente em todo o mundo- saltando de 20 servidores virtuais para 8.000 em questão de semanas. Embora o trabalho que um roteador de vídeo de 8×8 faça é simples o suficiente para explicar, na verdade é bastante intensivo em CPU.
Escalar esse sistema significava implantar mais servidores na nuvem. Os servidores 8×8 estavam sofrendo com o mesmo número de gargalos de desempenho da rede em questão de horas, pois seus engenheiros esperavam ter lidado ao longo de um ano inteiro.
“Geralmente, quando algo dá errado, uma máquina ficava sobrecarregada, haveria muita demanda na CPU, e não haveria trabalho suficiente para tirar pacotes de filas quando chegaram”, explicou Emil Ivov, de 8×8. O resultado desses problemas foi o aumento da latência que se tornou visível para os usuários e, com mais urgência, um enorme aumento no custo do serviço em nuvem.
Solução – Para reduzir os custos, 8×8 investiram na Oracle Cloud Infrastructure (OCI). O OCI ofereceu 8×8 uma instância ARM64 OCI mais barata alimentada pelas CPUs AMPERE® ALTRA®. Com pouco tempo de sobra, 8×8 aposta e começou a refatorar Jitsi para a mudança para a microarquitetura ARM64 – um movimento que temia que seria árduo e montado com incidentes. A maior parte do código crítico para JITSI é escrito em Java, exigindo que as interfaces JNI para as bibliotecas de criptografia de código de máquina nativas e outras bibliotecas que precisavam ser recompiladas.
Felizmente para 8×8, devido às bibliotecas ARM64 já existentes, realocando todo o seu código JITSI para o ARM64 exigia um trabalho mínimo de seus desenvolvedores, todos concluídos em um dia. Além disso, os scripts de automação para o lançamento de novas instâncias de máquinas virtuais tiveram que ser novamente ajustadas para instâncias do ARM64-equivalente a mais alguns dias.
Resultados – Depois de se mudar para as instâncias do ARM64 baseado em Ampere, o 8×8 atingiu seu objetivo de atingir o Jitsi ou exceder um P95 de 1 ms. Isso significava que o desempenho diário deve ver transações de pacotes consumindo menos de um milissegundo e um P99 de 5 ms.
De uma perspectiva de custo, as instâncias do ARM64 da OCI eram até 30 % menos caras por instância do que as instâncias que eles estavam usando antes. Além disso, as instâncias do ARM64 baseadas em Ampere ofereceram um desempenho 30 % maior, novamente de acordo com Ivov-“uma melhoria muito substancial”. Cada instância do ampere estava fazendo 20 a 30% mais de trabalho, no mesmo tamanho, em comparação com antes da migração. Disse, Ivov, “não há reticência na adoção de casos de amperes. Eles são sempre a primeira opção que olhamos”.
História do desenvolvedor
Após a Covid aumentou a demanda por ferramentas de comunicação on-line para extremos insondados, um dos maiores projetos de telecomunicações de código aberto do mundo mudou seus serviços para instâncias do ARM64 movidas a amperes na OCI. Essa decisão está pagando grandes dividendos.
Em 2020, quando a pandemia covid-19 transformou a cultura do trabalho em todo o mundo, o provedor de soluções de videoconferência 8×8 experimentou picos de tráfego colossal por seu serviço de comunicação de vídeo criptografado.
Antes do início da pandemia, os roteadores de vídeo para serviços de videoconferência de 8×8 foram executados em 20 servidores virtuais. Uma semana depois, eles estavam consumindo 80 instâncias. Seis semanas depois, esse número cresceu para 8.000. Com a economia global abalada em seu núcleo, o 8×8 se viu de repente servindo como um backbone global de telecomunicações.
No centro dos serviços de videoconferência da 8×8, havia um projeto de código aberto construído sobre o andaime de um projeto estudantil da Universidade de Estrasburgo chamado SIP Communicator. Desde então havia sido recristalizado jitsiapós a palavra búlgara para “fios”. Jitsi agora está absorvendo recursos suficientes de computação em nuvem que consomem energia para alimentar uma pequena cidade.
Anatomia de uma sobrecarga
Embora o trabalho que um roteador de vídeo de 8×8 faça é simples o suficiente para explicar, na verdade é bastante intensivo em CPU. Como um quadro de interruptor, um servidor lê pacotes de dados de um soquete, descriptografar -os, criptografa -os novamente e copia os pacotes criptografados para outros soquetes a serem encaminhados. Escalar esse sistema significava implantar mais servidores na nuvem. Parecia um plano de escalabilidade bastante simples o suficiente, pelo menos desde o início.
“Toda semana, estávamos dobrando a infraestrutura necessária (para hospedar Jitsi)”, disse Emil Ivov, criador e vice -presidente de produto de Jitsi, na 8×8. “E é loucura o quão rápido as coisas crescem quando as coisas são exponenciais.”
Os servidores 8×8 estavam sofrendo com o mesmo número de gargalos de desempenho da rede em questão de horas, pois seus engenheiros esperavam ter lidado ao longo de um ano inteiro. Ivov comparou o sentimento de se encontrar em um filme de combate submarino, onde todas as acusações de profundidade vêm de uma vez e todas as válvulas da ponte do navio começam a explodir e vomitar água.
“Geralmente, quando algo dá errado, uma máquina ficava sobrecarregada, haveria muita demanda na CPU, e não haveria trabalho suficiente para tirar pacotes de filas quando chegaram”, explicou Ivov.
“Essas filas cresceriam mais. Leva tempo para um pacote deixar essa fila, ser processado, ser colocado em uma fila de saída e ser enviado. Esse tempo aumenta, e esse aumento é visível para os usuários.
Esse tempo se manifesta como latência (e depois) perda de pacotes, porque, quando você começa a enviar muitos pacotes na estrada, você pode sobrecarregar as filas de vários dispositivos na estrada para o seu dispositivo final. Você pode ver vídeo ou ruído ruim em seu áudio, interrupções. Isso se torna muito visível não apenas nos gráficos de métricas, mas também para os usuários. ”
Um momento, o balanceador de carga da Haproxy encontraria impasses de delegação de threads. Então, como o Haproxy depende do syslog para gerar logs em vez de gravar arquivos de log para si, o sistema de log ficaria sobrecarregado.
Mas os desafios tecnológicos não foram o maior problema. “Houve um enorme desafio financeiro que entrou nele. Nosso projeto de lei aumentou duas ordens de magnitude, entrando em milhões por mês”.
Recompensa no percentil 99
8×8 precisavam reduzir seus custos imediatamente. Primeiro, investiu na Oracle Cloud Infrastructure (OCI). Em seguida, seus desenvolvedores criaram otimizações que permitiram que as cargas de trabalho consumissem menos instâncias do OCI Server. Depois disso, a Oracle se aproximou de 8×8 com a notícia de que estava lançando uma instância do ARM64 OCI mais barata alimentada pelas CPUs AMPERE® ALTRA®.
Com pouco tempo de sobra, 8×8 aposta e começou a refatorar Jitsi para a mudança para uma microarquitetura completamente diferente – um movimento que temia seria árduo e montado com incidentes. A maior parte do código crítico para JITSI é escrito em Java, exigindo que as interfaces JNI para as bibliotecas de criptografia de código de máquina nativas e outras bibliotecas que precisavam ser recompiladas. As próprias bibliotecas, no entanto, já tinham versões do ARM64.
“É uma arquitetura incrivelmente bem apoiada”, observou o IVov de 8×8. “Todo projeto significativo já tem binários para o ARM64, então nunca tivemos nenhum problema com isso”.
De acordo com a estimativa de Ivov, as instâncias do ARM64 da OCI foram até 30 % menos caras por instância do que as instâncias que eles estavam usando antes. Além disso, as instâncias do ARM64 baseadas em Ampere ofereceram um desempenho 30 % maior, novamente de acordo com Ivov-“uma melhoria muito substancial”. Cada instância do ampere estava fazendo 20 a 30% mais de trabalho, no mesmo tamanho, em comparação com antes da migração.
A latência é medida em redes de telecomunicações, empilhando os tempos de resposta para todas as transações juntas em um gráfico. A métrica que reflete o valor médio de latência esperada para o percentil 95 de todas as transações é referida como P95, que de preferência deve ser muito baixa.
No percentil 99 (P99), espera -se que as estimativas médias de latência sejam mais altas, porque os quatro por cento das transações entre os percentis 95 e 99 provavelmente incluirão transações mais lentas. Depois de se mudar para as instâncias do ARM64 baseado em Ampere, o 8×8 atingiu seu objetivo de atingir o Jitsi ou exceder um P95 de 1 ms. Isso significava que o desempenho diário deve ver transações de pacotes consumindo menos de um milissegundo e um P99 de 5 ms.
A realocação de todos os Jitsi para o ARM64 exigiu um trabalho mínimo de seus desenvolvedores, todos concluídos em um dia. Além disso, os scripts de automação para o lançamento de novas instâncias de máquinas virtuais tiveram que ser novamente ajustadas para instâncias do ARM64-equivalente a mais alguns dias. Os engenheiros da JITSI não relataram problemas sérios, adaptando suas ferramentas de monitoramento existentes para coletar métricas de desempenho para o ARM64, nem para reconfigurar plataformas de orquestração.
Uma vitória de baixo custo e fácil
Emil Ivov, do 8×8, admite que ele e sua equipe tiveram alguma apreensão sobre o que eles achavam que seria um êxodo de X86 para Ampere. Jitsi sofreria de acertos de desempenho, e o custo de mitigar esses hits excederia qualquer economia que eles tenham sido executados em plataformas de menor custo? 8×8 se encontraria dividido no meio, com a plataforma de comunicações hospedada por uma arquitetura completamente diferente da plataforma CX?
“No começo, pensei: ‘Ah, Puxa, quem sabe o que é exótico’ ‘, comentou Ivov,“ e quantas coisas não vão correr lá nessa arquitetura base do ARM64. Eu estava assustado, que coisas imprevistas aconteceriam. Mas pagar menos dinheiro é um grande incentivo para tentar e tentar tentar. “
Para sua surpresa, todo o itinerário para migrar Jitsi de x86 para o ARM64 usando OCI baseado em amperes consumiu apenas duas semanas. O próximo passo foi a mudança da encenação para a produção, e os resultados excederam as expectativas de todos.
“Ligamos, e as máquinas que eram aproximadamente 20% a 30% mais baratas estavam nos dando um desempenho de 20 a 30% melhor”, disse Ivov. Questionado sobre quais são os planos da 8×8 para mover outras plataformas para Ampere e OCI, Ivov declarou que é o caminho mais fácil de reduzir custos. “Não há reticência na adoção de casos de amperes”, disse ele. “Eles são sempre a primeira opção que olhamos.”
