Alta disponibilidad vs tolerancia a fallos en la nube

Contenido del curso

No sé dónde empezar

Introducción al curso

Cómo entender la nube

Introducción a Cloud Computing / Nube

Conceptos de Cloud Computing / Nube

Multi-Nube

Modelos de servicio en Cloud Computing / Nube

20
IaaS, PaaS y SaaS explicados con pizza
06:29 min

Características de una arquitectura en Cloud Computing /Nube

Construyendo nuestra arquitectura

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0011:22

Alta disponibilidad vs tolerancia a fallos en la nube

Curso de Introducción a la Nube

Clase 21 de 27

Clase 21 / 27

Recursos

Diseñar una aplicación en la nube exige entender dos conceptos que definen su resiliencia: alta disponibilidad y tolerancia a fallos. Si trabajas con arquitecturas cloud y quieres que tu aplicación siga operando aunque falle un componente, esta guía te muestra cómo aplicarlos con un caso real: Platzi Wallet.

¿Qué es la alta disponibilidad en arquitecturas cloud?

La alta disponibilidad es la forma en la que despliegas tu aplicación para que siga funcionando aunque uno de sus componentes falle. Si despliegas Platzi Wallet en una sola zona de disponibilidad y esa zona cae, tu aplicación deja de operar y dejas de ser altamente disponible.

De ahí sale la primera regla práctica que vale la pena tatuarse: toda aplicación en la nube debe ejecutarse en al menos dos zonas de disponibilidad. Así, si una se cae, la otra sigue atendiendo el tráfico.

¿Qué es alta disponibilidad? Es la capacidad de una aplicación de seguir operativa cuando uno de sus componentes falla, gracias a desplegarla en al menos dos zonas de disponibilidad.

¿Cómo funciona la alta disponibilidad con Platzi Wallet?

Imagina que un usuario hace un pago. El request llega al balanceador de aplicaciones, que busca el microservicio de pagos desplegado en la zona 1 y la zona 2. Si la zona 2 se cae, el balanceador redirige el request a la zona 1 y el pago se procesa.

La aplicación sigue disponible. Eso es alta disponibilidad en acción [03:45].

¿Qué son el RTO y el RPO y por qué importan?

Para dimensionar bien la alta disponibilidad necesitas dos métricas hermanas que siempre van juntas: RTO y RPO. Una habla de tiempo, la otra habla de datos.

¿Qué es el RTO o recovery time objective?

El RTO (Recovery Time Objective) es el tiempo máximo que tu aplicación puede estar caída sin afectar la continuidad del negocio. Si decides que Platzi Wallet puede tardar 10 minutos en volver a operar tras un desastre regional, tu RTO es de 10 minutos. En esos 10 minutos automatizas el redespliegue usando infraestructura como código y vuelves a estar operativo [01:30].

Y aquí viene lo interesante: a menor RTO, el costo crece de forma exponencial. ¿Cómo logras un RTO casi cero? Teniendo dos Platzi Wallet corriendo en paralelo en regiones distintas bajo un modelo activo-pasivo, listo para hacer switch de DNS cuando una región caiga.

¿Qué es el RPO o recovery point objective?

El RPO (Recovery Point Objective) es el volumen de datos que estás dispuesto a perder antes de volver a estar operativo. No mide tiempo de caída, mide pérdida de información.

¿Cuál es la diferencia entre RTO y RPO? El RTO mide cuánto tiempo puedes estar caído. El RPO mide cuántos datos puedes perder. Uno es tiempo, el otro es punto de recuperación.

Un ejemplo claro: si haces backup de la base de datos de Platzi Wallet todos los días a las 8:00 a.m. y la base se rompe a las 7:59 a.m., perdiste casi 24 horas de registros. Tu RPO es de 24 horas. Si haces backup cada dos horas, en el peor caso pierdes dos horas de datos [02:50].

Cuando preguntas a un cliente cuál quiere que sea su RPO, casi siempre responde "cero". Lograrlo es posible con replicación activo-activo a nivel de base de datos, pero la complejidad técnica y el costo son altos.

¿Qué es la tolerancia a fallos y en qué se diferencia de la alta disponibilidad?

La tolerancia a fallos es la capacidad de soportar fallas en los sistemas y mantener la disponibilidad sin caída ni degradación del servicio. Es un concepto más grande que la alta disponibilidad y la contiene [04:20].

Aquí entran los SLA (Service Level Agreement), los acuerdos de nivel de servicio. Si le prometes a tu usuario que la aplicación estará inactiva como máximo una hora al mes, ese compromiso es tu SLA.

¿Cuándo una aplicación es tolerante a fallos y no solo altamente disponible?

Volvamos al ejemplo. Platzi Wallet tiene dos microservicios de pagos por zona. Si la zona 2 cae, sigues operando con dos microservicios en la zona 1, pero pasaste de cuatro a dos atendiendo el tráfico. La aplicación está disponible, pero hay degradación del servicio mientras escala.

Para ser tolerante a fallos deberías tener al menos cuatro microservicios por zona, de modo que ante una caída no haya degradación perceptible.

¿Una app tolerante a fallos es siempre altamente disponible? Sí. Si es tolerante a fallos, implícitamente es altamente disponible. Pero al revés no aplica: puedes ser altamente disponible sin ser tolerante a fallos.

¿Cómo aplicar estos conceptos en una estrategia de disaster recovery?

Definir RTO y RPO no es un ejercicio teórico. Es la base de tu estrategia de disaster recovery: si pasa algo, en cuánto tiempo vuelves a estar operativo y cuánta información pierdes.

Algunas ideas para guiar tus decisiones:

Si tu RTO es de un segundo, necesitas una arquitectura activo-activo con replicación en tiempo real.
Si tu RTO es de ocho horas, basta con backups periódicos y restaurarlos cuando ocurra el incidente.
Define RTO y RPO por cada aplicación según su criticidad para el negocio.
Prueba las estrategias antes de necesitarlas, no después.

Ahora te toca a ti: piensa en una aplicación que estés diseñando, define su RTO y RPO, y ajusta la arquitectura según esos números. ¿Qué estrategia de disaster recovery elegirías y por qué? Cuéntame en los comentarios.

José Pablo Cabrera Romo

Hace 3 años

Las estrategias de recuperación ante desastres, conocidas como Disaster Recovery (DR), son fundamentales para garantizar la continuidad de los negocios y la protección de los datos en situaciones de emergencia. Aquí tienes algunas estrategias comunes de Disaster Recovery:

Copias de seguridad regulares: Realizar copias de seguridad de los datos críticos y almacenarlas en ubicaciones seguras, ya sea en servidores locales o en la nube. Las copias de seguridad deben ser automáticas y se deben probar de forma periódica para asegurarse de que se pueden restaurar correctamente.
Replicación de datos: Configurar la replicación en tiempo real o cerca de tiempo real de los datos críticos en servidores o centros de datos secundarios. Esto garantiza que siempre haya una copia actualizada de los datos disponibles.
Centros de datos secundarios o fuera del sitio: Mantener un centro de datos secundario o un sitio de recuperación ante desastres en una ubicación geográfica diferente. Esto protege los datos y sistemas en caso de desastres naturales o incidentes locales.
Virtualización y contenedores: Utilizar tecnologías de virtualización y contenedores para permitir la rápida implementación de sistemas y aplicaciones en servidores alternativos en caso de una falla en el servidor principal.
Plan de Continuidad de Negocios (BCP): Desarrollar un plan de continuidad de negocios que detalle cómo se debe actuar en caso de desastres. Esto debe incluir la asignación de funciones y responsabilidades, la comunicación con el personal y proveedores, y los pasos específicos para la recuperación.
Pruebas de recuperación ante desastres: Realizar pruebas periódicas de DR para asegurarse de que todos los procedimientos funcionen correctamente. Esto ayuda a identificar posibles problemas antes de que ocurra un desastre real.
Servicios de nube para DR: Utilizar servicios de nube como parte de su estrategia de DR. Muchos proveedores de nube ofrecen servicios específicos de recuperación ante desastres que pueden facilitar la recuperación y reducir los costos.
Recuperación de datos en tiempo real (RTO) y punto de recuperación (RPO): Definir objetivos claros para el tiempo de recuperación (cuánto tiempo puede pasar antes de que se restaure el servicio) y el punto de recuperación (cuántos datos se pueden perder). Estos objetivos varían según la crítica de la aplicación y los datos.
Almacenamiento resiliente: Utilizar tecnologías de almacenamiento resiliente, como RAID, para proteger los datos contra fallos de hardware.
Educación y capacitación del personal: Asegurarse de que el personal esté capacitado y preparado para responder adecuadamente a situaciones de recuperación ante desastres.

Es importante adaptar las estrategias de DR a las necesidades y presupuesto de su organización. Un enfoque adecuado para la recuperación ante desastres puede minimizar el tiempo de inactividad y proteger los activos críticos en caso de cualquier incidente inesperado.

Piero Nolte

Hace 2 años

Excelente aporte!

Comentarios (33)33 comentarios

Javier Cómbita Téllez

Diego Fernando Ramos Aguirre

Patricio Sánchez Fernández

Julian David Alzate Cuervo

Lucas Rojas

Walter Omar Barrios Vazquez

Alex Naupay

Carlos Andrés Zambrano Barrera

Profesor

Gildder Guerrero Ramirez

Enrique Rojas Reyes

Mauricio Ruiz Rubio

Eyair Raul Ayala Flores

Hace 4 meses

Julian Mauricio Perez Mora

Jan Cobian

Osvaldo Chípuli

Rommer Batista

Jose Luis Quintero Sánchez

Kevin Guzman

Introducción al curso

5 razones para usar la nube ahora

Aplicación de Billetera Virtual: Conceptos y Funcionalidades Básicas

Cómo entender la nube

Servidores y almacenamiento en la nube

Tipos de bases de datos en la nube

Microservicios, funciones y contenedores en la nube

On-premises vs nube: qué cambia al escalar

Introducción a Cloud Computing / Nube

Qué es cloud computing y cómo se cobra

Ventajas reales de migrar a la nube

Qué cambia al migrar una app a la nube

Infraestructura Global en la Nube: Regiones y Zonas de Disponibilidad

Nube privada, pública, híbrida y multinube

Conceptos de Cloud Computing / Nube

Qué es cloud native y por qué importa

Arquitectura cloud native de una app real

Ventajas y retos del modelo serverless

Componentes clave de una arquitectura serverless

Arquitectura serverless con API y funciones

Principales Proveedores de Servicios Cloud y Sus Ventajas

Multi-Nube

Tipos de lock-in en arquitectura cloud

Estrategias multinube para elegir tu proveedor

Modelos de servicio en Cloud Computing / Nube

IaaS, PaaS y SaaS explicados con pizza

Características de una arquitectura en Cloud Computing /Nube

Alta disponibilidad vs tolerancia a fallos en la nube

Escalabilidad vertical vs horizontal en la nube

Construyendo nuestra arquitectura

Diagramación de Arquitectura Agnóstica para Aplicaciones

Arquitectura de Servidores para Escalabilidad y Alta Disponibilidad

Kubernetes y microservicios con autoescalado

Arquitectura Serverless: Diseño y Escalabilidad de Funciones

Tu primer paso para elegir proveedor cloud

Alta disponibilidad vs tolerancia a fallos en la nube