“Pasamos el posterior año reconstruyendo componentes importantes de nuestro sistema”, anunció Cloudflare esta semana, “y acabamos de achicar la latencia del tráfico que pasa a través de nuestra red para millones de nuestros clientes” (hay un recortadura de 10 ms en el tiempo medio para replicar, adicionalmente de un aumento de rendimiento del 25 % según lo medido por las pruebas de rendimiento de CDN). Reemplazaron un sistema de 15 abriles llamado FL (donde ejecutan características de seguridad y rendimiento) y “Al mismo tiempo, Hemos hecho que nuestro sistema sea más seguro y hemos limitado el tiempo que nos lleva crear y divulgar nuevos productos”.

Y sí, Rust estuvo involucrado:

Escribimos mucho sobre Rust y nos hemos vuelto suficiente buenos en eso… Construimos FL2 en Rust, en Oxy (Cloudflare Situación proxy de próxima vivientes basado en Rust), y creó un ámbito de módulo fiel para disponer toda la método en FL2… Construido en Rust, (Oxy) elimina clases enteras de errores que plagaron nuestro FL1 basado en Nginx/LuaJIT, como problemas de seguridad de la memoria y carreras de datos, al tiempo que ofrece un rendimiento de nivel C. A la escalera de Cloudflare, esas garantías no son poco agradable de tener, son esenciales. Cada microsegundo ahorrado por solicitud se traduce en mejoras tangibles en la experiencia del legatario, y cada rotura o caso tope evitado mantiene Internet funcionando sin problemas. Las estrictas garantías de tiempo de compilación de Rust igualmente combinan perfectamente con la cimentación modular de FL2, donde aplicamos contratos claros entre los módulos del producto y sus entradas y panorama…

Es una distracción lo suficientemente vasto a la hora de expedir productos a los clientes como para rehacer la método del producto en Rust. Pedir a todos nuestros equipos que mantuvieran dos versiones de la método de su producto y que volvieran a implementar cada cambio una segunda vez hasta que termináramos nuestra migración fue demasiado. Entonces, implementamos una capa en nuestro antiguo FL basado en NGINX y OpenResty que permitió ejecutar los nuevos módulos. En puesto de prolongar una implementación paralela, los equipos podrían implementar su método en Rust y reemplazar su antigua método Lua con ella, sin esperar el reemplazo completo del antiguo sistema.
Más de 100 ingenieros trabajaron en FL2 y se realizaron pruebas exhaustivas, adicionalmente de un procedimiento de retorno a FL1. Pero “Comenzamos a mandar el tráfico de clientes a través de FL2 a principios de 2025 y hemos ido aumentando progresivamente la cantidad de tráfico atendido a lo generoso del año…”

Como describimos al principio de esta publicación, FL2 es sustancialmente más rápido que FL1. La principal razón de esto es simplemente que FL2 realiza menos trabajo (gracias a los filtros que controlan si los módulos necesitan ejecutarse)… Otra gran razón para un mejor rendimiento es que FL2 es una saco de código única, implementada en un habla centrado en el rendimiento. En comparación, FL1 se basó en NGINX (que está escrito en C), combinado con LuaJIT (capas de interfaz Lua y C) y igualmente contenía muchos módulos Rust. En FL1, dedicamos mucho tiempo y memoria a convertir datos de la representación que necesita un idioma a la representación que necesita otro. Como resultado, nuestras medidas internas muestran que FL2 utiliza menos de la fracción de la CPU de FL1 y mucho menos de la fracción de la memoria. Esa es una gran superioridad: ¡podemos utilizarse la CPU en ofrecer más y más funciones a nuestros clientes!

Utilizando nuestras propias herramientas y puntos de remisión independientes como CDNPerf, medimos el impacto de FL2 a medida que lo implementábamos en la red. Los resultados son claros: los sitios web responden 10 ms más rápido en promedio, un aumento del rendimiento del 25%. FL2 igualmente es más seguro por diseño que FL1. Ningún sistema de software es valentísimo, pero el habla Rust nos aporta enormes ventajas sobre LuaJIT. Rust tiene fuertes controles de memoria en tiempo de compilación y un sistema de tipos que evita grandes clases de errores. Combine eso con nuestro sistema de módulos rígidos y podremos realizar la mayoría de los cambios con gran confianza…

Durante mucho tiempo hemos seguido la política de que cualquier rotura inexplicable de nuestros sistemas debe ser investigado como de reincorporación prioridad. No relajaremos esa política, aunque la principal causa de fallas novedosas en FL2 hasta ahora se debe a fallas de hardware. Las tasas enormemente reducidas de tales accidentes nos darán tiempo para hacer un buen trabajo en dichas investigaciones. Pasaremos el resto de 2025 completando la migración de FL1 a FL2 y desactivaremos FL1 a principios de 2026. Ya estamos viendo los beneficios en términos de rendimiento del cliente y velocidad de progreso, y esperamos ofrecérselos a todos nuestros clientes.

Luego de eso, cuando todo sea modular, en Rust y probado y escalado, ¡en realidad podremos comenzar a optimizar…!
Gracias al fogueado leedor de Slashdot Beeftopia por compartir el artículo.