Monitoramento de perda de pacotes de rede e latência na Roblox Cloud

A equipe de Engenharia de Rede da Roblox mantém uma rede ampla e em rápido crescimento, com data centers e pontos de presença (POP) distribuídos por todo o mundo. Oferecer uma excelente experiência ao usuário na plataforma Roblox depende do desempenho e da confiabilidade dessa rede. É fundamental que os operadores de rede sejam capazes de solucionar e detectar problemas na rede, além de ter visibilidade do desempenho da rede. O monitoramento de rede geralmente é realizado por meio da coleta periódica de estatísticas de dispositivos, métricas de erros e syslogs, e seu armazenamento em uma série temporal ou banco de dados de logs. Os dados são coletados por meio de um modelo push ou pull, utilizando protocolos padrão como SNMP, Netconf, APIs Rest ou Streaming Telemetry.

A detecção de falhas de rede exclusivamente por meio da telemetria de dispositivos apresenta várias deficiências, pois é uma técnica de monitoramento passiva. Ela depende da capacidade dos nós da rede de identificar e relatar situações anômalas assim que elas ocorrem. O dispositivo nem sempre reporta os dados ou, em alguns casos, pode não ter todas as suas estatísticas de integridade expostas aos métodos usuais de coleta de telemetria. Além disso, os dispositivos de rede podem, às vezes, fornecer dados errôneos ou silenciosamente bloquear o tráfego. Uma grande limitação da telemetria de dispositivos é que ela oferece muito pouca visibilidade sobre a acessibilidade de ponta a ponta, a perda de pacotes e as estatísticas de latência da rede.

Uma ótima maneira de monitorar ativamente uma rede é transmitindo regularmente sondas sintetizadas por uma malha, conforme ilustrado nas figuras abaixo.

Ao solucionar interrupções na produção, os operadores de rede frequentemente recebem perguntas como: “A rede está perdendo pacotes?” ou “Há alguma falha na rede afetando a conectividade do serviço?”. Para responder a esse tipo de pergunta sem acesso a dados históricos de perda de pacotes e latência, eles precisariam investigar um grande conjunto de links e nós dentro da rede.

Projetando um sistema de monitoramento de malha de rede confiável e escalável

Para que um sistema de monitoramento de rede do tipo “caixa preta” seja eficaz na detecção de perda de pacotes ou picos de latência, é necessário realizar sondagens contínuas em diferentes partes da rede. As redes de data center utilizam todos os links entre os nós para o tráfego de usuários. Os dispositivos de rede de produção executam o BGP e distribuem a carga de tráfego por múltiplos caminhos de custo igual. Alterações na topologia da rede geralmente são refletidas em segundos por meio de atualizações da tabela de roteamento em circunstâncias normais. Para obter uma medição precisa da perda de pacotes de rede, as sondas de teste devem percorrer o maior número possível de caminhos, cobrindo todos os nós e links da rede. Com uma rede grande, como a nossa, que abrange vários locais em todo o mundo, não é escalável sondar entre cada par de nós ou racks. A solução mais sustentável que escolhemos, que não compromete o nível de visibilidade, é sondar uma malha N² entre os racks dentro de cada local, juntamente com outra malha N² entre todos os locais.

Com o que testamos a rede?

As sondas de teste devem emular o tráfego ativo que passa por uma rede de produção. A maior parte do tráfego em nossa rede é TCP, UDP ou HTTP, e cada um desses protocolos poderia ser usado para sondas. Um dos problemas com a sondagem TCP é que ela não é leve o suficiente para escalar para o número de conexões necessárias para monitorar uma rede grande. Outra desvantagem do TCP é que o controle de fluxo integrado e as transmissões baseadas em janela deslizante resultam em uma taxa de transmissão de sondagem variável, o que não é ideal para quantificar ou detectar quedas momentâneas de pacotes. O ICMP, usado pelo ping e pelo traceroute, é normalmente limitado em taxa nos servidores ou nos nós de rede. Isso limita a taxa agregada de sondas ICMP que podem ser usadas. As solicitações HTTP estão em um nível mais alto na camada de aplicação e dependem de alguns fatores externos à rede, como o desempenho do servidor ou da aplicação. O HTTP adiciona um fator variável extra aos resultados que é difícil de isolar. O objetivo deste sistema é monitorar o desempenho da infraestrutura de rede subjacente que opera principalmente nas camadas 4 e inferiores do modelo OSI. Escolhemos sondas UDP por esses motivos, além de ser o principal protocolo da camada de transporte em nossa rede.

De onde fazemos as sondagens?

Uma maneira de alcançar uma alta taxa agregada de sondagem e também cobrir um grande número de caminhos de rede é utilizar o maior número possível de nós de computação para transmitir as sondas. Isso tem duas vantagens: ajuda a distribuir a carga nos sistemas que estão gerando as sondas e amplia o número de portas de rede que as transportam. No entanto, isso requer um agente que seja muito estável e que consuma o mínimo possível de recursos do sistema host. Ao mesmo tempo, o agente deve ser capaz de medir com precisão a perda de pacotes e a latência em múltiplos caminhos sem ser afetado por oscilações na utilização da CPU, da memória ou da E/S no sistema host. O agente precisa manter constantemente esse delicado equilíbrio entre ser leve e ter alto desempenho.

