Alta disponibilidad y tolerancia a fallos

La falla de hardware de las 2 a.m.

Una tienda en línea corre su API de pagos en una sola instancia EC2. A las 2 a.m., el servidor físico debajo de esa instancia falla, en silencio y por completo, como eventualmente falla el hardware sin importar de quién sea el logo en el rack. La instancia desaparece, y con ella el checkout, hasta que alguien nota el problema y lanza un reemplazo. Esa instancia solitaria era un punto único de falla: 1 recurso cuya caída, por sí sola, se llevó todo el sistema con ella. Eliminar puntos únicos de falla como ese es de lo que trata el resto de esta lección, y resulta que hay 2 niveles distintos de "eliminado", no 1.

Lo que ya tienes: zonas de disponibilidad y un balanceador de carga

Ya tienes las 2 piezas que hacen posible esa eliminación. Las zonas de disponibilidad te dan ubicaciones físicamente separadas para repartir instancias, así que una mala noche en 1 centro de datos no se lleva todo de un golpe. Un balanceador de carga se para frente a esas instancias, revisa la salud de cada una y enruta el tráfico solo hacia las que siguen respondiendo. Junta las 2 cosas, instancias repartidas entre varias zonas detrás de un balanceador de carga, y una repetición de la falla de las 2 a.m. deja de ser catastrófica. Lo que se vuelve después, un tropiezo breve o directamente nada, depende de cuánta capacidad de repuesto ya estaba corriendo en el momento exacto de la falla.

Alta disponibilidad: seguir en pie durante una interrupción breve

Los despliegues Multi-AZ de Amazon RDS muestran este patrón con claridad. Una instancia principal de base de datos atiende cada lectura y escritura, mientras una instancia en espera en otra zona de disponibilidad se mantiene sincronizada de fondo, lista pero inactiva. Si la principal falla, RDS lo detecta, promueve la instancia en espera y redirige el registro DNS de la base de datos hacia ella, típicamente en 60 a 120 segundos, sin perder ni un dato. Durante esos 60 a 120 segundos, sin embargo, las conexiones a la base de datos sí se caen o quedan en espera.

Eso es alta disponibilidad: el sistema se recupera solo y rápido, pero la recuperación misma es una brecha visible, aunque breve. A la mayoría de las aplicaciones les alcanza con esto. Un minuto de errores de conexión durante una falla poco frecuente de zona es un problema muy distinto a la caída total que sufrió la tienda de la instancia única.

Tolerancia a fallos: seguir en pie sin ninguna interrupción

Vuelve ahora a la API de pagos, pero rediseñada. Digamos que necesita 6 instancias corriendo para atender su carga normal. Repartidas en 2 zonas de disponibilidad, 3 instancias en cada una, eso ya es altamente disponible: pierdes 1 zona, y las 3 instancias sobrevivientes mantienen el checkout funcionando, aunque a la mitad de capacidad hasta que se lancen nuevas instancias detrás de ellas. Repártelas en 3 zonas de disponibilidad en cambio, con 3 instancias en cada una, 9 instancias en total, y perder cualquier 1 zona deja igual 6 instancias vivas, exactamente la capacidad que necesita el checkout. Nada cambia para el usuario. Eso es tolerancia a fallos: el sistema nunca estuvo realmente corto de capacidad, porque las instancias "de repuesto" ya estaban corriendo y ya servían tráfico antes de que ocurriera la falla.

La comparación es toda la distinción en 1 sola imagen: un diseño altamente disponible tiene suficiente redundancia para sobrevivir una falla, y un diseño tolerante a fallos tiene tanta redundancia que sobrevivirla no produce ninguna caída que sobrevivir. La tolerancia a fallos se parece más a una llanta autosellante que mantiene el auto rodando a toda velocidad tras un pinchazo, que a una llanta de repuesto que hace arrancar de nuevo al auto después de parar a cambiarla, que es justo la cara que tiene la ventana de recuperación de la alta disponibilidad. Lleva la comparación más allá de ese único punto y se rompe: una llanta de repuesto es barata de cargar sin usarla, mientras que la capacidad tolerante a fallos te cobra cada hora que queda inactiva, esperando una falla que puede que nunca llegue.

Dónde tiene que llegar la redundancia: en cada capa, no solo en cómputo

Un sistema es tan disponible como su capa menos redundante. Repartir la capa de cómputo entre zonas no sirve de nada si la base de datos, el balanceador de carga o el DNS siguen siendo un punto único de falla debajo de ella.

Los proveedores de nube construyen sus balanceadores de carga administrados y sus health checks de DNS para que ya sean redundantes por defecto, así que las capas que un equipo suele tener que diseñar explícitamente son cómputo y base de datos.

Activo-activo frente a activo-pasivo

Los 2 patrones de redundancia de arriba tienen nombre, y la diferencia entre ellos vuelve a aparecer más adelante en este tema. Activo-activo significa que cada réplica sirve tráfico al mismo tiempo, como reparte un balanceador de carga las solicitudes entre todas las instancias de cómputo saludables ahora mismo, no solo cuando algo falla. Activo-pasivo significa que 1 lado hace el trabajo mientras el otro se mantiene sincronizado e inactivo, listo para tomar el control, como se comporta una instancia en espera de RDS Multi-AZ.

Ningún patrón es mejor por definición. Las capas de cómputo suelen ser activo-activo porque repartir solicitudes sin estado entre muchas instancias idénticas es directo. Las bases de datos suelen ser activo-pasivo más seguido porque mantener cada réplica escribible al mismo tiempo levanta preguntas difíciles de consistencia que un solo escritor activo evita.

Error de concepto: "multi-AZ" no es sinónimo automático de "tolerante a fallos"

Es tentador escuchar "desplegado en varias zonas de disponibilidad" y asumir que eso resuelve la pregunta de confiabilidad. Solo resuelve la mitad. Multi-AZ te dice que una falla en 1 zona no se va a llevar todas las instancias. No dice nada sobre si la capacidad sobreviviente alcanza para seguir atendiendo toda tu carga sin ninguna caída. Un equipo que reparte 6 instancias en 2 zonas mejoró de verdad su disponibilidad frente a un despliegue de 1 sola zona, pero no se volvió tolerante a fallos, y asumir lo contrario es exactamente la brecha que aparece como un faltante de capacidad no planeado durante el próximo evento a nivel zona.

Pistas de examen: cómo leer una pregunta de alta disponibilidad frente a tolerancia a fallos

La trampa a vigilar: un escenario que describe una configuración multi-AZ sólida y pregunta si es tolerante a fallos. Revisa la matemática de capacidad, no solo la cantidad de zonas, antes de responder.

Dónde te deja esto

Los 2 patrones parten del mismo movimiento, eliminar un punto único de falla, y después se separan según cuánta capacidad de repuesto estés dispuesto a correr y pagar todo el tiempo. La alta disponibilidad tolera una ventana de recuperación corta y automática; la tolerancia a fallos elimina esa ventana manteniendo la capacidad redundante ya activa. A la mayoría de las aplicaciones les alcanza con la primera. La próxima lección pasa de seguir en pie durante una falla a una pregunta relacionada pero distinta: una vez que decidiste cuánta capacidad necesita un sistema, ¿quién decide cuándo agregar más, y cuándo quitarla de nuevo?