El escalado automático de Azure es una característica de Azure Product as a Service (PaaS) que nos permite aumentar o disminuir recursos automáticamente mediante reglas de escalado, gracias a las cuales podemos establecer umbrales o programaciones con las que disminuir los recursos que requieran una aplicación.
¿Por qué deberíamos usar escalado automático de Azure?
Pongamos que para un cliente realizamos a diario realizamos cargas de datos para mantener su sistema actualizado. Pongamos que al final de cada mes, recibimos unos ficheros con gran cantidad de información, muy superior a la que se requiere día a día. Para realizar dicha carga mensual, se necesita disponer de más recursos para realizarla, lo cual provoca un aumento de costes, pero gracias a Azure Auto Scaling, se puede programar para disponer de estos recursos automáticamente solo cuando hagan falta, disminuyendo así los costes.
Los Escalados pueden ser horizontales o verticales, pero el que nos ocupa en el blog es el escalado vertical de bases de datos, que se utiliza para aumentar o disminuir los recursos de los que disponemos para realizar nuestras cargas de datos. El escalado de bases de datos se puede realizar por niveles como veremos en el siguiente apartado.
Niveles de bases de datos y escalado por DTU
En Azure existen 3 niveles de servicios (Basic, Estándar y Premium), los cuales tienen subniveles con una cantidad correspondiente de DTU (Database Throughput Unit). El DTU es una unidad abstracta con la que se representan los recursos que tenemos disponibles de memoria, CPU, disco, y velocidad de lectura y escritura. Por regla general, el doble de DTU se corresponde con el doble de rendimiento en un Benchmark.
Los niveles de Servicio que se disponen son desde el básico con 5 DTU, que es ideal para una sola base de datos que realice una sola operación a la vez, hasta Premium con 4000 DTU, que permite múltiples operaciones concurrentes con múltiples bases de datos de gran volumen, pero muy caro mantener ese nivel de servicio comparado con niveles más bajos. Para ayudar a informarnos del nivel que requerimos, existe una calculadora online en la siguiente URL.
En los casos que tengamos múltiples bases de datos con distintas cargas, se puede generar un grupo elástico que permita compartir los recursos entre sí. De este modo, es posible que tengamos bases de datos distintas que requieran gran cantidad de recursos a distintas horas, y que puedan compartir esos recursos.
¿Cómo se realiza el escalado?
En el portal de Azure, podemos seleccionar la base de datos que necesitamos hacer el escalado, y en el menú de la izquierda seleccionamos ‘Configurar’, así nos saldrán los niveles que disponemos.
Si queremos un escalado automático por núcleos, podemos pulsar en vCore-based purchasing options desde donde podemos elegir los núcleos y recursos que queremos al realizar el escalado automático para disponer de más recursos cuando sea necesario.
Otra forma de realizar el escalado automático por DTU, sería realizarlo en el Data Factory, dentro de un Pipeline programado en una rutina como se puede ver aquí mediante el uso de procedimientos almacenados.
Si tenemos una suscripción Estándar, podemos alternar entre S0 y S3 por ejemplo, para que en el uso normal de la base de datos se encuentre en S0, pero cuando vayamos a realizar cargas de datos lo haga en S3.
ALTER DATABASE [FastDB] MODIFY (SERVICE_OBJECTIVE = ‘S3’);
ALTER DATABASE [FastDB] MODIFY (SERVICE_OBJECTIVE = ‘S0′);
Nótese que el escalado no es instantáneo, por lo que será necesario introducir un delay mientras se realiza el escalado o que dependa de que acabe otra operación. Un ejemplo de introducir el delay sería con una caja de procedimiento almacenado con la siguiente sentencia: WAITFOR DELAY ’00:03:00’.
Si estás interesado en este tema y otros relacionados, échale un vistazo a los workshops que tenemos preparados para ti este año sobre Azure y Planes de ejecución en SQL Server en nuestro SolidQ Summit, el evento nacional dedicado a la plataforma de datos de Microsoft. Aprende cosas nuevas y comparte conocimientos con nuestros MVP de Microsoft y con toda la comunidad SolidQ.
