Prevención de interrupciones mediante arquitecturas resilientes

No entraba en nuestras quinielas que la fiabilidad y la arquitectura descentralizada propias de nuestro plano de control fueran las funcionalidades clave de las que todo el mundo querría oír hablar esta semana, pero sorpresas te da la vida. Ningún proveedor de servicios en la nube es inmune a las interrupciones, pero en Fastly trabajamos sin descanso para prevenir estos riesgos aumentando la resiliencia y la redundancia de nuestra red, nuestro plano de control y nuestro plano de datos. El objetivo es protegernos frente a errores catastróficos, ya sea evitando que ocurran en primera instancia o reduciendo su gravedad en caso de que se produzcan. 

Sentimos una gran empatía hacia los compañeros del sector que ha sufrido interrupciones recientemente y nos gustaría darles un abrazo al más puro estilo #hugops. Esta es la peor de nuestras pesadillas. Hemos decidido redactar este artículo sobre nuestra forma de entender la resiliencia porque es algo por lo que nos han preguntado muchos de nuestros clientes durante la última semana.

Veamos qué decisiones hemos tomado hasta ahora y qué trabajo hemos realizado durante varios años para que Fastly sea más resiliente ante absolutamente todo, desde eventos imprevistos con graves consecuencias, como la pérdida total de un centro de datos, hasta otras situaciones más habituales, como los cortes de internet o los ataques de DDoS sofisticados. Fastly integra la resiliencia en los planos de control y datos, pero también en su red global y la gestión del tráfico, por mencionar solo algunos ejemplos. Cuando llegues al final de este artículo, entenderás por qué Fastly lleva la resiliencia y la redundancia en los genes. 

Las soluciones descentralizadas reducen los puntos de error únicos

Dos de los principios más importantes que se aplican a lo largo y ancho de la plataforma de Fastly son el desarrollo de sistemas descentralizados y la eliminación de puntos de error únicos. 

Hace cosa de tres años, Fastly puso en marcha un proceso formal para evaluar y reforzar nuestra arquitectura de forma continua del que se encargó Reliability Task Force (RTF), un equipo multidisciplinar interno. Los integrantes de RTF se reúnen periódicamente para estudiar la mitigación de riesgos en nuestra plataforma mediante el triaje, la evaluación, el debate y la priorización. Este equipo ha desempeñado un papel fundamental a la hora de impulsar mejoras de gran calado y planificar los pasos siguientes. En parte, formamos el equipo de RTF porque nos dimos cuenta de que Fastly no estaba preparada para hacer frente a un corte de electricidad en un centro de datos (ahora sí lo está). Para abordar este problema y los riesgos asociados, pusimos en marcha una iniciativa en toda la empresa a la que llamamos «Cloudvolution» por dos motivos. En primer lugar, porque queríamos adoptar un modelo transformador y en constante evolución para el funcionamiento de toda nuestra plataforma y así crear una arquitectura multinube y multirregión más resiliente. En segundo lugar, porque nos parecía un nombre gracioso y pensábamos que jamás tendríamos que desvelarlo en público. ¡No hace falta usar siglas para todo!

Resiliencia de los planos de control y datos

Nuestra intención con Cloudvolution era reforzar tanto el plano de control como el plano de datos y ampliar la disponibilidad de los servicios clave de nuestra plataforma para disfrutar de una resiliencia superior. Uno de nuestros principales objetivos consistía en hacer evolucionar las abstracciones del diseño del sistema de manera iterativa para aumentar la resiliencia, establecer límites mejor definidos entre los servicios y adaptar nuestra propia escalabilidad a un volumen de clientes cada vez mayor. Básicamente, queríamos reducir las dependencias, los riesgos y los puntos de error y, al mismo tiempo, ganar en resiliencia. 

Sabíamos que esta mejora en la arquitectura sería una pieza clave para seguir ofreciendo un servicio fiable en caso de desastre. En la actualidad, nuestros planos de control y datos son multinube y multirregión. Nos hemos empleado a fondo para garantizar que Fastly no dependa de un solo centro de datos, una sola zona de disponibilidad o un solo proveedor de servicios en la nube. El plano de control se ejecuta en dos regiones independientes que están separadas geográficamente y cuenta con un sistema de recuperación de fallos que cede el testigo a la segunda cuando la situación lo requiere. De manera similar, el plano de datos (que está detrás de nuestras funcionalidades de observabilidad y análisis) también tiene dos regiones independientes y un sistema de recuperación de fallos, pero se encuentra en un servicio en la nube distinto al del plano de control. Esto limita la «onda expansiva» de cualquier error catastrófico y reduce considerablemente las probabilidades de que nuestras capacidades para observar (plano de datos) y tomar medidas (plano de control) queden fuera de juego simultáneamente en un momento dado. 

