Lecciones de sistemas distribuidos a partir de los informes de incidentes de AWS (COE) - Principios de diseño transformados por los grandes incidentes del pasado
A partir de los Correction of Errors (COE) y los informes de incidentes publicados por AWS, explica las causas raíz de grandes incidentes del pasado, como el incidente de S3, el incidente de DNS en us-east-1 y el incidente de Kinesis, y cómo cambiaron los principios de diseño de AWS.
El contexto cultural de la publicación de incidentes en AWS
Cuando se produce un incidente a gran escala, AWS publica un Post-Event Summary (resumen posterior al incidente). Los informes publicados describen la cronología del incidente, la causa, el alcance del impacto y las medidas para evitar que se repita. El hecho de que AWS publique informes de incidentes detallados se relaciona con uno de los principios de liderazgo de Amazon, «Customer Obsession» (obsesión por el cliente). Ocultar la causa de un incidente puede dañar la confianza de los clientes a largo plazo. Se explica que AWS considera la transparencia sobre los incidentes un elemento imprescindible para generar confianza. Las autopsias que publica el equipo de SRE de Google y los informes de incidentes de Cloudflare son ejemplos conocidos de publicación detallada de incidentes.
El incidente de S3 de 2017 - El día en que una errata detuvo la mitad de Internet
El 28 de febrero de 2017 se produjo un incidente a gran escala en S3 en la región us-east-1, y S3 volvió a funcionar con normalidad a la 1:54 p. m. (PST). La causa del incidente fue que, durante un trabajo de depuración del sistema de facturación de S3, un operador ejecutó un comando que detuvo más servidores de los previstos. En concreto, aunque la intención era detener un número reducido de servidores, un error de escritura detuvo gran parte del subsistema de índices de S3 (el sistema que gestiona los metadatos de los objetos) y del subsistema de ubicación (el sistema que gestiona la ubicación física de los datos). Se vieron afectados otros servicios de AWS que dependen de S3 (la consola de S3, el lanzamiento de nuevas instancias de EC2, los volúmenes de EBS que usan instantáneas de S3 y Lambda). Como la consola de administración del Service Health Dashboard (SHD) dependía de S3, AWS no pudo actualizar el estado de cada servicio en el SHD hasta mitad del incidente, y comunicó la situación a través de Twitter y de un aviso en la parte superior del SHD. AWS extrajo varias lecciones de este incidente. En primer lugar, modificó la herramienta que retira capacidad para que la retire lentamente y añadió una salvaguarda que impide retirarla cuando un subsistema quedaría por debajo de la capacidad necesaria. En segundo lugar, modificó la consola de administración del SHD para que funcione en varias regiones de AWS. En tercer lugar, anunció que adelantaría el trabajo de dividir el subsistema de índices en celdas más pequeñas para acortar el tiempo de recuperación. Estas medidas se presentaron en el informe del incidente.
El incidente de Kinesis de 2020 - Un fallo en cadena provocado por la ampliación de los servidores de front-end
El 25 de noviembre de 2020 se produjo un incidente en Kinesis Data Streams en us-east-1, que se extendió a servicios como CloudWatch, Lambda, Cognito y EventBridge. El desencadenante del incidente fue la adición de capacidad a la flota de front-end de Kinesis, y la causa fue que el número de hilos de cada servidor superó el límite configurado en el sistema operativo. Los servidores de front-end de Kinesis estaban diseñados para que cada servidor mantuviera hilos con todos los demás servidores de front-end. El número de hilos que tiene cada servidor aumenta en proporción al número de servidores de la flota. Ese día, tras una adición de capacidad relativamente pequeña, el número de hilos superó el límite configurado en el sistema operativo, y los servidores de front-end no pudieron construir la tabla de correspondencia de shards (shard-map) ni dirigir las solicitudes al back-end. Entre los servicios que usan Kinesis Data Streams, en Cognito aumentaron los fallos de la API, y en CloudWatch aumentaron los errores de las API que reciben métricas y registros. Muchas de las métricas de CloudWatch no se procesaron, las políticas de Auto Scaling que usan métricas de CloudWatch se retrasaron y aumentaron los errores en las invocaciones de Lambda. AWS anunció que trasladaría los servicios grandes, como CloudWatch, a una flota de front-end separada. AWS mencionó como medidas pasar a servidores con más CPU y memoria para reducir el número de servidores, añadir alarmas sobre el consumo de hilos y acelerar la división del front-end en celdas.
El incidente de red de us-east-1 de 2021 - Lo que enseñó la congestión de la red interna
El 7 de diciembre de 2021, el incidente de us-east-1 comenzó a las 7:30 a. m. (PST), y los dispositivos de red se recuperaron a las 2:22 p. m. (PST). Un proceso que aumentaba automáticamente la capacidad de un servicio que se ejecutaba en la red principal de AWS provocó un comportamiento inesperado de muchos clientes de la red interna, y el aumento repentino de conexiones sobrecargó los dispositivos que conectan las dos redes. La particularidad de este incidente fue que la propia consola de AWS se volvió de difícil acceso. En las regiones afectadas, fallaba el inicio de sesión en la Consola de administración de AWS. Las llamadas a la API mediante la CLI o los SDK también sufrieron retrasos y tiempos de espera agotados debido a la congestión de la red interna. Este incidente se relaciona con el principio de diseño de separar el plano de control y el plano de datos. Al plano de datos (la lectura y escritura de los datos reales) se le exige una disponibilidad mayor que al plano de control (la creación, modificación y eliminación de recursos). AWS explica que detuvo el aumento automático de capacidad que había sido el desencadenante, avanzó en la corrección del problema por el que los clientes no podían moderar los reintentos y añadió una configuración que protege los dispositivos de red. Como lecciones para los usuarios se mencionan el diseño multirregión y los procedimientos operativos que no dependen de la consola de AWS (preparar de antemano scripts de la CLI).
Principios de diseño de AWS derivados de los incidentes
Como principios de diseño que AWS explica en relación con su experiencia con incidentes, se mencionan los tres siguientes. El primero es la «minimización del Blast Radius». Para limitar el alcance del impacto de un incidente, el servicio se divide en unidades independientes llamadas celdas (Cell), con un diseño en el que el fallo de una celda no se extiende a las demás. DynamoDB se menciona a veces como ejemplo de la idea de las celdas. El segundo es la «Static Stability» (estabilidad estática). Es un diseño que permite mantener el funcionamiento existente aunque un servicio del que se depende sufra un fallo. Por ejemplo, cuando Auto Scaling sufre un fallo, se hace que las instancias ya lanzadas puedan seguir funcionando. El tercero es el «Shuffle Sharding». Al asignar a los clientes a shards de forma aleatoria, se reduce la probabilidad de que el tráfico anómalo de un cliente afecte a otros clientes. AWS explica estos principios en relación con su experiencia con incidentes, y sirven de referencia cuando los usuarios diseñan sus propios sistemas.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.