Supervisión de la pérdida de paquetes y la latencia de red en Roblox Cloud

El equipo de ingeniería de redes de Roblox mantiene una red grande y en rápido crecimiento, con centros de datos y puntos de presencia (POP) distribuidos por todo el mundo. Ofrecer una excelente experiencia de usuario en la plataforma Roblox depende del rendimiento y la fiabilidad de esta red. Es fundamental que los operadores de red sean capaces de detectar y solucionar problemas en la red, y que tengan visibilidad sobre el rendimiento de la misma. La monitorización de la red se lleva a cabo generalmente mediante la recopilación periódica de estadísticas de dispositivos, métricas de errores y registros del sistema (syslogs), y su almacenamiento en una base de datos de series temporales o de registros. Los datos se recopilan mediante un modelo push o pull utilizando protocolos estándar como SNMP, Netconf, API REST o Streaming Telemetry.

La detección de fallos de red únicamente a través de la telemetría de los dispositivos presenta varias deficiencias, ya que se trata de una técnica de monitorización pasiva. Depende de la capacidad de los nodos de red para identificar y notificar situaciones anómalas tan pronto como se producen. Es posible que el dispositivo no siempre envíe los datos o, en algunos casos, que no exponga todas sus estadísticas de estado a los métodos habituales de recopilación de telemetría. Además, los dispositivos de red pueden, en ocasiones, proporcionar datos erróneos o absorber el tráfico de forma silenciosa. Una limitación importante de la telemetría de dispositivos es que ofrece muy poca visibilidad sobre la accesibilidad de extremo a extremo, la pérdida de paquetes y las estadísticas de latencia de la red.

Una excelente forma de supervisar activamente una red es transmitir regularmente sondas sintetizadas a través de una malla, tal y como se muestra en las figuras siguientes.

Al resolver incidencias de interrupciones en la producción, a los operadores de red se les suelen plantear preguntas como: «¿Está la red perdiendo paquetes?» o «¿Hay algún fallo de red en curso que esté afectando a la conectividad del servicio?». Para responder a este tipo de preguntas sin tener acceso a datos históricos de pérdida de paquetes y latencia, tendrían que investigar un gran conjunto de enlaces y nodos dentro de la red.

Diseño de un sistema de monitorización de malla de red fiable y escalable

Para que un sistema de monitorización de red de tipo «caja negra» sea eficaz a la hora de detectar pérdidas de paquetes o picos de latencia, requiere un sondeo continuo en diferentes partes de la red. Las redes de centros de datos utilizan todos los enlaces entre nodos para el tráfico de los usuarios. Los dispositivos de red de producción ejecutan BGP y equilibran la carga del tráfico a través de múltiples rutas de igual coste. Los cambios en la topología de la red suelen reflejarse en cuestión de segundos mediante actualizaciones de la tabla de enrutamiento en circunstancias normales. Para obtener una medición precisa de la pérdida de paquetes de red, las sondas de prueba deben recorrer tantas rutas como sea posible, cubriendo todos los nodos y enlaces de la red. Con una red grande, como la nuestra, que abarca múltiples sitios en todo el mundo, no es escalable realizar sondeos entre cada par de nodos o racks. La solución más sostenible que elegimos, que no compromete el nivel de visibilidad, es sondear una malla N² a través de los racks dentro de cada sitio junto con otra malla N² a través de todos los sitios.

¿Con qué sondeamos la red?

