Patrones Multi-AZ para servicios con estado

Los servicios con estado —bases de datos, cachés y sistemas de archivos— son los componentes más difíciles de hacer altamente disponibles porque contienen datos que deben sobrevivir a los fallos. Si falla una base de datos en una sola AZ, toda la aplicación pierde su almacén de datos. La respuesta de AWS son las implementaciones Multi-AZ, en las que el servicio mantiene una réplica síncrona o casi síncrona en una segunda zona de disponibilidad que puede asumir el control rápidamente cuando falla la principal.

RDS Multi-AZ mantiene una réplica en espera síncrona en una AZ diferente. Cada escritura en la instancia principal se replica de forma síncrona antes de confirmar el éxito; esto significa que no se pierden datos (RPO=0), aunque aumenta ligeramente la latencia de escritura. Cuando falla la instancia principal, RDS actualiza automáticamente el punto de conexión DNS para que apunte a la instancia en espera en un plazo de 60-120 segundos. La aplicación solo necesita volver a conectarse al mismo punto de conexión; no se requieren cambios en el código.

Amazon Aurora lleva Multi-AZ un paso más allá con una capa de almacenamiento distribuido compartido que replica automáticamente los datos en tres AZ, con seis copias. Las instancias de Aurora no tienen estado: leen y escriben en este almacenamiento compartido. Cuando falla la instancia principal de escritura de Aurora, una réplica de lectura de otra AZ se promueve a instancia de escritura en menos de 30 segundos. Esto es más rápido que la conmutación por error Multi-AZ de RDS, y los datos siempre son coherentes entre las AZ sin necesidad de replicación explícita en una instancia en espera.

ElastiCache for Redis admite Multi-AZ mediante grupos de replicación. Un nodo principal acepta las escrituras y las replica de forma asíncrona en réplicas de lectura ubicadas en otras AZ. Cuando falla el nodo principal, ElastiCache promueve automáticamente una réplica a nodo principal. Con el modo de clúster habilitado para Redis, los datos se distribuyen en fragmentos entre varios grupos de nodos, cada uno con su propio nodo principal y réplicas distribuidos entre las AZ; esto proporciona tanto alta disponibilidad como escalado horizontal.

Amazon Elastic File System (EFS) es inherentemente Multi-AZ: es un servicio regional que almacena los datos de forma redundante en varias AZ dentro de una región. Debe crear destinos de montaje en la subred de cada AZ, y las instancias de EC2 de cualquier AZ pueden montar el sistema de archivos a través de su destino de montaje local. No es necesario configurar Multi-AZ manualmente. EFS proporciona almacenamiento de archivos POSIX compartido al que varias instancias de distintas AZ pueden acceder simultáneamente.

Los Elastic Load Balancers también son Multi-AZ: ALB y NLB implementan nodos del balanceador de carga en cada AZ que especifique. Con el equilibrio de carga entre zonas habilitado (opción predeterminada para ALB), cada nodo del balanceador de carga distribuye el tráfico de forma uniforme entre todos los destinos registrados en todas las AZ, no solo en su propia AZ. Esto garantiza que, aunque fallen todas las instancias de una AZ, el balanceador de carga continúe atendiendo el tráfico mediante las instancias de las AZ restantes.

Un error común consiste en implementar un único NAT Gateway en una AZ mientras las subredes privadas de otras AZ enrutan el tráfico a través de él. Si esa AZ falla, todas las instancias privadas pierden el acceso a Internet. El patrón Multi-AZ correcto consiste en implementar un NAT Gateway por AZ y configurar la tabla de enrutamiento privada de cada AZ para que enrute 0.0.0.0/0 a través de su propio NAT Gateway. Esto elimina el NAT Gateway como SPOF entre AZ y reduce los costes de transferencia de datos entre AZ.

DynamoDB es un servicio totalmente administrado que replica automáticamente los datos en tres AZ dentro de una región; no es necesario configurar Multi-AZ manualmente. Cada escritura se almacena de forma duradera en las tres AZ antes de devolver una respuesta de éxito. DynamoDB es, en la práctica, tolerante a fallos a nivel de AZ desde el primer momento. Por eso, DynamoDB suele ser la opción de base de datos recomendada cuando la pregunta del examen enfatiza la alta disponibilidad con una sobrecarga operativa mínima.

Durante una conmutación por error Multi-AZ de RDS, las aplicaciones que mantienen conexiones persistentes con la base de datos pueden experimentar fallos cuando cambia el endpoint. RDS Proxy se sitúa entre la aplicación y RDS y mantiene un grupo de conexiones con la base de datos. Durante la conmutación por error, RDS Proxy redirige automáticamente las conexiones a la nueva instancia principal, lo que reduce el impacto de la conmutación de 60-120 segundos a menos de 30 segundos en las aplicaciones que utilizan el endpoint del proxy. RDS Proxy también resulta útil para las funciones de Lambda que crean muchas conexiones de corta duración.

Comprender los modos de replicación es fundamental para elegir patrones Multi-AZ. La replicación síncrona (RDS Multi-AZ, EFS) garantiza RPO=0 porque cada escritura se confirma en ambas AZ antes de indicar que se ha realizado correctamente. La contrapartida es una latencia de escritura ligeramente mayor. La replicación asíncrona (réplicas de ElastiCache Redis, réplicas de lectura de RDS) ofrece una latencia de escritura menor, pero admite un pequeño retraso de replicación; esto significa que algunos datos podrían perderse si la instancia principal falla antes de que finalice la replicación.

Debe probar periódicamente la conmutación por error Multi-AZ para validar sus supuestos sobre el RTO. En RDS, puede activar una conmutación por error mediante la opción Reboot with failover de la consola o mediante la CLI. Supervise CloudWatch para consultar la métrica FailedSQLServerAgentJobsCount y revise los registros de la aplicación para verificar que se vuelve a conectar correctamente. Documente la duración real de la conmutación por error; puede diferir de la documentación de AWS según la clase de instancia y la carga de trabajo.

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

En esta lección ha aprendido que RDS Multi-AZ utiliza replicación síncrona con conmutación por error automática mediante DNS, que Aurora utiliza una capa de almacenamiento compartido en tres AZ para lograr una conmutación por error más rápida y que EFS y DynamoDB son inherentemente Multi-AZ sin configuración manual. Implemente un NAT Gateway por AZ para evitar SPOF entre AZ. A continuación, exploraremos los patrones activo-activo y activo-pasivo entre varias regiones.