Principios de sistemas distribuidos aprendidos de las interrupciones de AWS - Arquitecturas transformadas por grandes incidentes
Usando como material los informes de incidentes publicados por AWS, como la interrupción de S3 (2017), la interrupción de Kinesis (2020) y la particularidad de us-east-1, explicamos principios de diseño como Shuffle Sharding, Static Stability y Cell-based Architecture.
Los informes de incidentes como libro de texto
AWS publica informes detallados de incidentes llamados Post-Event Summary cuando ocurren interrupciones a gran escala. Estos informes no son simples disculpas, sino documentos valiosos que describen técnicamente la causa raíz del fallo, la cadena de impactos, el proceso de recuperación y las medidas preventivas. Los principios de diseño de sistemas distribuidos tienden a discutirse de forma abstracta, pero al vincularlos con casos reales de incidentes, se comprende concretamente por qué esos principios son importantes. Aquí examinaremos casos representativos de incidentes publicados por AWS y explicaremos los principios de diseño derivados de ellos.
Interrupción de S3 (febrero 2017) - Fallos en cascada y dificultad de recuperación
El 28 de febrero de 2017, S3 estuvo inactivo durante aproximadamente 4 horas en la región us-east-1. Según el informe oficial de AWS, durante el proceso de depuración de un problema del sistema de facturación, se eliminaron más servidores de los previstos de los subsistemas de índice y ubicación de S3. El problema comenzó aquí. Estos subsistemas son esenciales para las operaciones de lectura y escritura de S3, y los servidores restantes no tenían capacidad de procesamiento suficiente. Lo más grave fue que estos subsistemas no habían experimentado un reinicio completo durante muchos años. El reinicio de los subsistemas requería verificaciones de integridad de los metadatos existentes, y debido al crecimiento del volumen de datos, el tiempo de reinicio fue mayor de lo esperado. Este incidente dejó dos lecciones. Primera, el peligro de la cadena de dependencias (fallos en cascada). Numerosos servicios y sitios web que dependían de S3 se detuvieron en cascada. El propio panel de estado de incidentes de AWS dependía de S3, por lo que ni siquiera podía notificar el estado del incidente, una situación irónica. Segunda, el costo de reinicio de sistemas a gran escala. Los sistemas que se asumen como nunca detenidos conllevan el riesgo de tiempos de reinicio inesperadamente largos.
Interrupción de Kinesis (noviembre 2020) - Un fallo causado por la ampliación de capacidad
El 25 de noviembre de 2020, Kinesis sufrió un incidente de aproximadamente 21 horas en us-east-1. La causa revelada por el informe oficial de AWS fue la propia ampliación de capacidad. Los servidores frontend de Kinesis tenían una estructura de malla que utilizaba un hilo del sistema operativo por servidor para la comunicación mutua. Al agregar servidores al backend, el número de hilos mantenidos por cada servidor frontend superó el límite configurado del sistema operativo. La ironía de este incidente es que una adición de capacidad para mejorar el servicio fue el detonante del fallo. Además, el incidente de Kinesis se propagó a numerosos servicios dependientes de Kinesis como CloudWatch, Cognito y Lambda. Tras este incidente, AWS migró los servidores frontend a servidores con mayor CPU y memoria, reduciendo el número de servidores para resolver fundamentalmente el problema de hilos. También revisó la estructura de caché del frontend para reducir el impacto de los cambios del backend en el frontend.
La particularidad de us-east-1 - Por qué esta región tiene más incidentes
Al seguir los informes de incidentes de AWS, se nota que us-east-1 (Norte de Virginia) aparece repetidamente. Esto no es coincidencia. us-east-1 es la región más antigua de AWS, y los planos de control de servicios globales como IAM, Route 53 y CloudFront están concentrados allí. Los servicios globales son aquellos que no están vinculados a una región específica y tienen endpoints comunes en todo el mundo. Dado que los planos de control (componentes de gestión que procesan cambios de configuración y autenticación) de estos servicios están en us-east-1, los incidentes en esta región pueden propagarse a otras regiones. En el incidente de diciembre de 2021, un problema en los equipos de red internos de us-east-1 afectó los planos de control de múltiples servicios dentro de la región. Aunque los planos de datos (componentes que realizan el procesamiento real de datos) funcionaban normalmente, no se podían crear nuevos recursos ni realizar cambios de configuración. Este caso demuestra la importancia de separar el plano de control del plano de datos, diseñando para que el plano de datos continúe operando independientemente durante un fallo del plano de control.
Principios de diseño nacidos de los incidentes
AWS ha sistematizado principios de diseño a partir de estas experiencias de incidentes a través de la Builders' Library y whitepapers. Shuffle Sharding es una técnica que asigna clientes a combinaciones de servidores (shards) seleccionados aleatoriamente. En el sharding fijo tradicional, un fallo en un shard afecta a todos los clientes de ese shard, pero con Shuffle Sharding, como la combinación de shards es diferente para cada cliente, la proporción de clientes afectados por un fallo se reduce probabilísticamente de forma significativa. Esta técnica se utiliza en la asignación de servidores de nombres de Route 53. Static Stability es un diseño que permite continuar operando manteniendo el estado actual incluso cuando un servicio dependiente falla. Por ejemplo, si un grupo de Auto Scaling tiene suficientes instancias pre-desplegadas en cada Availability Zone, puede continuar procesando con las instancias existentes durante un fallo de AZ, incluso si no puede tomar decisiones de escalado (operaciones del plano de control). Cell-based Architecture es un diseño que divide el sistema en múltiples celdas (réplicas) independientes, cada una operando de forma autónoma. Si una celda falla, las demás no se ven afectadas. Es un patrón de diseño promovido por AWS después del incidente de S3, que limita físicamente el radio de explosión de los fallos.
Aplicación a sus propios sistemas
Estos principios son aplicables no solo a sistemas de la escala de AWS, sino también al diseño de aplicaciones en general. Primero, comprender explícitamente las dependencias. Identificar de antemano de qué servicios depende su sistema y qué sucede cuando esos servicios se detienen. Segundo, ser consciente de la separación entre plano de control y plano de datos. Diseñar para que el procesamiento de datos existente pueda continuar incluso cuando los cambios de configuración u operaciones de gestión no sean posibles. Implementar el patrón Circuit Breaker para cambiar inmediatamente al procesamiento de respaldo cuando se detecta un fallo en una dependencia también es efectivo. La configuración Multi-AZ debe adoptarse como tolerancia a fallos mínima, y la configuración Multi-Región debe considerarse según los requisitos del negocio. Sin embargo, Multi-Región implica compromisos en consistencia de datos y latencia, por lo que no debe aplicarse a todas las cargas de trabajo. Diseñar bajo la premisa de que los fallos ocurrirán inevitablemente y minimizar el alcance del impacto durante un fallo es la esencia del diseño de sistemas distribuidos. Para aprender sistemáticamente los principios de diseño de sistemas distribuidos, los libros especializados (Amazon) son útiles.
Resumen
Las grandes interrupciones de AWS son el mejor material didáctico para aprender principios de diseño de sistemas distribuidos. La interrupción de S3 nos enseñó el peligro de los fallos en cascada y los costos de reinicio, la interrupción de Kinesis nos mostró los efectos secundarios inesperados de los cambios de capacidad, y las interrupciones recurrentes de us-east-1 nos revelaron el riesgo de concentración de servicios globales. Los principios de diseño nacidos de estas experiencias, como Shuffle Sharding, Static Stability y Cell-based Architecture, son conocimientos universales aplicables al diseño de cualquier sistema distribuido, no solo dentro de AWS.