Continuidad de negocio en AWS: Disponibilidad y resiliencia

Por Horacio Ferro, Arquitecto de Soluciones, AWS México.

Trabajando con nuestros clientes en etapas de diseño de arquitectura, comúnmente contamos con requerimientos de nivel de servicio o Service Level Agreement (SLA), los cuales definen diferentes atributos del sistema. Por ejemplo, un SLA de 99.99% de disponibilidad indica que el sistema que estamos diseñando no deberá superar más de 52.56 minutos fuera de línea en 365 días. O por ejemplo un SLA de 99.99% de durabilidad nos indica que por un giga-byte (GB) de información no deberíamos superar la perdida de información por más de 100 bytes.

En términos de recuperación de desastres tenemos dos métricas principales: Recovery Point Objective u Objetivo de Punto de Recuperación, el cual nos indica cuánto tiempo puede existir en términos de perdida de información, por ejemplo, un RPO de una hora indica que si el sistema falló a las 12:00 pm, debemos poder contar con todos los cambios de información generados hasta las 11:00 am, es decir, debemos contar con los mecanismos necesarios para capturar ese cambio de información y resguardarlo en una localidad secundaria. El Objetivo de Tiempo de Recuperación o Recovery Time Objective indica cuánto tiempo el sistema puede estar fuera de línea, por ejemplo, si el RTO es 1hr y el sistema falla a las 12:00 pm, el sistema debe contar con su funcionalidad al 100% a la 1:00 pm.

Cuando diseñamos una arquitectura de software inicialmente nos enfocamos en los requerimientos funcionales, es decir, que es lo que nuestro sistema debe resolver. Una vez que tenemos esta arquitectura es necesario garantizar nuestros atributos de calidad, como son los niveles de servicio (SLAs). Utilizando nuestro AWS Well Architected Framework, específicamente el pilar de Confiabilidad (Reliability) podemos enriquecer nuestra arquitectura para alcanzar SLAs específicos.

En AWS nuestra infraestructura esta distribuida geográficamente en regiones, estas regiones se encuentran aisladas unas de otras, tanto de forma geográfica como en software. Es decir, si existe algún desastre natural las regiones están lo suficientemente alejadas y aisladas para no verse afectadas al mismo tiempo y los servicios son desplegados de forma independiente en cada una de estas regiones.

Dentro de una región de AWS contamos con diferentes zonas de disponibilidad, estas zonas de disponibilidad se encuentran a una distancia que permita latencias de 1ms, cuentan con sistemas redundantes y existe una distancia entre ellas que permita reducir el riesgo de un evento natural que pueda afectar a más de una zona de disponibilidad. Mas información aquí y en este video de Peter DeSantis existe una explicación más a fondo de la infraestructura en AWS.

A continuación revisaremos algunos ejemplos de niveles de disponibilidad alcanzados utilizando varias zonas de disponibilidad y una o más regiones:

• Una sola Región y una o más Zonas de Disponibilidad:

o 99 % Aplicaciones útiles para el negocio, en caso de no estar disponibles solo causan inconvenientes.
o 99.9 % Aplicaciones que pueden tolerar una intermitencia en su recuperación.
o 99.99 % Aplicaciones que deben contar con alta disponibilidad y tolerancia a fallas en alguno de sus componentes.

• Múltiples Regiones y múltiples Zonas de Disponibilidad:

o 99.95 % Aplicaciones con recuperación entre 5 y 30 minutos.
o 99.999 % Aplicaciones con recuperación en menos de 1 minuto.

Tomando como base las definiciones anteriores, ¿cómo logramos llegar a estos objetivos enriqueciendo nuestra arquitectura?

El primer paso es conocer cada uno de los componentes que integran nuestra arquitectura y sus SLAs independientes. Para poder calcular el SLA de un sistema basta con multiplicar los diferentes SLAs entre sí. Ejemplo:

¿Como podemos incrementar el SLA?

Para poder incrementar el SLA de una aplicación es necesario introducir redundancia y tolerancia a fallas en todos los componentes de la arquitectura, desde el cliente hasta la capa de persistencia de datos. En el ejemplo siguiente utilizaremos los siguientes servicios para lograrlo:

• Amazon Route 53 – Utilizando este servicio obtendremos un SLA de 100% para resolución de nombres (DNS).
• Amazon Application Load Balancer (ALB) – Este servicio nos permite balancear las peticiones y tener resiliencia en caso de qué alguna instancia de EC2 falle, se reinicie o se apague. Adicionalmente utilizando un Auto Scaling Group nos permite registrar/eliminar de forma dinámica instancias de EC2 que se agreguen o se detengan.
• Amazon Elastic Cloud Compute (EC2) – En las instancias de EC2 instalaremos los diferentes servicios, una instancia de EC2 nos proveé un SLA de 90%, para poder obtener un 99.99% es necesario utilizar diferentes zonas de disponibilidad, apoyarnos de grupos de auto escalamiento (Auto Scaling Group) y de un balanceador de cargas (ALB).
• Amazon Relational Database Service (RDS) – Para poder obtener un SLA de 99.99% es necesario utilizar un despliegue en múltiples zonas de disponibilidad (Multi AZ).

En esta liga podemos encontrar los SLAs actualizados de los diferentes servicios – https://aws.amazon.com/legal/service-level-agreements/

La siguiente arquitectura cuenta con un SLA de 99.95% (99.99% ˆ 5 = 99.95001%) utilizando varias zonas de disponibilidad dentro de una región de AWS como podemos observar en el siguiente diagrama.

Utilizando está arquitectura en dos regiones podemos obtener el siguiente SLA:

Porcentaje de no disponibilidad de la aplicación en una región 100% – 99.95% = 0.05 % (Hasta 4.38 horas por año)

Porcentaje de no disponibilidad de la aplicación en dos regiones combinadas 0.05% * 0.05% = 0.000025 % (Hasta 7.884 segundos por año)

SLA total utilizando ambas regiones = 100% – 0.000025% = 99.999975 %

NOTA: Si utilizamos esta arquitectura en múltiples regiones es necesario cambiar el servicio de Amazon RDS por otro servicio que funcione en múltiples regiones como activo/activo, como puede ser Amazon Aurora Global Database, y en este caso tomar en consideración la latencia de replica para el cálculo del SLA y su efecto en el RPO/RTO de su aplicación.

¿Cómo puedo reducir complejidad en la arquitectura, tiempo de administración y costos?

Desplegar la arquitectura anterior en dos regiones incrementa de forma considerable la complejidad, esfuerzo administrativo y costos. A continuación diseñaremos una arquitectura similar utilizando dos o más regiones pero con servicios Serverless, con los cuales reduciremos costos al entrar a un esquema de cobro por uso sin infraestructura ociosa, reduciremos la complejidad de la arquitectura y esfuerzo administrativo al ser servicios administrados.

• Amazon Route 53 – Utilizando este servicio obtendremos un SLA de 100% para resolución de nombres (DNS).
• Amazon CloudFront – Este servicio nos permite tener un cache cercano a nuestros clientes, cuenta con un SLA de 99.9%, utilizando Origin Fail Over podemos registrar dos orígenes distintos para combinar los SLAs y tener una mejor disponibilidad.
• Amazon Simple Storage Service (S3) – Utilizando este servicio podemos hospedar un sitio web estático, este servicio tiene un SLA de 99.9%. Habilitando replicación o otra región podemos incrementar este SLA.
• Amazon API Gateway – Con este servicio podemos hospedar APIs REST y conectarlas a otros servicios, API Gateway nos provee con un SLA de 99.95%.
• AWS Lambda – En este servicio podemos hospedar nuestros microservicios obteniendo un SLA de 99.95 %.
• Amazon RDS – Este servicio nos provee un SLA de 99.99%.

Calculando el SLA combinado de los servicios 99.9% * 99.9% * 99.95% * 99.95% * 99.99% = 99.69% obtenemos un SLA 0.24% por debajo del SLA de la arquitectura tradicional pero obtenemos a cambio una arquitectura más sencilla, menos componentes que administrar y un menor costo al no tener infraestructura ociosa. Si a esta arquitectura agregamos otra región de AWS, alcanzamos un SLA de 99.999%.

¿Qué puedo implementar si mis requerimientos de servicio no son tan estrictos?

Existen escenarios donde el costo de tener una infraestructura duplicada no es justificable, es decir, el no disponer del sistema por algunos minutos o incluso horas, puede no afectar la continuidad del negocio. En estos casos existen alternativas que podemos utilizar como un plan de recuperación de desastres, en los cuales el RPO (Recovery Point Objective) y el RTO (Recovery Time Objective) serán la base para seleccionar el método más adecuado.

• Respaldos y recuperación. Este es el método más simple y económico para crear un plan de recuperación de desastres, consiste en generar respaldos, realizar un plan de recuperación y ejecutar pruebas cotidianas de dicho plan. Para que este tipo de plan de recuperación de desastres sea viable nuestros RPO y RTO no pueden ser muy bajos, tomemos en cuenta que al ejecutar este plan hay que restablecer toda la infraestructura y puede llevarnos varias horas o incluso días dependiendo de la complejidad del sistema.
• Flama piloto (Pilot Light). La idea tras este tipo de recuperación de desastre es una analogía de un piloto de calentador de gas, contar con lo mínimo necesario para arrancar el ambiente. En este esquema de recuperación de desastres se tiene una pequeña parte de la infraestructura activa, se mantiene una sincronización de datos mutables (bases de datos, archivos compartidos, etc.). Esta infraestructura debe permitir realizar el despliegue del resto de la infraestructura de forma automática para reducir los tiempos de RPO y RTO, a diferencia de la estrategia de respaldos y restauración, aquí hablamos en escala de minutos a horas.
• Espera cálida (Warm standby). A diferencia de la flama piloto, la espera cálida contiene una replica exacta de la infraestructura pero a escala pequeña, es decir, contamos con todos los componentes de la aplicación original pero con capacidades reducidas. En este caso el sitio alterno tomará menos tiempo en estar disponible al 100% ya que, solo requiere escalar a la demanda en el momento del incidente, reduciendo aún más el RPO y RTO, en este caso estaríamos en una escala de segundos a minutos.

Conclusión:

Para poder obtener una disponibilidad o SLA de 99.999% siempre es necesario considerar un ambiente de múltiples regiones.

Una región de AWS puede aportar hasta 99.99% de disponibilidad para algunos servicios.

Utilizar servicios Serverless disminuye considerablemente la complejidad de despliegues y mantenimiento al eliminar administración de componentes individuales y automatizando tareas como auto escalamiento y tolerancia a fallos.

Siguientes pasos:

Ejercitar el uso de la herramienta del Well Architected Framework para identificar el nivel actual de SLA contra el nivel deseado y realizar los ajustes necesarios.

Sobre el autor

Horacio Ferro es Arquitecto de Soluciones en AWS México.

Revisores

Raul Frias es Arquitecto de Soluciones Head of Mexic

Carlos Castro es Arquitecto de Soluciones Principal Outposts