Más de una década después: la evolución de Instant Purge

La invalidación instantánea de la caché es esencial para la distribución de contenido dinámico. Las noticias de última hora, las actualizaciones de eventos en vivo y las promociones de comercio electrónico dependen de la capacidad de purgar rápidamente la información obsoleta. 

Entonces, ¿por qué Instant Purge™ sigue siendo tan difícil de resolver hoy como lo fue cuando lo abordamos hace más de 10 años? Bueno, las redes del borde modernas están distribuidas por todo el mundo. Asegurar la invalidación casi simultánea en todos esos nodos de caché no es tarea fácil. Necesitamos comunicar los eventos de invalidación a cada nodo activo en cuestión de milisegundos. Además, hay un constante acto de equilibrio entre la fiabilidad, la velocidad, la escalabilidad y la cobertura. Necesitamos minimizar la latencia sin sacrificar la consistencia del caché, haciéndola lo suficientemente eficiente como para que sea realmente "instantánea". Eso es mucho pedir. No es de extrañar que haya pasado más de una década para que otros intenten ponerse al día.

¿Centralizar o descentralizar? 

Cuando nos enfrentamos a este problema hace muchos años, nos dimos cuenta de que había dos maneras principales de resolverlo: centralizada o descentralizada. La solución típica consiste en enviar peticiones de purga a un sistema central, que luego coordina la eliminación del contenido de las cachés a nivel mundial. Aunque este método pueda parecer sencillo, introduce un único punto de fallo y una mayor latencia, lo cual no es ideal para obtener resultados instantáneos.

Comenzamos a ver este desafío de una manera diferente. En lugar de confiar en una estructura de mando centralizada, nos preguntamos: ¿Y si tratamos la purga como un problema de mensajería distribuida que se puede resolver de forma descentralizada? En lugar de llevar las peticiones de purgar a una ubicación central, ¿por qué no las interceptáis en el borde y usáis la lógica allí mismo para distribuirlas rápidamente?

Ahora, este enfoque descentralizado no está exento de desafíos. Es más complicado de crear y añade cierta complejidad. Es posible que los servidores pierdan temporalmente el contacto entre sí, o que los mensajes se pierdan o se retrasen durante el tránsito. Pero encontramos una manera de solucionar eso.

¿Cómo funciona Instant Purge™?

Basamos nuestro sistema en un algoritmo llamado Bimodal Multicast. Es rápido, comprensible y garantiza que los mensajes se entregarán eventualmente. Prácticamente, así es como funciona: cuando un servidor de caché recibe una petición de purgar, inmediatamente transmite el mensaje a todos los demás servidores usando UDP. Con tasas de pérdida de paquetes típicas inferiores al 0,1 % entre nuestros puntos de presencia (PoP), la latencia de purga suele estar limitada únicamente por el retraso de la red.

Un concepto clave de nuestro sistema: no requerimos la confirmación de los mensajes de purga. Al omitir este paso, podemos reducir la latencia hasta la mitad. Tampoco intentamos ser demasiado listos con el enrutamiento. En cambio, difundimos la purga por todas partes. Esto puede parecer ineficiente, pero en realidad simplifica las cosas. Todos nuestros nodos son igualmente capaces de manejar el mismo tráfico. Esto significa que podemos enviar peticiones de purga a todas partes sin mantener mapas complejos de la ubicación del contenido. Es un enfoque más sencillo y robusto que escala bien a medida que nuestra red crece.

Nuestro enfoque de la arquitectura de red también nos da una ventaja: hemos creado nuestros POPs para maximizar el almacenamiento en caché en el borde y un control programático más inteligente. Al ejecutar intencionadamente menos POPs pero más potentes, reducimos la complejidad de nuestra red y minimizamos el número de servidores que necesitan recibir mensajes de purga. Esta decisión arquitectónica ofrece ventajas significativas para la purga instantánea. Además, nuestra red definida por software nos permite adaptar y optimizar nuestro sistema de purga al vuelo, sin estar limitados por las limitaciones de hardware.

¿Cómo te ha resultado esto? 

Ahora estoy seguro de que te estarás preguntando: «¿Ha escalado bien este sistema?» ¿Ha seguido funcionando bien a medida que hemos añadido cada vez más clientes y tráfico? ¿Tu enfoque dio resultado? Bueno, la respuesta corta es sí... como esperábamos de nuestro diseño inicial, hemos tenido que iterar en nuestro sistema de purga para aumentar el tráfico que podemos manejar y seguir escalando. Con el tiempo, hemos pasado de 2-3 mil purgas por segundo en 2018 a alrededor de 60 mil purgas por segundo en la actualidad. Cuando implementamos por primera vez la Multidifusión Bimodal, fue casi directamente sacado de los artículos académicos, pero había límites de escalabilidad. Con el tiempo, nuestro sistema se ha convertido en algo propio y ya no es realmente puramente Bimodal Multicast. 

