Editor Top
Cuando AWS sufrió una serie de fallos en cascada que colapsó sus sistemas durante horas a finales de octubre, la industria recordó una vez más su extrema dependencia de los principales hiperescaladores. (Como para probar el punto, Microsoft sufrió un colapso similar unos días después.)
El incidente también arrojó una luz incómoda sobre lo frágiles que se han vuelto estos entornos masivos. En Amazon informe post mortem detalladoel gigante de la nube detalló una amplia gama de sistemas delicados que mantienen en funcionamiento las operaciones globales, al menos la mayor parte del tiempo.
Es impresionante que esta combinación de sistemas funcione tan bien, y ahí radica el problema. Las bases para este entorno se crearon hace décadas. Y si bien Amazon merece un aplauso por lo brillante que fue ese sistema cuando se creó, el entorno, la escala y la complejidad que enfrentan los hiperescaladores hoy en día son órdenes de magnitud más allá de lo que esos diseñadores originales imaginaron.
El método del parche atornillado simplemente ya no es viable. Todos los hiperescaladores, especialmente AWS, necesitan sistemas rediseñados, si no sistemas completamente nuevos, que puedan soportar a los usuarios globales para 2026 y más allá.
Chris Ciabarrael CTO de Athena Security, leyó la autopsia de AWS y se mostró incómodo.
«Amazon está admitiendo que una de sus herramientas de automatización destruyó parte de su propia red», dijo Ciabarra. «La interrupción expuso cuán profundamente interdependientes y frágiles se han vuelto nuestros sistemas. No proporciona ninguna confianza de que no volverá a suceder. ‘Mejores salvaguardias’ y ‘mejor gestión de cambios’ suenan como correcciones de procedimiento, pero no son prueba de resiliencia arquitectónica. Si AWS quiere recuperar la confianza empresarial, necesita mostrar pruebas contundentes de que un incidente regional no puede volver a afectar su red global. En este momento, los clientes todavía cargan con la mayor parte de ese riesgo».
catalin voicuingeniero de nube de N2W Software, se hizo eco de algunas de las mismas preocupaciones.
«La arquitectura subyacente y las dependencias de la red siguen siendo las mismas y no desaparecerán a menos que haya una nueva arquitectura completa de AWS», dijo Voicu. «AWS afirma tener una disponibilidad del 99,5% por este motivo. Pueden poner curitas en los problemas, pero la naturaleza de estos hiperescaladores es que los servicios principales vuelven a llamar a regiones específicas. Esto no va a cambiar pronto».
Analista principal de Forrester Brent EllisLa interpretación de la autopsia es que AWS, al igual que otros hiperescaladores, tiene servicios que son puntos únicos de falla que no están bien documentados.
Aunque Ellis enfatizó que “AWS está realizando una increíble cantidad de operaciones aquí”, agregó que “ninguna cantidad de instalaciones bien diseñadas [technology] Los habría protegido de este problema”.
Ellis estuvo de acuerdo con otros en que AWS no detalló por qué Esta falla en cascada ocurrió ese día, lo que dificulta que los ejecutivos de TI empresariales tengan una gran confianza en que algo similar no sucederá en un mes. «Hablaron de qué cosas fallaron y no de qué causó la falla. Normalmente, fallas como ésta son causadas por un cambio en el entorno. Alguien escribió un script y cambió algo o alcanzaron un umbral. Podría haber sido tan simple como una falla de disco en uno de los nodos. Tiendo a pensar que es un problema de escala».
La conclusión clave de Ellis: los hiperescaladores deben considerar seriamente los cambios arquitectónicos importantes. «Crearon un montón de soluciones para los problemas que encontraron internamente. Esto significa que el primer hiperescalador está sufriendo un poco de deuda técnica. Las decisiones arquitectónicas no duran para siempre», dijo Ellis. «Estamos llegando al punto en el que se necesita más».
Profundicemos en lo que dijo AWS. Aunque muchos informes atribuyeron las fallas en cascada a problemas de DNS, no está claro qué tan cierto es eso. De hecho, parece que los sistemas DNS fueron donde se detectaron los problemas por primera vez, pero AWS no dijo explícitamente qué provocó el problema de DNS.
AWS dijo que los problemas comenzaron con «aumentos en las tasas de error de API» en su región US-East-1, que fueron seguidos inmediatamente por el «Network Load Balancer (NLB) de AWS experimentó un aumento de errores de conexión para algunos balanceadores de carga». Dijo que los problemas de NLB fueron «causados por fallas en los controles de estado de la flota de NLB, lo que resultó en un aumento de errores de conexión en algunos NLB». Luego, AWS detectó que «fallaron los lanzamientos de nuevas instancias EC2», seguido de «algunas instancias recién lanzadas experimentaron problemas de conectividad».
A partir de ahí surgieron cosas malas. «Los clientes experimentaron mayores tasas de error de la API de Amazon DynamoDB en la región N. Virginia (us-east-1). Durante este período, los clientes y otros servicios de AWS con dependencias de DynamoDB no pudieron establecer nuevas conexiones al servicio. El incidente fue provocado por un defecto latente dentro del sistema automatizado de administración de DNS del servicio que causó fallas en la resolución de puntos finales para DynamoDB».
Luego, AWS ofreció esta teoría: «La causa principal de este problema fue una condición de carrera latente en el sistema de administración de DNS de DynamoDB que resultó en un registro DNS vacío incorrecto para el punto final regional del servicio (dynamodb.us-east-1.amazonaws.com) que la automatización no pudo reparar».
Y entonces sucedió algo maravilloso: «Aunque el Centro de soporte logró realizar la conmutación por error a otra región según lo diseñado, un subsistema responsable de los metadatos de la cuenta comenzó a proporcionar respuestas que impedían que los usuarios legítimos accedieran al Centro de soporte de AWS. Si bien hemos diseñado el Centro de soporte para evitar este sistema si las respuestas no eran exitosas, en este caso, este subsistema devolvía respuestas no válidas. Estas respuestas no válidas provocaron que el sistema bloqueara inesperadamente a los usuarios legítimos para que no pudieran acceder a las funciones de los casos de soporte».
Esta sección es bastante larga, pero quiero dejar que AWS lo explique con sus propias palabras:
«La condición de carrera implica una interacción improbable entre dos de los Enactors DNS. En operaciones normales, un Enactor DNS elige el último plan y comienza a trabajar a través de los puntos finales de servicio para aplicar este plan. Este proceso generalmente se completa rápidamente y hace un trabajo eficaz al mantener el estado del DNS recién actualizado. Antes de comenzar a aplicar un nuevo plan, el Enactor DNS hace una verificación única de que su plan es más nuevo que el plan aplicado anteriormente. A medida que el Enactor DNS avanza a través de la lista de puntos finales, es posible encontrar retrasos mientras intenta realizar una transacción y es bloqueado por otro DNS Enactor que actualiza el mismo punto final. En estos casos, DNS Enactor volverá a intentar cada punto final hasta que el plan se aplique correctamente a todos los puntos finales.
“Justo antes de que comenzara este evento, un DNS Enactor experimentó retrasos inusualmente altos al necesitar volver a intentar su actualización en varios de los puntos finales de DNS. A medida que avanzaba lentamente en los puntos finales, también estaban sucediendo varias otras cosas. Primero, el Planificador de DNS continuó ejecutándose y produjo muchas generaciones más nuevas de planes. En segundo lugar, uno de los otros Enactors de DNS comenzó a aplicar uno de los planes más nuevos y avanzó rápidamente a través de todos los puntos finales. El momento de estos eventos desencadenó la condición de carrera latente. Cuando el segundo Enactor (que aplica el plan más nuevo) completó las actualizaciones de sus terminales, invocó el proceso de limpieza del plan, que identifica los planes que son significativamente más antiguos que el que acaba de aplicar y los elimina. Al mismo tiempo que se invocó este proceso de limpieza, el primer Enactor (que se había retrasado inusualmente) aplicó su plan mucho más antiguo al punto final DDB regional, sobrescribiendo el plan más nuevo. La verificación que se realizó al inicio del proceso de solicitud del plan, que garantiza que el plan sea más nuevo que el plan aplicado anteriormente, estaba obsoleta en ese momento debido a los retrasos inusualmente altos en el procesamiento de Enactor. “
Por lo tanto, esto no impidió que el plan anterior sobrescribiera el plan más nuevo. El segundo proceso de limpieza de Enactor luego eliminó este plan más antiguo porque era muchas generaciones más antiguo que el plan que acababa de aplicar. Como se eliminó este plan, todas las direcciones IP del punto final regional se eliminaron inmediatamente. Además, debido a que se eliminó el plan activo, el sistema quedó en un estado inconsistente que impidió que cualquier Enactor DNS aplicara actualizaciones posteriores del plan. Esta situación finalmente requirió la intervención manual del operador para corregirla”.
Cerca del final del informe, AWS habló sobre lo que estaba haciendo para solucionar la situación: «Estamos realizando varios cambios como resultado de este evento operativo. Ya hemos deshabilitado el planificador de DNS de DynamoDB y la automatización de DNS Enactor en todo el mundo. Antes de volver a habilitar esta automatización, arreglaremos el escenario de condición de carrera y agregaremos protecciones adicionales para evitar la aplicación de planes de DNS incorrectos. Para NLB, estamos agregando un mecanismo de control de velocidad para limitar la capacidad que un único NLB puede eliminar cuando las fallas en la verificación de estado causan una conmutación por error de AZ. Para EC2, «Estamos creando un conjunto de pruebas adicional para aumentar nuestras pruebas de escala existentes, que ejercitarán el flujo de trabajo de recuperación de DWFM para identificar cualquier regresión futura. Mejoraremos el mecanismo de aceleración en nuestros sistemas de propagación de datos EC2 para limitar el trabajo entrante en función del tamaño de la cola de espera para proteger el servicio durante períodos de alta carga».
Eso está muy bien, pero se siente como si se estuviera apagando una serie de incendios urgentes, sin un gran plan para evitar que algo como el apagón vuelva a ocurrir. En pocas palabras, AWS parece estar librando la batalla de ayer.
Es cierto que estos cambios podrían evitarlo. exacto Una serie de problemas vuelvan a ocurrir, pero hay un número casi infinito de otros problemas que podrían surgir. Y esa situación no va a mejorar. A medida que el volumen continúa aumentando y la complejidad (hola, IA agente) aumenta, choques como este ocurrirán con cada vez más frecuencia.
Si AWS, Microsoft, Google y otros se encuentran tan involucrados en sus entornos que no pueden hacer nada más que aplicar parches aquí y allá, es hora de que algunas nuevas empresas inteligentes lleguen con una tecnología limpia y construyan lo que se necesita.
La amenaza lógica: arréglenlo ustedes mismos, hiperescaladores, o dejen que algunas nuevas empresas financiadas por capital de riesgo lo hagan por ustedes.
