Un colapso de un sistema distribuido puede comenzar con un error que parece limitado, pero transformarse rápidamente en una cadena de fallos cuando muchos componentes dependen unos de otros. En una presentación ofrecida por Sam Newman, el consultor independiente de ingeniería de software relaciona el concepto de colapso progresivo (Progressive Collapse) en la ingeniería civil con los problemas de resiliencia de los sistemas digitales, y concluye que no es posible prevenir todos los errores, pero sí reducir las probabilidades de que se propaguen y su impacto.
Del edificio Ronan Point a los servicios en la nube
Newman se remonta al incidente de colapso parcial de la torre Ronan Point, en la zona de Canning Town, en Londres, en 1968. Una explosión de gas limitada dentro del apartamento de Mrs. Ivy Hodge arrancó un muro exterior que sostenía parte del edificio. Los cuatro pisos situados sobre el lugar de la explosión se derrumbaron, lo que después provocó la caída de parte de una esquina de la torre en un efecto en cadena. Murieron cuatro personas, y el momento del incidente, poco antes de las seis de la mañana, ayudó a limitar el número de víctimas.
La importancia para el software no reside en la similitud física entre un edificio y un servicio digital, sino en el patrón de fallo: un pequeño fallo inicial deshabilita un componente del que dependen otros componentes, por lo que el alcance del daño se amplía. Esta cadena es difícil de comprender en los sistemas distribuidos porque las relaciones entre servicios, bases de datos, balanceadores de carga y sistemas DNS no siempre son visibles como una fila de fichas de dominó.
Ejemplos digitales de fallos en cadena
Durante la interrupción de la región us-east-1 de AWS en octubre, un subcomponente de DynamoDB tuvo un problema al actualizar las rutas DNS dentro de la infraestructura de AWS. Un fallo en el proceso de actualización de los planes provocó la eliminación de rutas en Route 53; después, comenzaron a fallar los servicios que dependían de esas rutas, incluidos los balanceadores de carga de red, la computación, las colas y EKS. Como estos servicios fundamentales son utilizados por otros servicios, el problema se propagó a productos y empresas orientados a los usuarios, entre ellos Alexa, Ring, Slack, Snapchat, Zoom y Shopify; algunos se vieron afectados parcialmente y otros por completo.
Según la explicación de Newman, basada en el informe de AWS, el sistema incluía un planificador que creaba planes de cambios de DNS y varios ejecutores que los aplicaban. Uno de los planes tardó más de lo habitual; después se creó otro plan que un ejecutor diferente ejecutó rápidamente. Cuando la ejecución del plan antiguo terminó más tarde, eliminó las rutas que había creado el plan nuevo. El resultado fue una condición de carrera (Race Condition) que provocó la eliminación de entradas DNS.
El segundo ejemplo fue un sitio de venta de automóviles usados, motocicletas y remolques que funcionaba mediante una aplicación con el nombre en clave Sauron en diez servidores. La aplicación solía gestionar entre 30 y 60 solicitudes simultáneas, pero recibió más de 800. Uno de los sitios dependientes aceptaba las conexiones y después quedaba bloqueado sin responder, mientras la aplicación esperaba 30 segundos antes de finalizar la solicitud. El grupo de conexiones se agotó; después, los hilos de software se acumularon y los procesadores consumieron su tiempo gestionándolos, hasta que el sistema se detuvo por completo. Los usuarios aumentaron la presión al pulsar repetidamente el botón de actualización.
Tres vías para reducir el colapso
Newman considera que centrarse en una única «causa raíz» conduce a una simplificación excesiva. Prevenir la chispa puede ser útil, pero no aborda todas las condiciones que permiten que el incendio se propague. Por ello, la ingeniería de resiliencia se centra en aceptar la posibilidad de que ocurran fallos y prepararse para limitar sus efectos mediante tres categorías interrelacionadas:
- Reducir los riesgos: eliminar las fuentes de peligro o limitar su capacidad para agotar los recursos. En el caso de AWS, esto incluyó detener temporalmente la gestión automatizada de DNS hasta resolver el problema y añadir mejores pruebas para el componente. En la aplicación Sauron, podría haberse utilizado el descarte de carga (Load Shedding) para aceptar un número determinado de solicitudes y rechazar las que superaran la capacidad del sistema, en lugar de permitir que se acumularan hasta provocar el colapso.
- Reforzar los componentes: aumentar la capacidad del servicio para soportar el fallo de una parte mediante redundancia, supervisión, pruebas y mejoras de implementación. Esto puede significar ejecutar varias copias del servicio detrás de un balanceador de carga, pero la decisión depende de la importancia del componente y de su coste; la aplicación Sauron se encontraba en proceso de retirada y representaba solo una parte de los ingresos, por lo que ejecutar copias de respaldo adicionales no era una opción comercialmente atractiva en ese momento.
- Reducir la interdependencia: impedir que el fallo de un componente se transmita al resto del sistema. Esto incluye utilizar compartimentos estancos (Bulkheads), límites de tiempo de espera, rutas alternativas y diseños locales por defecto cuando sea posible. Cuanto menor sea la dependencia de una parte del sistema respecto de otra, más fácil será contener el fallo en lugar de propagarlo.
¿Qué cambia en la práctica para los equipos técnicos?
La resiliencia no significa ejecutar automáticamente el sistema en dos regiones o dos nubes. Newman explica que las opciones van desde la copia de seguridad y la recuperación, pasando por una arquitectura Pilot Light que replica los datos sin ejecutar toda la infraestructura, hasta la recuperación en caliente y, finalmente, la ejecución simultánea de dos sitios activos. Estas opciones reducen progresivamente el tiempo de inactividad y la pérdida de datos, pero aumentan el coste y la complejidad.
También advierte que considerar la sincronización bidireccional entre sitios como algo sencillo puede ser problemático, especialmente al añadirla a una aplicación existente que no fue diseñada para ello. Lo mismo se aplica a las múltiples nubes: pueden reducir la dependencia de un único proveedor, pero requieren habilidades y operaciones diferentes para cada plataforma, y no basta con desplegar el mismo código en AWS y Azure para garantizar la independencia, porque el mismo defecto de software podría interrumpir ambos entornos.
Conclusión
La lección principal es que la resiliencia no consiste en buscar un entorno que nunca falle, sino en diseñar el sistema de modo que una parte siga siendo operativa cuando otra falle. Por ello, deben evaluarse los riesgos, los límites de capacidad, los cuellos de botella y las rutas de dependencia, y después equilibrar la redundancia, el aislamiento y el coste. Las decisiones como operar en múltiples regiones o múltiples nubes siguen siendo opciones de ingeniería y comerciales vinculadas a la importancia del servicio, no una receta general aplicable a todos los sistemas.