Las sondas de prueba deben emular el tráfico real que pasa por una red de producción. La mayor parte del tráfico de nuestra red es TCP, UDP o HTTP, y cada uno de estos protocolos podría utilizarse potencialmente para las sondas. Uno de los problemas de las sondas TCP es que no son lo suficientemente ligeras como para escalar al número de conexiones necesarias para monitorizar una red grande. Otro inconveniente del TCP es que el control de flujo integrado y las transmisiones basadas en ventanas deslizantes dan lugar a una tasa de transmisión de sondas variable, lo que no es ideal para cuantificar o detectar caídas momentáneas de paquetes. El ICMP, que utilizan ping y traceroute, suele tener una tasa limitada en los servidores o nodos de red. Esto limita la tasa agregada de sondas ICMP que se pueden utilizar. Las solicitudes HTTP se sitúan más arriba en la capa de aplicación y dependen de algunos factores ajenos a la red, como el rendimiento del servidor o de la aplicación. El HTTP añade un factor variable adicional a los resultados que es difícil de aislar. El objetivo de este sistema es supervisar el rendimiento de la infraestructura de red subyacente que opera principalmente en las capas 4 y inferiores del modelo OSI. Elegimos sondas UDP por estas razones, además de por ser el protocolo principal de la capa de transporte en nuestra red.

¿Desde dónde realizamos las sondas?

Una forma de lograr una alta tasa de sondeo agregada y cubrir al mismo tiempo un gran número de rutas de red es utilizar tantos nodos de cálculo como sea posible para transmitir los sondeos. Esto tiene dos ventajas: ayuda a distribuir la carga en los sistemas que generan los sondeos y amplía el número de puertos de red que los transportan. Sin embargo, esto requiere un agente que sea muy estable y que consuma los mínimos recursos posibles del sistema host. Al mismo tiempo, el agente debe ser capaz de medir con precisión la pérdida de paquetes y la latencia en múltiples rutas sin verse afectado por las fluctuaciones en la utilización de la CPU, la memoria o las E/S del sistema host. El agente tiene que mantener constantemente este delicado equilibrio entre ser ligero y ofrecer un alto rendimiento.

¿Cómo medimos la pérdida de red y la latencia?

Esto puede parecer un cálculo trivial sobre un único flujo de sondas; sin embargo, surgen algunos retos a gran escala que no son evidentes a primera vista. Para escalar a una malla tan grande, el agente necesita calcular de forma rápida y precisa el recuento de paquetes de transmisión (Tx) y recepción (Rx) con marcas de tiempo en numerosos flujos simultáneamente. Es importante que las métricas de pérdida de red no incluyan los paquetes que se pierden en el host que ejecuta el agente cuando su CPU está ocupada o sus búferes de red se desbordan. La latencia de red debe calcularse con el tiempo total que las sondas estuvieron en el cable o en los nodos de red intermedios, excluyendo el tiempo de espera en los búferes de E/S y el proceso del agente pendiente de la programación del sistema operativo.

El sistema Ping Mesh de Roblox

La necesidad de monitorizar la pérdida y la latencia de la red mediante una «caja negra» existe desde el crecimiento de la infraestructura de nube pública y privada. Ha resultado difícil encontrar una solución comercial que se pueda adaptar a nuestra amplia red. Varios grandes operadores de nube y proveedores de herramientas de red han diseñado sus propias soluciones para monitorizar la pérdida y la latencia de la red. Probamos algunas herramientas de libre acceso, pero nos encontramos con problemas de estabilidad y escalabilidad, al tiempo que solo obteníamos una visibilidad limitada del rendimiento de la red. Esto nos llevó a crear nuestro propio sistema de monitorización en malla, que ha proporcionado una mejor detección de errores de baja frecuencia con una baja sobrecarga. Algunas de las características más destacadas de nuestro sistema son:

• Elegimos Go para implementar todos los componentes de nuestro sistema, lo que nos ayudó a alcanzar un alto nivel de rendimiento utilizando un mínimo de recursos del sistema.
• Nuestros agentes son muy estables y pueden ejecutarse en una amplia gama de hosts de producción, incluidos aquellos que prestan servicios críticos en la plataforma Roblox, como servidores de tráfico, de almacenamiento en caché y de aplicaciones.
• El agente está optimizado para agrupar operaciones de E/S de paquetes mediante funciones envolventes de Go sobre las llamadas al sistema sendmmsg() y recvmmsg() de Linux, lo que le permite transmitir una alta tasa de sondas con una baja sobrecarga. Cada agente de nuestra implementación transmite simultáneamente sondas a hasta 100 hosts diferentes, a una tasa de 100 paquetes por segundo (PPS). El agente transmite ráfagas de paquetes cada segundo a cada destino.
• Las sondas llevan diferentes valores del campo «tipo de servicio» (TOS) en la cabecera IP a cada destino y se contabilizan por separado para la pérdida de paquetes y la latencia en la red. Cada ráfaga de paquetes incluye una combinación de múltiples valores TOS para cada uno de los demás destinos. Esto ayuda a supervisar el rendimiento de la red para diferentes clases de calidad de servicio (QoS).
• El agente puede detectar caídas de red de tan solo 1 de cada 6000 paquetes por minuto en cada ruta de sonda. Se pueden detectar pérdidas de paquetes en el núcleo o el perímetro de la red que duren menos de 1 segundo, como las que se producen durante una fluctuación de BGP.
• Los gráficos de caídas de paquetes de las sondas imitan los de las tasas de error de las interfaces de los dispositivos de red cuando los errores son los responsables de las caídas. Hemos podido descubrir errores de «black-holing» del tráfico en la red que son difíciles de detectar.
• Los agentes utilizan las marcas de tiempo de lectura del kernel de la NIC para lograr una alta precisión en las mediciones de latencia de la red. Se puede medir una latencia de ida y vuelta intra-sitio constante de 50-100 microsegundos, excluyendo la latencia de programación del sistema operativo del host y la deriva del reloj de red.
• Bajo consumo de CPU y huella de memoria. El agente utiliza menos del 25 % de un solo núcleo en las tasas máximas de transmisión y recepción (5 kpps cada una). La mayoría de los agentes desplegados utilizan solo alrededor del 5 % de un núcleo. Solo se necesitan 10 MB de memoria heap para gestionar los búferes y contadores de paquetes de transmisión y recepción del agente. Cuando la red crece, podemos escalar vertical u horizontalmente ajustando los límites o añadiendo agentes adicionales.
• El agente rara vez se ve afectado cuando el sistema host está bajo estrés. Hemos obtenido resultados precisos incluso cuando la carga de la CPU del host se ha acercado al 99 % en varias ocasiones.
• Se recopila telemetría de cada agente para supervisar su estado. Los agentes pueden identificar situaciones problemáticas, como cuando el sistema host se reinicia, cuando el proceso del agente se reinicia o cuando se pierden paquetes debido al desbordamiento de los búferes de los sockets.

Los agentes se implementan con Chef en un amplio conjunto de clústeres de servidores para mantener un elevado número de nodos participando en la sonda de red. El binario del agente se ejecuta y gestiona con systemd en Linux, de modo que se reinicia automáticamente tras un reinicio del host o una actualización del agente. El programador de malla detecta y ajusta dinámicamente los flujos según sea necesario cuando alguno de los agentes se cae o aparecen otros nuevos. Nuestra aplicación de programación consulta periódicamente el inventario de dispositivos y un sistema de descubrimiento de servicios para detectar nuevos agentes y el estado de salud de los servidores antes de asignar objetivos para las pruebas intra-pod, intra-sitio e inter-sitio. Se utiliza un bus de mensajes para comunicar la lista de hosts de destino a cada agente que transmite pruebas de sondeo. Los flujos individuales que se originan o terminan en un rack específico se distribuyen entre todos los agentes disponibles dentro de ese rack. Esto nos ayuda a ejercitar una gran cantidad de rutas de coste igual dentro de nuestra estructura de red, como se muestra en las figuras siguientes.

Comenzamos con 150 agentes en nuestra primera implementación y ahora hemos multiplicado con éxito esa cifra por diez. La malla cubre nuestra red troncal, interconectando 25 emplazamientos repartidos por todo el mundo. En uno de nuestros principales centros de datos contamos con una malla interna que abarca más de 200 racks con unos 33 000 flujos que suman una tasa de sondeo de 1,65 Mpps. Cada rack recibe entre 5 y 10 kpps de sondeos de otros racks. La aplicación de programación calcula y distribuye uniformemente más de 35 000 objetivos entre todos nuestros agentes en diferentes emplazamientos.