Como medimos a perda de pacotes e a latência na rede?

Isso pode parecer um cálculo trivial em um único fluxo de sondas; no entanto, existem alguns desafios que surgem em escala e que não são imediatamente óbvios. Para escalar para uma malha tão grande, o agente precisa calcular de forma rápida e precisa as contagens de pacotes de transmissão (Tx) e recepção (Rx) com carimbos de data/hora em vários fluxos simultaneamente. É importante que as métricas de perda de rede não incluam pacotes perdidos no host que executa o agente quando sua CPU está ocupada ou seus buffers de rede transbordam. A latência de rede precisa ser calculada com o tempo total em que as sondas estiveram no cabo ou em nós de rede intermediários, excluindo o tempo gasto na espera em buffers de E/S e no processo do agente aguardando agendamento do sistema operacional.

O sistema Ping Mesh da Roblox

A necessidade de monitoramento de perda e latência de rede em "caixa preta" existe desde o crescimento da infraestrutura de nuvem pública e privada. Tem sido difícil encontrar uma solução pronta para uso que possa ser dimensionada para nossa grande rede. Vários grandes operadores de nuvem e fornecedores de ferramentas de rede desenvolveram suas próprias soluções para monitorar perda e latência de rede. Testamos algumas ferramentas disponíveis abertamente, mas enfrentamos problemas de estabilidade e escalabilidade, obtendo apenas visibilidade limitada do desempenho da rede. Isso nos levou a construir nosso próprio sistema de monitoramento em malha, que proporcionou melhor detecção de erros de baixa frequência com baixo overhead. Alguns dos destaques do nosso sistema são:

• Escolhemos Go para implementar todos os componentes do nosso sistema, o que ajudou a alcançar um alto nível de desempenho usando o mínimo de recursos do sistema.
• Nossos agentes são altamente estáveis e podem ser executados em uma ampla variedade de hosts de produção, incluindo aqueles que executam serviços críticos na plataforma Roblox, como servidores de tráfego, cache e aplicativos.
• O agente é otimizado para agrupar operações de E/S de pacotes com funções wrapper do Go sobre as chamadas de sistema sendmmsg() e recvmmsg() do Linux, o que permite transmitir uma alta taxa de sondas com baixa sobrecarga. Cada agente em nossa implantação transmite simultaneamente sondas para até 100 outros hosts, a uma taxa de 100 pacotes por segundo (PPS). O agente transmite rajadas de pacotes a cada segundo para cada destino.
• As sondas transportam diferentes valores do campo tipo de serviço (TOS) no cabeçalho IP para cada destino e são contabilizadas separadamente para perda de pacotes e latência na rede. Cada rajada de pacotes inclui uma combinação de vários valores de TOS para todos os outros destinos. Isso ajuda a monitorar o desempenho da rede para diferentes classes de qualidade de serviço (QoS).
• O agente pode detectar quedas de rede tão baixas quanto 1 em 6.000 pacotes por minuto em cada caminho de sonda. É possível detectar perdas de pacotes no núcleo ou na borda da rede com duração inferior a 1 segundo, como aquelas que ocorrem durante uma oscilação de BGP.
• Os gráficos de queda de pacotes de sonda imitam as taxas de erro da interface do dispositivo de rede quando os erros são responsáveis pelas quedas. Conseguimos descobrir bugs de black-holing de tráfego na rede que são difíceis de detectar.
• Os agentes utilizam carimbos de data/hora de leitura do kernel da NIC para obter alta precisão nas medições de latência de rede. É possível medir uma latência de ida e volta consistente dentro do site de 50 a 100 microssegundos, excluindo a latência de agendamento do sistema operacional do host e o desvio do relógio de rede.
• Baixa utilização da CPU e pegada de memória. O agente usa menos de 25% de um único núcleo nas taxas máximas de transmissão e recepção (5 kpps cada). A maioria dos agentes implantados usa apenas cerca de 5% de um núcleo. São necessários apenas 10 MB de memória heap para gerenciar os buffers e contadores de pacotes de transmissão e recepção do agente. Quando a rede cresce, podemos escalar vertical ou horizontalmente ajustando os limites ou adicionando agentes.
• O agente raramente é afetado quando o sistema host está sob carga. Obtivemos resultados precisos mesmo quando a carga da CPU do host se aproximou de 99% em várias ocasiões.
• A telemetria é coletada de cada agente para monitorar sua integridade. Os agentes podem identificar situações problemáticas, como quando o sistema host reinicia, quando o processo do agente é reiniciado ou quando pacotes são perdidos devido ao estouro dos buffers de soquete.

