Alta disponibilidad y tolerancia a fallas

Todo falla tarde o temprano: un disco, un servidor, un centro de datos completo. La pregunta no es si va a fallar, sino qué ven tus usuarios cuando falla. Diseñar para la disponibilidad es buscar cada pieza única de tu arquitectura y darle un reemplazo listo.

Tres palabras que se confunden

La tolerancia a fallas es un caso más exigente de alta disponibilidad. No todo la necesita: una página de marketing puede aguantar un minuto de caída; el sistema de pagos, quizá no. Decide por lo que cuesta la caída, no por gusto. Esto es parte del pilar de fiabilidad de Well-Architected.

Quitar puntos únicos de falla, capa por capa

Un punto único de falla es una pieza que, si se cae, se lleva todo el sistema. Recorre tu diagrama de arriba abajo:

1. 1

   DNS: el directorio de la ciudad

   Route 53 es un servicio global con chequeos de salud. Con enrutamiento de conmutación por error (failover) manda el tráfico a otro destino si el principal no responde.
2. 2

   Entrada: la recepción

   Un Application Load Balancer se despliega en subredes de al menos dos AZs y deja de enviar tráfico a los destinos que fallan su chequeo de salud.
3. 3

   Cómputo: los apartamentos

   Un grupo de Auto Scaling repartido en varias AZs reemplaza solo las instancias que fallan. Si una AZ cae, lanza capacidad en las otras.
4. 4

   Base de datos

   RDS Multi-AZ mantiene una réplica en espera en otra AZ y cambia a ella de forma automática. Aurora guarda seis copias de los datos en tres AZs. DynamoDB replica en varias AZs sin que hagas nada.
5. 5

   Almacenamiento: el banco

   S3 Standard guarda los objetos en al menos tres AZs. Nada que configurar.
6. 6

   Red

   Un NAT Gateway por AZ. Si compartes uno solo, la caída de su AZ deja sin salida a las demás.

Calcular la disponibilidad por sus partes

La disponibilidad de un sistema se calcula a partir de la de sus componentes. Hay dos reglas, y la diferencia entre ellas explica por qué la redundancia funciona.

• En serie (la petición pasa por A y por B): se multiplican. Disponibilidad = A × B. Cada pieza agregada en serie baja el total.
• En paralelo (basta con que funcione A o B): se multiplica la probabilidad de que fallen ambos. Disponibilidad = 1 − (1 − A) × (1 − B). Cada copia en paralelo sube el total.

Un ejemplo con números inventados para practicar (no son los SLA de AWS): un balanceador de 99,99 %, un servidor de 99 % y una base de datos de 99,9 %, en serie.

1. 1

   Con un solo servidor

   0,9999 × 0,99 × 0,999 = 0,9889 → 98,89 %. Unos 4 días de caída al año. El servidor es el eslabón débil.
2. 2

   Con dos servidores en paralelo

   Capa de aplicación: 1 − (0,01 × 0,01) = 0,9999. Total: 0,9999 × 0,9999 × 0,999 = 0,9988 → 99,88 %. Unas 10,5 horas al año.
3. 3

   Con la base de datos duplicada

   Capa de datos: 1 − (0,001 × 0,001) = 0,999999. Total: 0,9999 × 0,9999 × 0,999999 = 0,9998 → 99,98 %. Menos de 2 horas al año.

La fórmula supone que las fallas son independientes y que el cambio a la copia es instantáneo. En la vida real no lo es del todo, por eso las copias van en AZs distintas: dos servidores en la misma AZ comparten energía y red, y pueden caer juntos.

La tabla de los nueves

Probar que aguanta: ingeniería del caos

Un diseño redundante que nunca se probó es una hipótesis. AWS Fault Injection Service (FIS) ejecuta experimentos controlados: detener instancias, agregar latencia a la red, simular la pérdida de una AZ. Defines condiciones de parada con alarmas de CloudWatch para cortar el experimento si el daño pasa de lo esperado.

• 

  AWS Fault Injection Service

  El simulacro de evacuación

  Inyecta fallas reales de forma controlada para comprobar que el sistema se recupera como esperas.
• 

  AWS Resilience Hub

  El inspector de riesgos

  Evalúa una aplicación contra tus objetivos de recuperación y recomienda mejoras.