También nos aseguramos de que, si se produce un fallo, nuestros centros de datos puedan acudir a la red eléctrica o sistemas de alimentación ininterrumpida con generadores secundarios, pero no basta con que estos elementos estén incluidos en una lista. Nuestro plan de continuidad del negocio contempla la ejecución de sistemas de recuperación de fallos entre regiones activas y en reposo para probar estas funcionalidades constantemente en caso de que un proveedor de servicios en la nube sufra una interrupción. 

Cuando nuestros planos de control y datos pasaron a formar parte de esta arquitectura mejorada, nos dimos cuenta de que debíamos facilitar la labor de nuestros equipos de ingeniería para que todo lo desarrollado por Fastly fuera lo más resiliente posible. Hicimos que nuestros planos de control y datos funcionaran como una plataforma de integración para que estos equipos pudieran crear productos y funcionalidades caracterizados por la seguridad, la escalabilidad y la resiliencia, incluso en el caso de las pruebas más insignificantes y los proyectos en fases tempranas. Esto nos permite reducir aún más el riesgo, ya que los equipos de ingeniería más pequeños no están obligados a recrear sus propias versiones de los sistemas principales para añadir novedades. Cualquiera puede desarrollar con total seguridad y resiliencia sin dificultad, pero la cosa no acaba ahí.

Ahora que ya hemos abordado nuestras prioridades originales, RTF sigue identificando áreas que tienen margen de mejora, y ya estamos trabajando en la próxima iteración de nuestros planos de control y datos. Como estos cambios pueden tardar años en implementarse por completo, resulta fundamental empezar a trabajar en determinados aspectos antes de que hagan falta. Ya estamos avanzando en nuestros planes para separar aún más las abstracciones persistentes del sistema en el plano de control durante el año que viene, lo cual contribuirá a hacerlo más resiliente y a agilizar el desarrollo de productos.

Resiliencia de la red más allá del plano de control

Los fallos en los centros de datos que afectan a los planos de control y datos de una plataforma no son la única dificultad que puede presentarse cuando se gestiona una plataforma en la red del borde que promete una alta disponibilidad y una baja latencia. Ahora que ya hemos hablado de la descentralización y la resiliencia de nuestros planos de control y datos, veamos cómo hemos diseñado la red del borde de Fastly para evitar puntos de error únicos y mitigar los problemas de forma inmediata, automática e inteligente. Por norma general, cuando hablamos de resiliencia en Fastly, nos referimos a nuestra red del borde y nuestros servicios de distribución de contenidos.

Gestión resiliente del tráfico y las interrupciones en la red

Las anomalías en el tráfico, los problemas de latencia y los cortes de internet son el pan de cada día para una red tan extensa como la de Fastly. En un momento dado, el conjunto de los proveedores de tráfico de internet puede experimentar entre unos pocos y unos cientos de esos episodios transitorios y de corta duración de deterioro del rendimiento o de la conectividad a los que solemos referirnos como «clima de internet». Aunque algunos cortes de internet se hacen notar en todo el mundo debido a su gran envergadura, la mayoría de ellos son más pequeños y breves. Sin embargo, estos también pueden afectar tanto a la latencia como al rendimiento y acabar pasando factura. 

En la actualidad, el sector emplea técnicas como cambiar el enrutamiento del protocolo de puerta de enlace de frontera (BGP) a modo de práctica recomendada, pero como BGP no incorpora funcionalidades de detección de fallos a nivel de aplicación, un problema puede tardar horas en resolverse, y eso es demasiado tiempo. Un sistema de supervisión u observabilidad independiente de BGP debe detectar el problema, identificar las rutas afectadas, trazar una solución y, por último, utilizar BGP para imponer restricciones que cambien la topología de la red y eliminen dichas rutas. Una vez enviadas las instrucciones correspondientes, BGP puede solucionar un problema con rapidez, pero todos los pasos anteriores pueden llevar minutos u horas. En definitiva, BGP no es precisamente efectivo cuando se produce una interrupción o un corte breve en la red y hay que realizar ajustes muy concretos. Por norma general, cuando BGP tiene listos los cambios, los problemas se han resuelto por sí solos y no sirven de nada para los sitios web y las aplicaciones que han sufrido las consecuencias durante cada segundo de interrupción y han tenido que esperar a que las cosas vuelvan a funcionar.

