Situación de 4 nueves (99,99 %)

Este objetivo de disponibilidad para aplicaciones requiere que la aplicación esté altamente disponible y sea tolerante a errores de componentes. La aplicación debe ser capaz de absorber errores sin necesidad de obtener recursos adicionales. Este objetivo de disponibilidad es para aplicaciones críticas que son los principales o importantes generadores de ingresos para una corporación, como un sitio de comercio electrónico, un servicio web de empresa a empresa o un sitio de contenido o medios de alto tráfico.

Podemos mejorar aún más la disponibilidad mediante el uso de una arquitectura que será estáticamente estable dentro de la región. Este objetivo de disponibilidad no requiere ningún cambio de plano de control en el comportamiento de nuestra carga de trabajo para tolerar errores. Por ejemplo, debe haber suficiente capacidad para soportar la pérdida de una zona de disponibilidad. No deberíamos requerir actualizaciones para el DNS de Amazon Route 53. No deberíamos necesitar crear ninguna infraestructura nueva, ya sea crear o modificar un bucket de S3, crear nuevas políticas de IAM (o modificaciones de políticas) o modificar las configuraciones de tareas de Amazon ECS.

Monitorear los recursos

El monitoreo incluirá métricas de éxito, así como alertas cuando ocurran problemas. Además, habrá alertas en cada reemplazo de un servidor web incorrecto, cuando la base de datos falle y cuando falle un AZ.

Adaptación a los cambios en la demanda

Usaremos Amazon Aurora como RDS, lo que permitirá el escalado automático de las réplicas de lectura. En estas aplicaciones, diseñar priorizando la disponibilidad de lectura por encima de la disponibilidad de escritura del contenido principal también es una decisión clave de la arquitectura. Aurora también puede aumentar automáticamente el almacenamiento según sea necesario, en incrementos de 10 GB hasta 64 TB.

Implementar cambios

Aplicaremos actualizaciones con despliegues de valor controlado o azul-verde en cada zona de aislamiento de forma separada. Las implementaciones están completamente automatizadas, incluida una restauración si los KPI indican un problema.

Los runbooks existirán para requisitos de informes rigurosos y seguimiento del rendimiento. Si las operaciones exitosas 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. También nos comprometeremos con AWS Support para ofrecer gestión de eventos de infraestructura.

El equipo que cree y opere el sitio web identificará la corrección de cualquier error inesperado y priorizará la solución que se desplegará después.

Copia de seguridad de los datos

La copia de seguridad y la restauración se pueden hacer con Amazon RDS. Se ejecutará regularmente con un runbook para garantizar que podamos cumplir con los requisitos de recuperación.

Diseñar para la resiliencia

Recomendamos tres zonas de disponibilidad para este enfoque. Con un despliegue de tres zonas de disponibilidad, cada AZ tiene una capacidad estática del 50 % de pico. Se podrían utilizar dos zonas de disponibilidad, pero el coste de la capacidad estáticamente estable sería mayor porque ambas zonas tendrían que tener el 100 % de la capacidad máxima. Agregaremos Amazon CloudFront para proporcionar almacenamiento en caché geográfico, así como la reducción de solicitudes en el plano de datos de nuestra aplicación.

Usaremos Amazon Aurora como RDS y desplegaremos réplicas de lectura en las tres zonas.

La aplicación se creará con los patrones de resiliencia de software o aplicación en todas las capas.

Prueba de resiliencia

La canalización de despliegue tendrá un conjunto de pruebas completo, que incluye pruebas de inyección de error, carga y rendimiento..

Practicaremos nuestros procedimientos de recuperación de errores constantemente durante los “días de juego”, utilizando runbooks para asegurarnos de que podamos realizar las tareas y no desviarnos de los procedimientos. El equipo que compila el sitio web también lo opera.

Planificar para la recuperación de desastres (DR)

Existen runbooks para la recuperación total de la carga de trabajo y la creación de informes habituales. La recuperación usa las copias de seguridad almacenadas en la misma región que la carga de trabajo. Los procedimientos de restauración se llevan a cabo de forma habitual como parte de los días de juego.

Objetivo de diseño de disponibilidad

Suponemos que al menos algunos errores requerirán una decisión manual de ejecutar la recuperación. Sin embargo, con una mayor automatización en esta situación, suponemos que solo dos eventos al año requerirán esta decisión y las acciones de recuperación serán rápidas. Tomamos 10 minutos para decidir ejecutar la recuperación, y suponemos que la recuperación se completa en cinco minutos. Esto implica 15 minutos para recuperarse del error. Suponiendo dos fallos al año, nuestro tiempo de impacto estimado durante el año es de 30 minutos.

Esto significa que el límite superior de disponibilidad es del 99,99 %. 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 recupera. En esta arquitectura, suponemos que la aplicación está en línea continuamente cuando recibe actualizaciones. En función de esto, nuestro objetivo de diseño de disponibilidad es del 99,99 %.

Resumen

Tema	Implementación
Monitorear los recursos	Comprobaciones de estado en todas las capas 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 nivel de aplicación de escalado automático y la web; almacenamiento con escalado automático y réplicas de lectura en varias zonas para el RDS de Aurora.
Implementar cambios	Implementación automatizada a través del valor controlado o azul-verde y restauración automática cuando los KPI o alertas indican problemas no detectados en la aplicación. Las implementaciones se realizan por zona de aislamiento.
Copia de seguridad de los datos	Copias de seguridad automatizadas a través de RDS para cumplir con RPO y restauración automatizada que se practica regularmente en un “día de juego”.
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.
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.
Planificar para la recuperación de desastres (DR)	Copias de seguridad cifradas a través del RDS en la misma región de AWS que se practica en un día de juego.