En este artículo vamos a plantear una solución para minimizar costes de BBDD en los modelos de bases de datos Azure SQL en procesos aprovisionados.
Uno se pregunta si el modelo ServerLess ya escala de forma automática y ayuda a reducir costes (incluso pudiendo configurar una pausa del servicio cuando ha pasado un tiempo sin usarse). ¿Por qué elegir el modelo de provisión de recursos? Existen varios escenarios en los que deberíamos escoger este último modelo:
- Bases de datos únicas con patrones de uso más regular y predecibley mayor uso promedio de proceso a lo largo del tiempo.
- Bases de datos que no pueden tolerar compensaciones de rendimiento resultantes de recortes de memoria más frecuentes, o de demoras en la reanudación automática desde un estado de pausa.
- Varias bases de datos con patrones de uso impredecibles e intermitentes que se pueden consolidar en grupos elásticos para una mejor optimización de la relación precio-rendimiento.
Una vez tenemos claro que el modelo provisionado es lo que realmente necesita nuestra BBDD, si tenemos identificados los patrones de uso (Escenario A), podemos implementar de forma sencilla esta solución para minimizar costes:
Vamos a pensar en un escenario en el que la BBDD tiene un uso bastante intensivo en horario de oficina, en un modelo de trabajo tradicional (de 08 a 18 horas). En el resto de los horarios tiene un uso residual, fines de semana incluidos.
Para que nuestra aplicación no tenga denegaciones de servicio, hemos hecho un análisis previo y requiere de una talla de BBDD que cuesta 1.000€ al mes (licencia poética) en horario de trabajo. Durante las horas de uso residual hemos visto que una talla de 50€ al mes es suficiente. Si suponemos que en un mes tenemos 22 días hábiles (por simplificar obviaremos festivos y demás escenarios esporádicos), adaptando las tallas de BBDD en función de los patrones de uso de la aplicación, estaríamos pagando 340€ en lugar de 1.000€ (la comprobación de estos datos os la regalo en forma de ejercicio de cálculo mental 😉 .
Vale, me has convencido, pero ¿cómo se hace?
El dimensionamiento del nivel de precios de nuestra BBDD es una tarea sencilla si contamos con los privilegios adecuados. Esto es posible desde varios sitios:
a) Desde el portal de Azure. Esta es la opción más generalizada, además cuenta con la ventaja de poder visualizar el coste mensual:
b) Desde SQL Management Studio, posicionándonos sobre nuestra BBDD, botón derecho propiedades > Configure SLO (Service Level Objetive)
c) Por último, la opción que nos va a permitir automatizarlo, mediante un script de sql como este:
ALTER DATABASE [database_name] MODIFY (EDITION = ‘Standard’, MAXSIZE = 250 GB, SERVICE_OBJECTIVE = ‘S4’);
Gracias a este script vamos a aprovechar la potencia de los conectores de logic app para ajustar el nivel de precio de nuestra BBDD a las horas de uso intensivo, y lo dejaremos a un nivel de precio suficiente para el resto de los horarios. Seguiremos los siguientes pasos:
1. Desde el portal de Azure, crearemos un proyecto de LogicApp, según la imagen:
- Añadimos un trigger de recurrencia en el que vamos a configurar cuándo se va a lanzar el proceso. En nuestro caso, queremos que se ejecute de lunes a viernes a las 07:55 de la mañana, tiempo suficiente para anticiparnos al periodo de uso intensivo. Importante seleccionar la zona horaria, porque de lo contrario, cogerá por defecto el horario del servidor.
- Añadimos un conector de SQL Server y seleccionamos Executea SQL Query. En este caso, seleccionamos la autenticación mediante SQL Server, así que introducir credenciales de administrador de SQL. Luego introducimos la query mencionada anteriormente para dimensionar nuestra BBDD.
- Opcionalmente, escribiremos un mensaje de aviso. Los conectores de LogicApp nos dan un amplio abanico de posibilidades: correo electrónico, SMS, etc. Buscaremos el canal preferente de comunicación que tengamos establecido. En nuestro caso, vamos a escribir un mensaje en un canal de Teams.
- Para rebajar el nivel de precio una vez finalizado el periodo de uso intensivo, tenemos dos opciones:
a) Crear otra LogicApp de igual forma que esta
b) Añadir un temporizador, tras el cual ejecutar la query para dimensionar a la baja. En este ejemplo vamos a utilizar este, con el fin de tener toda la trazabilidad del proceso en un solo sitio.
Una vez hayamos terminado de configurar la Logic App, al guardar se publicará automáticamente. Si queremos comprobar que todo está configurado correctamente, podemos poner un delay de prueba (como en este caso, 5 minutos) y pulsamos en Run Trigger para ejecutar el flujo de forma manual.
Conclusión
En resumen, podemos aportar mucho valor a nuestra empresa o nuestros clientes y ayudar a minimizar costes con muy poco esfuerzo. Además, la potencia de las Logic App admite mucha personalización para adecuarla a nuestro escenario.
¡Suscríbete a nuestras RRSS!