Recopilación y visualización de datos

Ejecutamos una aplicación colectora independiente que sondea periódicamente a todos los agentes de Ping Mesh para obtener resultados de pérdida de paquetes y latencia. Estos datos se filtran automáticamente para excluir los resultados no válidos basándose en los estados de salud almacenados en caché localmente en el colector. Por ejemplo, excluimos los resultados de un agente que se ejecuta en un servidor que no respondió a las comprobaciones de estado o en un servidor que acaba de reiniciarse. Nuestro colector puede sondear y filtrar de forma sincrónica los resultados de más de 1.500 nodos y, a continuación, ingestar los datos en una base de datos de series temporales en menos de 2 segundos.

Tanto los resultados agregados como los de cada flujo se visualizan con la ayuda de los paneles de Grafana. Las cuadrículas de mapas de calor pueden resultar difíciles de usar con grandes conjuntos de datos, especialmente en nuestro gran centro de datos. Utilizamos una consulta topk() de Prometheus para mostrar las rutas con la mayor pérdida de paquetes individual entre miles de resultados, que por lo general son solo unas pocas. Los resultados se contrastan exhaustivamente con las estadísticas de estado del agente y del sistema host que el colector recopila con frecuencia. Esto nos proporciona un alto nivel de confianza en cada resultado individual, independientemente de la magnitud de las variaciones en la pérdida de paquetes. Los resultados individuales, cuando se analizan en conjunto, pueden darnos pistas sobre dónde se produjo el fallo de red. A continuación se muestran algunos ejemplos de pérdida de paquetes detectados por nuestro sistema de monitorización de malla.

Resumen y próximos pasos

Nuestro sistema Ping Mesh ha sido una herramienta muy eficaz para que el equipo de ingeniería de redes supervise la pérdida de paquetes y la latencia de extremo a extremo. Estos datos pueden utilizarse para responder al instante a la pregunta: «¿Está la red perdiendo paquetes?». Según nuestra experiencia, los incidentes de red importantes que afectan a los clientes suelen detectarse y notificarse mediante el sistema de supervisión de telemetría de los dispositivos. Este sistema saca a la luz problemas de bajo impacto, pero potencialmente problemáticos, relacionados con el almacenamiento en búfer de la red o con el bloqueo aislado del tráfico.

Nuestro sistema también puede proporcionar información sobre la fiabilidad general de la red Roblox Cloud. En uno de nuestros principales centros de datos, contamos con más de 100 millones de sondas por minuto que supervisan el estado de la red y rara vez superamos un recuento de pérdida de paquetes superior a 50 por minuto. Esto indica una fiabilidad de aproximadamente 6 nueves (99,9999 %) en la red de nuestro centro de datos. Con bastante frecuencia, no se detecta ninguna pérdida de paquetes entre los 100 millones de paquetes. Cuando se pierde una cantidad significativa de paquetes, este sistema proporciona información sobre dónde y durante cuánto tiempo se produjo la pérdida. Un motor de corrección automática repara la red y evita que el tráfico de los usuarios sufra más pérdidas redirigiéndolo a través de una ruta diferente en la red. El equipo de redes de Roblox ha construido una red en la nube extremadamente fiable.

En el futuro, tenemos la intención de utilizar un motor de análisis para correlacionar datos de telemetría de dispositivos, registros del sistema y otros conjuntos de datos. A continuación, tenemos previsto compararlos con los datos de Ping Mesh para ayudar a aislar dónde se produjo el fallo de red. A medida que la red en la nube de Roblox continúa expandiéndose y evolucionando, tenemos previsto mejorar nuestros mecanismos de sondeo para incluir IPv6 y tramas jumbo, al tiempo que añadimos más agentes para aumentar la cobertura entre sitios.