Puede que en Fastly no controlemos la red global, pero eso no nos exime de encontrar maneras de ofrecer un servicio más robusto y resiliente a nuestros clientes. A continuación veremos algunas de las innovaciones que nos permiten poner las experiencias más ágiles y fiables al alcance de nuestros clientes y sus usuarios finales. Estos avances en las operaciones en la red del borde no serían posibles sin la arquitectura de una red moderna definida mediante software, ya que eso nos permite desplegar lógica en todas las capas, ampliar los flujos de red y ajustarlos de la forma que más convenga con el objetivo de eludir los problemas que plantea internet, además de garantizar la disponibilidad y la fiabilidad.

Debemos destacar dos puntos importantes al respecto: primero, que nuestros sistemas están automatizados, se recuperan solos y pueden responder inmediato sin necesidad de intervención humana; y segundo, que se aprovisionan en toda nuestra flota de puntos de presencia (POP).

Menos dependencias para abordar el clima de internet

Nos encanta resolver problemas, así que lo peor del clima de internet es que cortarlos de raíz no está en nuestras manos. Estos problemas surgen en una parte de la infraestructura global que alguien gestiona o tiene en su poder, por lo que están fuera de nuestro control. No obstante, sí podemos controlar ciertas cosas, por lo que hemos desarrollado métodos para mejorar nuestro servicio y hacer frente al clima adverso. El primero es una tecnología a la que llamamos recuperación rápida de fallos en rutas. 

La recuperación rápida de fallos en rutas detecta y vuelve a enrutar las conexiones en el edge con un rendimiento insuficiente que se encuentran en la capa de transporte. De esta forma, podemos mitigar los efectos negativos del clima de internet que tienen su origen fuera de nuestros POP. Un clima de internet adverso no siempre se traduce en una desconexión total. A veces simplemente hay mucha latencia o algo similar: técnicamente, el nodo de la red sigue estando conectado, pero la conexión está tan degradada que acaba dando problemas. La solución más generalizada consiste en utilizar BGP para alejar el tráfico de las rutas en mal estado. Esto puede estar bien cuando todo se ha venido abajo, pero es un completo desastre para las conexiones deterioradas. 

Cuando un nodo de una ruta deja de estar disponible, BGP puede retirar las rutas que pasan por él y señalar rutas alternativas, si es que las hay. De este modo, los proveedores de servicios de internet pueden redirigir el tráfico y sortear el problema. No obstante, cuando una ruta está muy deteriorada pero no totalmente inactiva, existe la posibilidad de que BGP no la retire. A veces, el proveedor de servicios debe detectar el problema y redirigir el tráfico de forma manual, proceso que puede llevar desde unos minutos hasta varias horas dependiendo del proveedor. 

La recuperación rápida de fallos no espera a que BGP saque del embrollo a los clientes de Fastly. Si algo va mal, queremos que el tráfico se redirija al momento para que todo vuelva a funcionar cuanto antes. Este sistema detecta y redirige automáticamente las conexiones con un rendimiento insuficiente en el edge sin esperar a que BGP solucione el problema en toda la red. No tenemos que quedarnos de brazos cruzados hasta que un tercero o un proveedor de tránsito nos diga que una ruta no funciona porque podemos verlo nosotros mismos ni tenemos que esperar a que ponga su solución en marcha para probar una ruta distinta por nuestra cuenta. Nuestros servidores de edge cloud pueden determinar si las conexiones progresan adecuadamente, valorar el estado de la ruta y seleccionar otra a toda velocidad en caso necesario. 

Otra ventaja de nuestra arquitectura es que no dependemos de enrutadores físicos centralizados que crean atascos en los enrutamientos para todo un POP. Nuestros servidores en el edge pueden actuar rápido y de manera descentralizada a la hora de tomar decisiones relativas al enrutamiento para cada conexión. Así, las conexiones deterioradas se redirigen sin que afecte a aquellas en buen estado y la recuperación de fallos es más precisa. Este mecanismo resulta tremendamente eficaz para detectar y mitigar problemas en el clima de internet que son demasiado pequeños o breves para las técnicas de supervisión habituales. Hay más información sobre recuperación rápida de fallos en este enlace.

En algunas ocasiones, cuando la topología de la red depende mucho del clima de internet, puede que no exista una ruta alternativa por la que pasar el tráfico de otra con errores. Otros proveedores no ofrecen alternativas viables a este tipo de problemas, pero nosotros jamás damos un no por respuesta. La extraordinaria diversidad de Fastly en cuanto a opciones de tránsito y emparejamiento reduce considerablemente el riesgo de toparse con cuellos de botella en la red de camino a los usuarios finales.

