3,5 nueves (99,95 %) con un tiempo de recuperación entre 5 y 30 minutos

Este objetivo de disponibilidad para aplicaciones requiere un tiempo de inactividad extremadamente corto y muy poca pérdida de datos durante tiempos específicos. Las aplicaciones con este objetivo de disponibilidad incluyen aplicaciones en las áreas de banca, inversión, servicios de emergencia y captura de datos. Estas aplicaciones tienen tiempos de recuperación y puntos de recuperación muy cortos.

Podemos mejorar aún más el tiempo de recuperación mediante el uso de un enfoque de Espera en caliente en dos regiones de AWS. Implementaremos toda la carga de trabajo en ambas regiones, con una reducción vertical de nuestro sitio pasivo y el mantenimiento de todos los datos de forma uniforme en algún momento. Ambas implementaciones se mantendrán estáticamente estables en sus respectivas regiones. Las aplicaciones deben crearse con los patrones de resiliencia del sistema distribuido. Tendremos que crear un componente de enrutamiento ligero que supervise el estado de la carga de trabajo y que pueda configurarse para dirigir el tráfico a la región pasiva si es necesario.

Supervisión de recursos de

Habrá alertas de cada reemplazo de un servidor web, cuando la base de datos falle y cuando la región falle. También supervisaremos el contenido estático en Amazon S3 para verificar la disponibilidad y alertar si no está disponible. El registro se agregará para facilitar la administración y ayudar en el análisis de causa raíz en cada región.

El componente de enrutamiento supervisar tanto el estado de nuestras aplicaciones como cualquier dependencia física regional que tengamos.

Adaptación a los cambios en la demanda

Igual que en el escenario de los 4 nueves.

Implementación de cambios

La entrega del nuevo software se lleva a cabo en un horario fijo de cada dos o cuatro semanas. Las actualizaciones de software se automatizarán con patrones de implementación azul/verde o canario.

Los manuales de procedimientos existen para cuando se produce la conmutación por error de región, para problemas comunes de los clientes que ocurren durante esos eventos y para informes comunes.

Tendremos manuales de estrategias para problemas comunes de la base de datos, incidencias relacionadas con la seguridad, implementaciones incorrectas, problemas inesperados de los clientes en la conmutación por error de la región y para establecer la causa raíz de los problemas. Una vez identificada la causa raíz, la corrección del error se identificará mediante una combinación de los equipos de operaciones y desarrollo y se implementará cuando se desarrolle la solución.

También nos comprometeremos con AWS Support para la gestión de eventos de infraestructura.

Copia de seguridad de los datos

Al igual que en la situación de los 4 9, utilizamos copias de seguridad automáticas en RDS y utilizamos el control de versiones en S3. Los datos se replican de forma automática y asíncrona desde el clúster de Aurora RDS de la región activa a las réplicas de lectura entre regiones de la región pasiva. La replicación entre regiones de S3 se utiliza para mover los datos de forma automática y asíncrona de la región activa a la pasiva.

Arquitectura de la resiliencia

Igual que en el escenario de los 4 nueves, además de que es posible la conmutación por error regional. Esto se gestiona manualmente. Durante la conmutación por error, dirigiremos las solicitudes a un sitio web estático mediante la conmutación por error de DNS hasta la recuperación en la segunda región.

Prueba de resiliencia

Igual que en la situación de los 4 9 y, además, validaremos la arquitectura a través de los “días de juego” con manuales de procedimientos. La corrección RCA también se prioriza por encima de los lanzamientos de características para su implementación inmediata.

Planificación de la recuperación de desastres (DR)

La conmutación por error regional se gestiona manualmente. Todos los datos se replican de forma asíncrona. La infraestructura en espera en caliente se escala horizontalmente. Esto se puede automatizar mediante un flujo de trabajo invocado en AWS Step Functions. AWS Systems Manager (SSM) también puede ayudar con esta automatización, ya que puede crear documentos de SSM que actualicen los grupos de escalado automático y redimensionen las instancias.

Objetivo de diseño de disponibilidad

Asumimos que al menos algunos errores requerirán una decisión manual para ejecutar la recuperación, sin embargo, con una buena automatización en esta situación, asumimos que solo dos eventos al año requerirán esta decisión. Tomamos 20 minutos para decidir ejecutar la recuperación y asumimos que la recuperación se completa en 10 minutos. Esto implica que se tarda 30 minutos en recuperarse de un error. Suponiendo que haya dos errores al año, nuestro tiempo de impacto estimado al año es de 60 minutos.

Esto significa que el límite superior de disponibilidad es del 99,95 %. La disponibilidad real también dependerá de la tasa real de error, la duración del error y la rapidez con que cada factor se recupere. Para esta arquitectura, suponemos que la aplicación está en línea continuamente a través de actualizaciones. Por lo tanto, nuestro objetivo de diseño de disponibilidad es 99,95 %.

Resumen

Tema	Implementación
Supervisión de recursos de	Comprobaciones de estado en todas las capas, incluido el estado de DNS en el nivel de región de AWS y KPI; alertas enviadas cuando se disparan las alarmas configuradas; que alertarán de todos los errores. Las reuniones operativas son rigurosas para detectar tendencias y lograr diseñar objetivos.
Adaptación a los cambios en la demanda	ELB para el nivel de aplicación web y de escalado automático; escalado automático de réplicas de almacenamiento y lectura en varias zonas de las regiones activas y pasivas para Aurora RDS. Los datos y la infraestructura se sincronizaron entre regiones de AWS para lograr una estabilidad estática.
Implementación de cambios	Implementación automatizada a través de canario o azul/verde y restauración automática cuando los KPI o alertas indican problemas no detectados en la aplicación, las implementaciones se efectúan en una zona de aislamiento en una región de AWS a la vez.
Copia de seguridad de los datos	Copias de seguridad automatizadas en cada región de AWS a través de RDS para cumplir con RPO y restauración automatizada que se practica regularmente en un día de juegos. Los datos de Aurora RDS y S3 se replican automática y asincrónicamente de la región activa a la pasiva.
Arquitectura de la resiliencia	Escalado automático para proporcionar un nivel de aplicación y web de recuperación automática; RDS es Multi-AZ; la conmutación por error regional se administra manualmente con el sitio estático presentado durante la conmutación por error.
Prueba de resiliencia	Las pruebas de errores de componentes y zonas de aislamiento están en proceso y se practican regularmente con el personal operativo en un “día de juego”; existen manuales de estrategias para diagnosticar problemas desconocidos y existe un proceso de análisis de causa raíz, con rutas de comunicación sobre cuál era el problema y cómo se corrigió o evitó. La corrección RCA se prioriza por encima de los lanzamientos de características para su implementación inmediata.
Planificación de la recuperación de desastres (DR)	La espera en caliente se implementó en otra región. La infraestructura se escala horizontalmente mediante flujos de trabajo invocados mediante AWS Step Functions o documentos de AWS Systems Manager. Copias de seguridad cifradas mediante RDS. Réplicas de lectura entre regiones entre dos regiones de AWS. Replicación entre regiones de activos estáticos en Amazon S3. La restauración se lleva a cabo en la región de AWS activa actual, se practica en un día de juego y se coordina con AWS.