A lo largo de los años, ha habido tres momentos en los que hemos realizado optimizaciones y cambios en la manera en que llevamos a cabo la purga. Unos años después de que introdujimos originalmente nuestra capacidad de purga, comenzamos a enfrentar algunos problemas de escalabilidad y fiabilidad a medida que expandíamos nuestra red y lidiábamos con el siempre presente estado de Internet. Originalmente, configuramos todos los nodos en un punto de presencia como pares sin jerarquía, donde cada nodo recibía cada petición de purga y tenía el deber de distribuir paquetes a todos los demás nodos. En un esfuerzo por optimizar la escalabilidad a medida que aumentaba nuestro número de nodos y la fiabilidad en lo que respecta a la pérdida de paquetes debido al estado de Internet, pensamos: en lugar de enviar mensajes de purga a cada nodo en un punto de presencia, ¿qué tal si los enviamos a uno y dejamos que lo retransmita al resto de los nodos en el punto de presencia?

Esto incrementó significativamente nuestra capacidad de escalar y disminuyó el número total de operaciones. Las peticiones de purgar se encapsulan en paquetes UDP que se distribuyen al menos a dos nodos en buen estado en cada punto de presencia del clúster, que luego retransmiten los paquetes a los nodos vecinos de la red local. Este mecanismo de "doble distribución" es nuestro primer nivel de defensa para la fiabilidad y reduce significativamente las probabilidades de que una petición se pierda en tránsito debido al estado de Internet.

Y finalmente, el año pasado trabajamos en la purga por lotes que tuvo un gran impacto en la escalabilidad (¡y eliminó las alertas que os despertaban por la noche!). Nuestra API siempre ha permitido a los clientes purgar por lotes con una serie de claves suplentes, pero esto no era realmente «purga por lotes». El sistema fragmentaba y clasificaba el lote en purgas individuales, que en grandes volúmenes podían inundar el sistema, alertándonos y obligándonos a aplicar un límite de volumen para no degradar el rendimiento. No es ideal para nuestros clientes ni para nosotros. Así que modificamos el sistema para gestionar la purga real y efectiva de lotes, mejorando la escalabilidad y eliminando las alertas y la limitación de frecuencia. Ahora estamos seguros de que podemos escalar a cientos de miles de purgas por segundo.

El futuro de Instant Purge

De cara al futuro, estamos trabajando en maneras de hacer que nuestro sistema de purga sea aún más eficiente y escalable, y siempre antes de que lo necesitemos. Siempre queremos estar por delante de la demanda con 10 veces la capacidad que actualmente necesitamos. Nuestro objetivo es expandir la capacidad de cientos de miles de peticiones por segundo a millones por segundo, y creemos que podemos ampliar las optimizaciones y técnicas que ya hemos implementado en torno a la agrupación de elementos para lograr el siguiente nivel de rendimiento y escalabilidad. Es un proceso continuo de innovación para adelantarte a las crecientes demandas.

Al final, se trata de crear una arquitectura dinámica que pueda adaptarse y escalar conforme evolucionan las necesidades. Al abordar el problema de manera diferente y adoptar la descentralización, hemos creado un sistema que cumple la promesa de una purga verdaderamente instantánea. Este artículo contiene declaraciones «prospectivas» que se basan en las creencias y suposiciones de Fastly y en la información actualmente disponible para Fastly en la fecha de este artículo. Las declaraciones prospectivas pueden implicar riesgos conocidos y desconocidos, incertidumbres y otros factores que pueden hacer que nuestros resultados, rendimiento o logros reales sean materialmente diferentes de los expresados o implícitos en las declaraciones prospectivas. Estas declaraciones incluyen, entre otras, las relativas al rendimiento futuro de los productos y a nuestra visión y objetivos para futuras operaciones. Salvo que lo exija la ley, Fastly no asume ninguna obligación de actualizar públicamente estas declaraciones prospectivas, ni de actualizar las razones por las que los resultados reales podrían diferir materialmente de los previstos en las declaraciones prospectivas, aunque en el futuro se disponga de nueva información. Los factores importantes que podrían hacer que los resultados reales de Fastly difirieran materialmente se detallan de vez en cuando en los informes que Fastly presenta ante la Comisión del Mercado de Valores (SEC), incluido nuestro Informe Anual en el Formulario 10-K para el año fiscal finalizado el 31 de diciembre de 2024, y nuestros Informes Trimestrales en el Formulario 10-Q. Las copias de los informes presentados ante la SEC se publican en el sitio web de Fastly y están disponibles en Fastly sin coste alguno.