Enrutamiento inteligente y automatizado del tráfico 

Si la recuperación rápida de fallos mejora la conectividad para las peticiones de contenido de la plataforma de edge cloud de Fastly que pasan por partes de internet que no controlamos, Precision Path y Autopilot aumentan el rendimiento en las zonas de la red de Fastly que sí controlamos.  

Precision Path mejora el rendimiento en las rutas de internet que unen los servidores de origen de los clientes y nuestra red, y Autopilot es nuestra solución de ingeniería para la automatización del tráfico de salida. Ambas herramientas hacen cosas increíbles cuando unen sus fuerzas y nos permiten reaccionar de inmediato, sin esperar a que un ser humano analice y trace un plan de acción. Esto es muy importante, ya que actuar cuanto antes es la clave para impedir que los problemas se propaguen y afecten a otras partes de la red.

Precision Path 

Precision Path supervisa constantemente todas las conexiones de origen en todos y cada uno de los POP de Fastly del mundo. En cuanto detecta una conexión de origen con un rendimiento insuficiente (debido a un clima de internet adverso, por ejemplo), identifica automáticamente todas las rutas alternativas posibles al origen afectado y redirecciona la conexión hacia la mejor alternativa en tiempo real. Esto significa que, en muchas ocasiones, podemos restablecer la conexión de origen antes de que los errores 5xx lleguen a los usuarios finales y solucionar los problemas de red tan rápido que es como si nunca hubieran existido. Además, nuestro envío de registros en tiempo real se puede utilizar para supervisar los redireccionamientos de las conexiones de origen que pueden darse en los servicios de Fastly. 

Precision Path también da prioridad a la distribución de contenido a los usuarios finales desde nuestra plataforma de edge cloud. Durante este proceso, hacemos un seguimiento del estado de todas las conexiones TCP. Si observamos que se produce congestión o algún otro tipo de degradación que afecte a la conexión, la recuperación rápida de fallos se encarga de pasar automáticamente la distribución a otra ruta y, así, eludir el problema. Esta mitigación automática está habilitada de forma predeterminada en todos nuestros POP y se aplica a todo el tráfico de Fastly sin tener que configurar nada.

Autopilot

Gracias a Autopilot, pudimos distribuir nada menos que 81,9 Tbit/s de tráfico durante la última Super Bowl sin ningún tipo de intervención humana, una cifra de récord a la altura de este acontecimiento deportivo. Desde febrero de 2023, nuestro tráfico ha pulverizado esta marca en muchas ocasiones, claro ejemplo de que cualquier día puede ser tan ajetreado o más que el de la Super Bowl. En otras palabras, la escalabilidad no es útil solo una vez al año, sino que nos permite optimizar el tráfico y la eficiencia de Fastly a diario.

Al igual que la recuperación rápida de fallos, Autopilot se diseñó pensando en las limitaciones del protocolo BGP. La capacidad es un misterio para BGP; es decir, solo se puede utilizar para comunicar si un destino de internet se puede alcanzar o no y no sabe si hay capacidad suficiente para distribuir la cantidad de tráfico deseada ni cuáles serían el rendimiento y la latencia. Es como si un transportista te dijera que puede entregar tu paquete, se lo llevara y se diera cuenta de que no le cabe en la furgoneta.

Para resolver este problema, Autopilot calcula constantemente la capacidad residual de nuestros nodos y el rendimiento de las rutas en la red. Esta información se recopila cada minuto mediante parámetros de la red y se utiliza para optimizar la asignación del tráfico e impedir que los nodos se congestionen. Precision Path es rápido como el rayo, pero se limita a alejar el tráfico de las conexiones inadecuadas. Apenas sabe nada de las nuevas cuando toma este tipo de decisiones. Autopilot tarda algo más en reaccionar, pero toma decisiones mejor fundamentadas a partir de los datos de telemetría a alta resolución de varios minutos de la red. En vez de limitarse a sacar el tráfico de una ruta con errores, como Precision Path, traslada mayores volúmenes de tráfico hacia mejores partes de una red. 

