Una interrupción en los servicios de Amazon Web Services (AWS) afectó a millones de usuarios a nivel global. Según un análisis interno de los ingenieros de la compañía, el incidente se originó en un único punto de fallo que se propagó a través de la extensa red de Amazon.
La cadena de errores se extendió durante 15 horas y 32 minutos, según informó Amazon. La empresa de inteligencia de redes Ookla reportó que su servicio DownDetector recibió más de 17 millones de informes sobre interrupciones en servicios ofrecidos por 3,500 organizaciones. Los países con mayor número de reportes fueron Estados Unidos, Reino Unido y Alemania. Los servicios más afectados, según los informes, fueron Snapchat, AWS y Roblox. Ookla calificó el evento como “una de las mayores interrupciones de Internet registradas por Downdetector”.
La causa raíz: un error en el DNS
Amazon identificó la causa principal de la interrupción como un error de software en el sistema de gestión de DNS de DynamoDB. Este sistema monitorea la estabilidad de los balanceadores de carga, creando periódicamente nuevas configuraciones de DNS para los puntos finales dentro de la red de AWS. El problema específico fue una condición de carrera, un tipo de error que hace que un proceso dependa del tiempo o la secuencia de eventos variables, lo que puede generar comportamientos inesperados y fallos.
En este caso, la condición de carrera se encontraba en el DNS Enactor, un componente de DynamoDB que actualiza constantemente las tablas de búsqueda de dominios en los puntos finales de AWS para optimizar el balanceo de carga. El Enactor experimentó “retrasos inusualmente altos, necesitando reintentar su actualización en varios de los puntos finales de DNS”. Mientras el Enactor intentaba ponerse al día, otro componente de DynamoDB, el DNS Planner, continuó generando nuevos planes. Posteriormente, un segundo DNS Enactor comenzó a implementar estos nuevos planes.
La sincronización de estos dos Enactors desencadenó la condición de carrera, que finalmente afectó a todo DynamoDB. Los ingenieros de Amazon explicaron el proceso de la siguiente manera:
Cuando el segundo Enactor (aplicando el plan más reciente) completó sus actualizaciones de punto final, 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 regional de DDB, sobrescribiendo el plan más reciente. La verificación que se realizó al inicio del proceso de aplicación del plan, que garantiza que el plan sea más nuevo que el plan aplicado anteriormente, estaba obsoleta en este momento debido a los retrasos inusualmente altos en el procesamiento del Enactor. Por lo tanto, esto no impidió que el plan anterior sobrescribiera el plan más reciente. El proceso de limpieza del segundo Enactor luego eliminó este plan anterior porque era muchas generaciones más antiguo que el plan que acababa de aplicar. Cuando se eliminó este plan, todas las direcciones IP para el punto final regional se eliminaron de inmediato. Además, debido a que el plan activo se eliminó, el sistema quedó en un estado inconsistente que impidió que los Enactors de DNS aplicaran actualizaciones de planes posteriores. Esta situación finalmente requirió la intervención manual del operador para corregir.
Este fallo provocó que los sistemas que dependían de DynamoDB en el punto final regional US-East-1 de Amazon experimentaran errores que les impidieron conectarse. Tanto el tráfico de los clientes como los servicios internos de AWS se vieron afectados.
El daño resultante del fallo de DynamoDB ejerció presión sobre los servicios EC2 de Amazon ubicados en la región US-East-1. La tensión persistió incluso después de que se restauró DynamoDB, ya que EC2 en esta región trabajó a través de una “importante acumulación de propagaciones de estado de red que debían procesarse”. Los ingenieros continuaron diciendo: “Si bien las nuevas instancias de EC2 podrían iniciarse con éxito, no tendrían la conectividad de red necesaria debido a los retrasos en la propagación del estado de la red”.
A su vez, el retraso en las propagaciones del estado de la red se extendió a un balanceador de carga de red del que dependen los servicios de AWS para la estabilidad. Como resultado, los clientes de AWS experimentaron errores de conexión desde la región US-East-1. Las funciones de red de AWS afectadas incluyeron la creación y modificación de clústeres de Redshift, las invocaciones de Lambda y los lanzamientos de tareas de Fargate, como Managed Workflows para Apache Airflow, las operaciones del ciclo de vida de Outposts y el Centro de soporte de AWS.
Por el momento, Amazon ha desactivado la automatización de DynamoDB DNS Planner y DNS Enactor en todo el mundo mientras trabaja para solucionar la condición de carrera y agregar protecciones para evitar la aplicación de planes DNS incorrectos. Los ingenieros también están realizando cambios en EC2 y su balanceador de carga de red.
Una lección aprendida
Ookla destacó un factor contribuyente no mencionado por Amazon: una concentración de clientes que enrutan su conectividad a través del punto final US-East-1 y la incapacidad de enrutar alrededor de la región. Ookla explicó:
El US-EAST-1 afectado es el centro más antiguo y más utilizado de AWS. La concentración regional significa que incluso las aplicaciones globales a menudo anclan los flujos de identidad, estado o metadatos allí. Cuando falla una dependencia regional, como fue el caso en este evento, los impactos se propagan por todo el mundo porque muchas pilas “globales” se enrutan a través de Virginia en algún momento.
Las aplicaciones modernas encadenan servicios administrados como almacenamiento, colas y funciones sin servidor. Si DNS no puede resolver de manera confiable un punto final crítico (por ejemplo, la API de DynamoDB involucrada aquí), los errores se propagan a través de las API ascendentes y causan fallas visibles en las aplicaciones que los usuarios no asocian
Fuente original: ver aquí