Compañía de Gestión Inmobiliaria
La Empresa de Gestión de Propiedades se centra en el Software de Gestión Hotelera en la Nube para hoteles pequeños y grandes. Zavia distribuye el inventario del hotel en todos los canales en línea y automatiza los procesos de gestión hotelera en las áreas operativa, administrativa y comercial. El software se ajusta a las necesidades de cada cliente, de modo que solo pagan por lo que utilizan.
Sistema Integral de Operación en la Nube: Desarrollado para la mejora continua y automatización de los procesos empresariales hoteleros mediante motores de reservas, conectividad con gestores de canales, pasarelas de pago, información en tiempo real con informes automatizados y más.
Cloudgenia ayudó a migrar una base de datos de RDS a Amazon Aurora en la infraestructura tecnológica del ERP de la Empresa de Gestión de Propiedades.
Por qué el cliente eligió a este partner
Una clave del éxito fue que la plataforma se implementa en AWS.
Retos tecnológicos
El alcance de este desafío abarca la migración de la base de datos de RDS a Amazon Aurora en la infraestructura tecnológica del ERP de la Empresa de Gestión de Propiedades. Recomendamos crear un entorno de control de calidad (QA) antes de realizar este proceso, donde se pueda replicar el entorno actual y validar un plan de migración con pruebas para la migración final.
Debido a que las migraciones de bases de datos suelen ser complejas, recomendamos un enfoque iterativo y gradual:
- Evaluación
- Planificación de migración
- Pruebas de migración
- Prueba
- Migración final
- Implementación
El ERP de la Empresa de Gestión de Propiedades no cuenta con entornos diferentes, por lo que parte del desafío será crear fases de migración. Una etapa importante es la prueba de migración, por lo tanto, contar con un entorno de “Prueba” donde se pueda validar que todos los procesos sigan funcionando correctamente es muy importante. Este entorno no solo servirá para la validación de la migración de la base de datos, sino también para futuros cambios en la arquitectura.
Esta es una lista de cosas que creemos que deben tenerse en cuenta:
- Creación del entorno de control de calidad (QA): aprovechar la organización de AWS mediante la consola de QA.
- Crear un diagrama de arquitectura actual para la replicación. Nivel alto.
- Asociar usuarios y roles para acceso y permisos.
- Clonar los componentes de la arquitectura actual al entorno de PRUEBA; EC2 y RDS.
- Configurar encendido/apagado para el uso eficiente del entorno de QA.
Amazon Web Services
El cliente ya estaba utilizando AWS, pero tenía deficiencias en cuanto a las tecnologías utilizadas para respaldar la solución, lo que provocaba que el portal o la solución fueran inestables en ciertos momentos y días, especialmente durante la temporada alta, lo que siempre generaba bloqueos.
Ofrecimos un servicio de consultoría en el que ayudamos al cliente inicialmente a generar un entorno de QA, algo que no tenían y necesitaban. El nuevo entorno utiliza menos recursos pero pudo emular el entorno productivo, lo que permite realizar pruebas de estrés a menor escala. Todo esto se desarrolló siguiendo las mejores prácticas de las Organizaciones de AWS, generando unidades de negocios correspondientes, separando las cargas de trabajo del entorno productivo y del QA, identificando así el gasto en cada uno de los entornos.
La solución consistió en la migración al uso gestionado de la base de datos, pasando de MariaDB a Aurora, que entre sus principales ventajas está el multi AZ y la capacidad de generar puntos de escritura y lectura.
Lo anterior es importante porque los procesos por lotes del cliente que generaban bloqueos hacían un uso intensivo de la base de datos. Para mitigar esto, se crearon dos réplicas de lectura, y además, se eligió una familia de cómputo centrada en el uso intensivo de memoria, ya que las métricas de la base de datos anterior indicaban que el consumo de memoria era alto, pasando de una familia M a una familia R.
Resultados y beneficios
Como resultado de la separación de entornos, se descubrió que la base de datos y la aplicación estaban en diferentes regiones; ahora, ambas están ubicadas dentro de la misma región con el objetivo de eliminar los costos de transferencia de datos. Ambos servicios (la aplicación y la base de datos) están en la misma región.
Al utilizar planes de ahorro de Elasticache RDS y EC2, se logró una reducción de costos; estos planes están activos durante un año hasta 2023, y se implementaron al inicio de las actividades de este proyecto.
Se validó que las copias de seguridad de la base de datos están programadas correctamente, algo que no existía antes.
Antes, existía una base de datos m5.2xlarge; después de la migración, ahora tienen una Aurora con la familia r4.xlarge (lectura y escritura). Al cambiar de un motor de base de datos a otro, hubo una reducción significativa de costos, así como un aumento en el rendimiento.
Las mejoras fueron la optimización de costos y rendimiento después de la migración; ahora tienen una versión reducida del entorno productivo (el entorno de prueba). Antes, ocurrían bloqueos del sistema de vez en cuando; ahora, cuentan con muchas herramientas que evitan que esto suceda (se eliminó la latencia multirregión, la caché de base de datos, la base de datos multi AZ y los puntos de escritura/lectura).
El escalado automático permitió que la aplicación ajustara dinámicamente sus recursos según los cambios en la demanda, de modo que el sistema pueda seguir funcionando de manera óptima incluso durante cargas pico o aumentos repentinos de tráfico.
Algunos de los beneficios son:
- Optimización del tiempo del equipo de TI en la gestión de la infraestructura debido al cambio de un esquema local a un esquema en la nube.
- Menores costos al pagar solo por lo que se consume en infraestructura y servicios.
- También existe un plan de costos reservados.
- Escalabilidad y elasticidad de los componentes de la nube en función de la demanda.
