Alta disponibilidad frente a tolerancia a fallos: definiciones y compensaciones

La alta disponibilidad (HA) y la tolerancia a fallos (FT) son dos objetivos de fiabilidad distintos que los arquitectos suelen confundir. La alta disponibilidad significa que un sistema experimenta un tiempo de inactividad mínimo: puede tolerar fallos, pero es posible que se produzcan breves interrupciones durante la recuperación. La tolerancia a fallos significa que un sistema continúa funcionando sin ninguna interrupción incluso cuando fallan componentes, gracias a rutas completamente redundantes que toman el control de inmediato.

La disponibilidad se mide como el porcentaje de tiempo de actividad a lo largo de un año. Una disponibilidad del 99,9 % (tres nueves) equivale aproximadamente a 8,7 horas de inactividad al año, mientras que el 99,99 % (cuatro nueves) permite solo 52,6 minutos. El 99,999 % (cinco nueves) permite apenas 5,26 minutos. Cada nueve adicional suele requerir más redundancia, automatización y costes. El examen SAA-C03 suele pedirle que identifique qué arquitectura cumple un objetivo de disponibilidad determinado.

Una arquitectura de alta disponibilidad tolera el fallo de un componente detectándolo automáticamente y cambiando a un reemplazo en buen estado en cuestión de segundos o minutos. Algunos ejemplos son RDS Multi-AZ (conmutación por error automática a una instancia en espera en una AZ diferente), los grupos de Auto Scaling que reemplazan las instancias terminadas y los Elastic Load Balancers que redirigen el tráfico para evitar los destinos en mal estado. Se produce una breve interrupción, pero el sistema se recupera sin intervención manual.

Una arquitectura tolerante a fallos cuenta con redundancia activa: varios componentes idénticos atienden solicitudes simultáneamente, de modo que, cuando uno falla, los demás absorben la carga de inmediato y sin tiempo de inactividad. Algunos ejemplos son un ELB activo-activo con varias instancias de EC2, las DynamoDB Global Tables, que atienden lecturas y escrituras simultáneamente en varias regiones, y Aurora con varias réplicas de lectura. La tolerancia a fallos requiere mantener más recursos en ejecución en todo momento.

La tolerancia a fallos es significativamente más cara que la alta disponibilidad porque requiere capacidad redundante completamente aprovisionada en todo momento. Una instancia RDS Multi-AZ de alta disponibilidad duplica el coste de la base de datos para mantener una instancia en espera que solo se activa cuando se produce un fallo. Una implementación Aurora activa-activa tolerante a fallos en varias regiones puede costar cuatro veces más, pero elimina todo el tiempo de inactividad durante los fallos regionales. Los arquitectos deben equilibrar el coste de la redundancia con el coste empresarial del tiempo de inactividad.

El Recovery Time Objective (RTO) es el tiempo máximo aceptable durante el que un sistema puede no estar disponible. Las arquitecturas de alta disponibilidad tienen como objetivo un RTO bajo, normalmente de minutos, mediante la conmutación por error automatizada. Las arquitecturas tolerantes a fallos tienen como objetivo un RTO cercano a cero. Al diseñar para HA, debe elegir servicios y configuraciones que garanticen la recuperación dentro del RTO disponible. Por ejemplo, RDS Multi-AZ proporciona un RTO aproximado de 60-120 segundos, adecuado para muchos requisitos de HA.

Un punto único de fallo (SPOF) es cualquier componente cuyo fallo provoca que todo el sistema deje de funcionar. Entre los SPOF habituales se incluyen una única instancia de EC2 sin ASG, una base de datos RDS en una sola AZ, una única puerta de enlace NAT o una única zona de disponibilidad. Eliminar los SPOF es el primer paso hacia la HA y la FT. El examen SAA-C03 evalúa con frecuencia su capacidad para identificar y eliminar SPOF en diagramas de arquitectura determinados.

Lograr HA o FT es mucho más sencillo para los servicios sin estado (como los servidores web o las funciones de Lambda), porque cualquier instancia puede gestionar cualquier solicitud. Los servicios con estado (bases de datos, cachés y sistemas de archivos) son más difíciles: debe sincronizar el estado entre las réplicas, gestionar el retraso de replicación y garantizar la coherencia durante la conmutación por error. Los servicios de AWS como EFS (sistema de archivos compartido), ElastiCache con grupos de replicación y Aurora (almacenamiento compartido) están diseñados para facilitar la HA con estado.

Entre los patrones habituales de HA en AWS se incluyen: 1) Equilibrio de carga Multi-AZ: distribuir las instancias de EC2 entre AZ detrás de un ALB. 2) Réplicas de lectura: descargar el tráfico de lectura y promover una réplica durante la recuperación ante desastres. 3) S3 para recursos sin estado: S3 ofrece de forma inherente una alta disponibilidad con 11 nueves de durabilidad. 4) Global Accelerator: direcciones IP Anycast estáticas que enrutan el tráfico a puntos de conexión en buen estado entre regiones. Cada patrón intercambia costes por un nivel específico de disponibilidad.

Los patrones tolerantes a fallos requieren redundancia activa en todas partes. Algunos patrones clave de FT son los siguientes: DynamoDB es tolerante a fallos de forma inherente: replica los datos entre tres AZ sin necesidad de conmutación por error. S3 incorpora tolerancia a fallos. Aurora Multi-Master (actualmente Aurora Serverless v2 multi-writer) permite escribir simultáneamente en varias AZ. Kinesis almacena los datos en varias AZ de forma predeterminada. Elegir servicios administrados con FT integrada es la forma más rentable de lograr arquitecturas sin tiempo de inactividad.

El diseño para HA o FT solo es tan bueno como las pruebas que se realicen. AWS recomienda utilizar AWS Fault Injection Simulator (FIS) para ejecutar experimentos controlados que terminen instancias, limiten las API o inyecten fallos de red. Debe verificar que la conmutación por error se complete dentro de su RTO, que no se pierdan más datos de los permitidos por su RPO y que las alarmas se activen correctamente. Los días de pruebas periódicos y los ejercicios de ingeniería del caos revelan deficiencias en sus supuestos de resiliencia antes de que lo hagan los incidentes en producción.

Compruebe sus conocimientos sobre los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido lo siguiente: la alta disponibilidad minimiza el tiempo de inactividad mediante la recuperación automatizada (RTO de minutos); la tolerancia a fallos elimina el tiempo de inactividad mediante la redundancia activa (RTO cero); y el coste aumenta significativamente con cada nivel de resiliencia. Eliminar los puntos únicos de fallo es la base de ambos enfoques. A continuación exploraremos los patrones Multi-AZ para servicios con estado.