Os agentes são implantados com o Chef em um amplo conjunto de clusters de servidores para manter um grande número de nós participando da sondagem de rede. O binário do agente é executado e gerenciado com o systemd no Linux, de modo que seja reiniciado automaticamente após uma reinicialização do host ou uma atualização do agente. O agendador de malha detecta e ajusta dinamicamente os fluxos conforme necessário quando qualquer um dos agentes fica inativo ou novos agentes são ativados. Nosso aplicativo agendador consulta periodicamente o inventário de dispositivos e um sistema de descoberta de serviços para detectar novos agentes e o status de integridade do servidor antes de alocar alvos para sondagem Intra-Pod, Intra-Site e Inter-Site. Um barramento de mensagens é usado para comunicar a lista de hosts de destino a cada agente que está transmitindo sondas de teste. Fluxos individuais que se originam ou terminam em um rack específico são distribuídos entre todos os agentes disponíveis dentro desse rack. Isso nos ajuda a testar uma grande quantidade de caminhos de custo igual dentro de nossa malha de rede, conforme mostrado nas figuras abaixo.

Começamos com 150 agentes em nossa primeira implantação e agora expandimos com sucesso em 10 vezes. A malha cobre nossa espinha dorsal, interconectando 25 locais espalhados pelo mundo. Em um de nossos principais data centers, temos uma malha intra-site cobrindo mais de 200 racks com cerca de 33.000 fluxos, totalizando uma taxa de sondagem de 1,65 Mpps. Cada rack recebe de 5 a 10 kpps de sondagens de outros racks. O aplicativo agendador calcula e distribui uniformemente mais de 35.000 alvos entre todos os nossos agentes em diferentes locais.

Coleta e visualização de dados

Executamos um aplicativo coletor separado que consulta periodicamente todos os agentes do Ping Mesh para obter resultados de perda de pacotes e latência. Esses dados são filtrados automaticamente para excluir resultados inválidos com base nos estados de integridade armazenados em cache localmente no coletor. Por exemplo, excluímos resultados de um agente em execução em um servidor que não respondeu às verificações de integridade ou de um servidor que acabou de reiniciar. Nosso coletor pode consultar e filtrar resultados de mais de 1.500 nós de forma síncrona e, em seguida, inserir os dados em um banco de dados de séries temporais em até 2 segundos.

Tanto os resultados agregados quanto os por fluxo são visualizados com a ajuda dos painéis do Grafana. As grades de mapas de calor podem ser difíceis de usar com grandes conjuntos de dados, especialmente para o nosso grande data center. Utilizamos uma consulta topk() do Prometheus para exibir os caminhos com a maior perda individual de pacotes entre milhares de resultados, que geralmente são apenas alguns. Os resultados são exaustivamente verificados em relação às estatísticas de integridade do agente e do sistema host, que são frequentemente coletadas pelo coletor. Isso nos dá um alto nível de confiança em cada resultado individual, independentemente do tamanho das variações na perda de pacotes. Os resultados individuais, quando analisados em conjunto, podem nos dar pistas sobre onde ocorreu a falha na rede. Alguns exemplos de perda de pacotes detectados pelo nosso sistema de monitoramento em malha são exibidos abaixo.

Resumo e próximos passos

Nosso sistema Ping Mesh tem sido uma ferramenta poderosa para a equipe de Engenharia de Rede monitorar a perda de pacotes e a latência de ponta a ponta. Esses dados podem ser usados para responder instantaneamente à pergunta: “A rede está perdendo pacotes?” Com base em nossa experiência, os principais incidentes de rede que afetam os clientes geralmente são detectados e alertados pelo sistema de monitoramento de telemetria do dispositivo. Problemas de baixo impacto, mas potencialmente problemáticos, relacionados ao buffer da rede ou ao bloqueio isolado de tráfego são revelados por esse sistema.

Nosso sistema também pode fornecer insights sobre a confiabilidade geral da Roblox Cloud Network. Em um de nossos principais data centers, temos mais de 100 milhões de sondas por minuto monitorando a integridade da rede e raramente atingimos uma contagem de perda de pacotes superior a 50 por minuto. Isso indica uma confiabilidade de cerca de 6 noves (99,9999%) da rede do nosso data center. Com bastante frequência, nenhuma perda de pacotes é observada entre os 100 milhões de pacotes. Quando uma quantidade significativa de pacotes é perdida, este sistema fornece insights sobre onde e por quanto tempo a perda de pacotes ocorreu. Um mecanismo de correção automática repara a rede e evita que o tráfego do usuário sofra novas perdas, redirecionando-o por um caminho diferente na rede. A equipe de redes da Roblox construiu uma rede em nuvem extremamente confiável.

No futuro, pretendemos utilizar um mecanismo de análise para correlacionar dados de telemetria de dispositivos, syslogs e outros conjuntos de dados. Em seguida, planejamos comparar isso com os dados do Ping Mesh para ajudar a isolar onde ocorreu a falha na rede. À medida que a rede em nuvem da Roblox continua a se expandir e evoluir, planejamos aprimorar nossos mecanismos de sondagem para incluir IPv6 e quadros jumbo, ao mesmo tempo em que adicionamos mais agentes para aumentar a cobertura entre os sites.