La combinación de estos dos sistemas permite redirigir flujos con rapidez a rutas más fluidas, así como ajustar periódicamente la configuración general de enrutamiento con los datos necesarios en la mano. Estos sistemas funcionan de manera ininterrumpida, y no hay más que fijarse en los datos de la Super Bowl para darse cuenta de lo eficientes que son. Durante este acontecimiento, redirigieron respectivamente 300 Gbit/s y 9 Tbit/s de tráfico que, de otro modo, habrían atravesado rutas congestionadas o con un rendimiento insuficiente y habrían provocado atascos en más puntos de la red de Fastly. Estas capacidades de autogestión nos permiten reaccionar más rápido y con mayor frecuencia a los posibles fallos, la congestión y el deterioro del rendimiento en nuestra red.

Autopilot aporta muchas ventajas a Fastly, pero es todavía mejor para nuestros clientes, que ahora pueden confiar aún más en nuestra capacidad de gestionar incidentes como errores de proveedores de red o ataques de DDoS y picos inesperados de tráfico, todo ello mientras los usuarios finales disfrutan de una experiencia fluida y sin trabas. Hay más información sobre Autopilot y Precision Path en este enlace. 

Protección automatizada frente a ataques de DDoS a gran escala

No todos los errores de red son accidentales. Un aspecto clave de la resiliencia de nuestra red es la capacidad para aguantar ataques de denegación de servicio distribuido (DDoS) a gran escala, como el reciente Rapid Reset. Este ataque sigue causando estragos en internet, pero no afectó a Fastly porque contábamos con un sistema automatizado que fue capaz de identificarlo y mitigarlo inmediatamente utilizando una técnica a la que llamamos «revelación de atributos».

Revelación de atributos

Los ataques de DDoS han ido ganando en agresividad y escalabilidad con el tiempo. A menudo pasan de cero a millones e incluso cientos de millones de peticiones por segundo en un momento y terminan igual de rápido, a veces en menos de un minuto. También son cada vez más sofisticados, como es el caso de Rapid Reset, un ataque reciente que fue el primero en aprovecharse de una vulnerabilidad del protocolo HTTP/2. 

Rapid Reset, que hasta hace poco era un ataque desconocido, sembró el caos en la mayoría de las plataformas importantes. Nosotros, en cambio, utilizamos la revelación de atributos cuando Rapid Reset llamó a nuestra puerta para extraer huellas digitales de manera rápida, precisa y automática, y lo mejor es que funciona exactamente igual con otros ataques complejos. Todas las peticiones que pasan por una red tienen un número elevado de características que se pueden usar para describir el tráfico, como encabezados de las capas 3 y 4, información de TLS y datos de la capa 7. Nuestro sistema incorpora los metadatos de las peticiones entrantes a nuestra red y los emplea para distinguir el tráfico malicioso del legítimo, lo que nos permite bloquear el primero y dejar paso al segundo.

Para agilizar la respuesta, la protección frente a DDoS se gestiona desde el edge de nuestra red mediante los mecanismos de detección y defensa integrados en el kernel y el stack de procesamiento en la capa de la aplicación. Este es otro ejemplo de una solución descentralizada que, del mismo modo que la recuperación rápida de fallos, solo es posible porque nuestra red está totalmente definida por software, lo que nos permite ejecutar funciones en paralelo en nuestros servidores. Como nuestro sistema también es modular, podemos mejorar las funcionalidades de detección y mitigación al vuelo a medida que surgen nuevos tipos de ataques, sin necesidad de desarrollar mecanismos de respuesta desde cero. Cuando se produce un ataque como Rapid Reset, tan solo tenemos que añadir unas cuantas funciones nuevas a los módulos de detección y respuesta. Esta es la razón por la que actuamos tan rápido, incluso ante ataques inéditos. Hay más información sobre la revelación de atributos y el ataque Rapid Reset en este enlace.

La resiliencia es un proceso

Hemos tratado muchos temas en este artículo, así que ahí va un resumen de lo que hacemos en Fastly: 

1. Nos preguntamos qué puede fallar desde el primer momento en lugar de esperar a que se produzca un problema.

2. Dedicamos una cantidad considerable de recursos a mejorar nuestra arquitectura.

3. Detectamos y eliminamos riesgos relacionados con los puntos de error únicos constantemente.

4. Identificamos formas innovadoras de prepararnos y solucionar problemas que se producen en zonas fuera de nuestro control.

5. Sabemos que este trabajo es continuo, intentamos prepararnos para el futuro y siempre nos preguntamos qué más podemos hacer. 

Si quieres conocer mejor la forma en que trabajamos y saber qué ventajas aportan estos avances a nuestros clientes en términos de seguridad, rendimiento y eficiencia, prueba nuestro plan gratuito o contacta hoy mismo con Fastly.