Situación de 5 nueves (99,999 %) o superior con un tiempo de recuperación inferior a un minuto

Este objetivo de disponibilidad para las aplicaciones casi no requiere tiempo de inactividad o pérdida de datos en momentos específicos. Las aplicaciones que podrían tener este objetivo de disponibilidad incluyen, por ejemplo, ciertas aplicaciones comerciales bancarias, de inversión, financieras, gubernamentales y críticas que son el negocio principal de un negocio que genera ingresos extremadamente grandes. Lo deseable es tener almacenes de datos fuertemente consistentes y una completa redundancia en todas las capas. Seleccionamos un almacén de datos basado en SQL. Sin embargo, en algunas situaciones, nos resultará difícil lograr un RPO muy pequeño. Si puede particionar sus datos, es posible que no haya pérdida de datos. Esto podría requerir incorporar latencia y lógica de aplicación para asegurarse de tener datos consistentes entre ubicaciones geográficas, así como la capacidad de mover o copiar datos entre particiones. Realizar esta partición podría ser más fácil si usa una base de datos NoSQL.

Podemos mejorar aún más la disponibilidad mediante el uso de una estrategia activa-activa entre varias regiones de AWS. La carga de trabajo se desplegará en todas las regiones deseadas que sean estáticamente estable entre regiones (de modo que las regiones restantes puedan afrontar la carga con la pérdida de una región). A enrutamiento dirige el tráfico a ubicaciones geográficas que estén en buen estado y cambia automáticamente el destino cuando el estado de una ubicación no sea correcto. Además, detiene temporalmente las capas de replicación de datos. Amazon Route 53 ofrece comprobaciones de estado en intervalos de 10 segundos y también ofrece TTL en sus conjuntos de registros de hasta un segundo tan solo.

Monitorear los recursos

Igual que la situación de 3 nueves y medio, y además alerta cuando se detecta una región en mal estado y se desvía el tráfico de ella.

Adaptación a los cambios en la demanda

Igual que la situación de 3 nueves y medio.

Implementar cambios

La canalización de implementación tendrá un conjunto de pruebas completo, que incluye pruebas de inyección de error, carga y rendimiento. Implementaremos actualizaciones mediante implementaciones de valor controlado o azul-verde en una zona de aislamiento a la vez, en una región antes de comenzar en la otra. Durante el despliegue, las versiones antiguas se seguirán ejecutando en instancias para facilitar una restauración más rápida. Están completamente automatizados y se incluye una restauración si los KPI indican un problema. El monitoreo incluirá métricas de éxito, así como alertas cuando ocurran problemas.

Los runbooks existirán para requisitos de informes rigurosos y seguimiento del rendimiento. Si las operaciones correctas tienden a no cumplir con los objetivos de rendimiento o disponibilidad, se utilizará una guía de estrategias para establecer qué causa la tendencia. Las guías de estrategias existirán para modos de error no descubiertos e incidencias de seguridad. También existirán guías de estrategias para establecer la causa raíz de los errores.

El equipo que compila el sitio web también lo opera. Ese equipo identificará la corrección de cualquier error inesperado y priorizará la solución que se desplegará después. También tratamos con AWS Support para la gestión de eventos de infraestructura.

Copia de seguridad de los datos

Igual que la situación de 3 nueves y medio.

Diseñar para la resiliencia

Las aplicaciones deben compilarse con los patrones de resiliencia de software o aplicación. Es posible que se requieran muchas otras capas de enrutamiento para implementar la disponibilidad necesaria. La complejidad de esta implementación adicional no debe subestimarse. La aplicación se implementará en zonas de aislamiento de errores de implementación y se dividirá e implementará para que incluso un evento de toda la región no afecte a todos los clientes.

Prueba de resiliencia

Validaremos la arquitectura a través de los “días de juego” con runbooks para asegurarnos de que podemos realizar las tareas y no nos desviamos de los procedimientos.

Planificar para la recuperación de desastres (DR)

Despliegue multirregional activo-activo con infraestructura de carga de trabajo completa y datos en múltiples regiones. Se utiliza una estrategia de lectura local y escritura global, una región es la base de datos principal para todas las escrituras y los datos se replican para la lectura a otras regiones. Si la región de la base de datos principal falla, tendrá que promocionarse una nueva base de datos. El método de lectura local y escritura global tiene usuarios asignados a una región inicial donde se gestionan las escrituras en la base de datos. Esto permite que los usuarios lean o escriban desde cualquier región, pero requiere una lógica compleja para administrar los conflictos de datos potenciales entre escrituras en distintas regiones.

Cuando se detecta que una región está en mal estado, la capa de enrutamiento dirige el tráfico automáticamente a las regiones en buen estado restantes. No se requiere ninguna intervención manual.

Los almacenes de datos se deben replicar entre las regiones para poder resolver posibles conflictos. Será necesario crear herramientas y procesos automatizados para copiar o mover datos entre las particiones por razones de latencia y para equilibrar las solicitudes o cantidades de datos en cada partición. La solución de la resolución de conflictos de datos también requerirá runbooks operativos adicionales.

Objetivo de diseño de disponibilidad

Suponemos que se realizan grandes inversiones para automatizar toda la recuperación y que la recuperación se puede completar en un minuto. Suponemos que no hay recuperaciones desencadenadas manualmente, sino hasta una acción de recuperación automatizada por trimestre. Esto implica cuatro minutos al año para recuperarse. Asumimos que la aplicación está en línea continuamente a través de actualizaciones. En función de esto, nuestro objetivo de diseño de disponibilidad es del 99,999 %.

Resumen

Tema	Implementación
Monitorear los recursos	Comprobaciones de estado en todas las capas, incluido el estado de DNS en el nivel de región de AWS y KPI; se envían alertas 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 nivel de aplicación con escalado automático y la web; almacenamiento con escalado automático y réplicas de lectura en varias zonas de las regiones activas y pasivas del RDS de Aurora. Datos e infraestructura sincronizados entre regiones de AWS para estabilidad estática.
Implementar cambios	Despliegue automatizado a través de valores controlados azul-verde y restauración automática cuando los KPI o alertas indican problemas no detectados en la aplicación; los despliegues se realizan 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 del RDS para cumplir con el RPO y la restauración automatizada que se practica regularmente en un día de juego. Los datos del RDS de Aurora y de S3 se replican de forma automática y asíncrona desde la región activa hasta la pasiva.
Diseñar para la resiliencia	Zonas de aislamiento de errores implementados para la aplicación; Auto Scaling para proporcionar un nivel de aplicación y web de recuperación automática; RDS es Multi-AZ; conmutación por error regional automatizada.
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 guías 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 funciones para su implementación inmediata.
Planificar para la recuperación de desastres (DR)	Despliegue activo-activo en al menos dos regiones. Infraestructura a plena escala y con estabilidad estática entre regiones. Datos particionados y sincronizados entre regiones. Copias de seguridad cifradas a través del RDS. Fallos de regiones practicados mediante días de juego y coordinados con AWS. Durante la restauración, es posible que tenga que promocionarse una nueva base de datos principal.