CASO DE ESTUDIO
Zavia Travel
La empresa de gestión de la propiedad se centran en el software de gestión hotelera en la nube para hoteles pequeños y grandes, Zavia Distribuir el inventario del hotel en todos los canales en línea y automatizar el proceso de gestión hotelera en las áreas operativas, administrativas y comerciales.
Desarrollado para la mejora continua y automatización del proceso de negocio hotelero a través de motores de reservas, conectividad con channel managers, pasarelas de pago, información en tiempo real con informes automatizados y mucho más.
Solución propuesta
Vista simplificada del proceso
PRINCIPAL
Desafíos tecnológicos
Zavia gestiona su propia consola de AWS; su arquitectura actual tiene un grupo de aplicaciones EC2 y procesos por lotes que consumen una base de datos MySQL RDS.
Hay algunas caídas ocasionales, pero durante la temporada alta Zavia experimenta un elevado número de solicitudes, y el número de caídas y tiempos de inactividad también aumenta. Las instancias EC2 y la base de datos están en diferentes regiones, lo que también causa latencia.
Saben que lo más probable es que la causa de los problemas sea la base de datos, así que quieren que les propongamos un plan de migración a una nueva base de datos que solucione este problema, pero antes de hacer la migración en entorno de producción, debemos presentar pruebas de que la migración va a funcionar.
El reto planteado por Zavia Travel gira en torno a la mejora del rendimiento y la fiabilidad de su arquitectura debido a las caídas y los tiempos de inactividad ocasionales, especialmente durante los periodos de alta demanda. El objetivo es abordar estos problemas mediante la migración de su base de datos RDS MySQL existente a una nueva solución que pueda gestionar el aumento de la carga sin comprometer la calidad del servicio.
CÓMO
se utilizó AWS como parte de la solución.
Para empezar, se creó un entorno de “prueba” específico para validar el proceso de migración y garantizar que todos los procesos sigan funcionando correctamente. Este entorno no sólo sirve para validar la migración, sino también para futuros cambios de arquitectura.
La migración tiene como objetivo una base de datos RDS Aurora, que ofrece todas las ventajas anteriores en comparación con la base de datos RDS MySQL existente, que está configurada con un nodo de escritura y un nodo de lectura. Esta arquitectura permite optimizar las operaciones de lectura y escritura y, en caso necesario, autoescalar más nodos de lectura.
Todos los recursos de AWS existentes de la arquitectura original se replican en los entornos de prueba, lo que garantiza un terreno de pruebas completo que refleja las condiciones de producción
Las organizaciones de AWS se utilizan para mejorar la administración de recursos, el control de acceso y la gobernanza en diferentes entornos.
Se emplea una instancia EC2 como host bastión para fines de copia de seguridad y restauración. Esta instancia ayuda a facilitar el proceso de migración creando una copia de seguridad de la base de datos MySQL de origen y restaurándola en la base de datos de Aurora.
Las instancias EC2 que realizan operaciones de escritura consumen el endpoint de escritura del nodo de escritura Aurora, mientras que las instancias que necesitan acceso de lectura utilizan el endpoint de lectura de los nodos de lectura Aurora (al final 2 nodos de lectura estaban siempre activos).
Si la migración resulta satisfactoria en la fase de pruebas, la solución puede implantarse en el entorno de producción. Este enfoque por fases minimiza los riesgos y garantiza una transición fluida.
PRINCIPAL
Resultados
- Ahorro estimado de 360,00 USD anuales por transferencia interregional.
- Migración de Amazon RDS a Amazon Aurora ahorro estimado de 3,200 USD anuales al realizar la migración, antes había una base de datos m5.2xlarge (0.6840 USD bajo demanda), ahora una Aurora con familia t4g.large (lectura y escritura, 0.1153 USD por 1 Año Reservado), al cambiar de un motor de base de datos a otro, hubo una reducción significativa en el costo, así como un incremento en el rendimiento.
- Se validó que las copias de seguridad de la BD están correctamente programadas, algo que antes no existía.
- Zavia no poseía un ambiente de pruebas, gracias a nuestras pruebas, ahora existe un ambiente de pruebas que puede ser utilizado para nuevos desarrollos u otras migraciones.
- El autoescalado permitió a la aplicación aumentar o disminuir sus recursos de forma dinámica en función de los cambios en la demanda, de modo que el sistema puede seguir funcionando de forma óptima, incluso durante los picos de carga o picos repentinos en el tráfico dando a Zavia una alta disponibilidad del 99,99%, en otras palabras, no más tiempo de inactividad debido a caídas.
