Una de las últimas novedades que Microsoft nos ha presentado en Azure es Azure SQL Database Serverless. Esta es una funcionalidad que muchos entornos, especialmente de desarrollo, testing, han estado demandando desde hace tiempo. También debemos tener en cuenta que esta funcionalidad existía en competidores como Amazon Aurora Serverless desde hace un tiempo por lo que era algo natural que MS ofreciera algo similar.

Realmente creo que realmente llamarlo Serverless es un poco engañoso y se utiliza este vocablo más por una moda, un hype, que hay ahora alrededor de todo lo que sea “Serverless”. Concretamente lo que deberíamos pensar es más bien en un Azure SQL Database pero con un comportamiento dinámico, ajustado segundo a segundo, en lo que respecta a los recursos asignados en base a las necesidades reales. También se cubre el escenario especial de “0 uso” con la funcionalidad de pausado y de autopausado. Como suele decirse, una imagen vale más que mil palabras y creo que el gráfico de la documentación oficial ayuda bastante a entender lo que se ofrece (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-serverless)

Como es normal, tenemos que asumir algunos tradeoffs que esperamos que poco a poco vayan relajándose. Por ejemplo, actualmente únicamente podemos movernos entre 0 (pausado) y entre 0.5 y 4 vCPUs una vez estemos en modo “activo”. Esto obviamente no es suficiente para muchas cargas, especialmente si no están bien optimizadas, pero como una preview, un comienzo, para poder ahorrar costes en entornos de Dev/QA nos parece una opción muy interesante.

Vamos a ver cómo crear una Azure SQL Database Serverless. El primer paso, aunque suene a chiste, es crear un Azure SQL Server:

El siguiente paso es configurar una base de datos en modo Serverless en dicho servidor. Como podemos ver, tenemos distintos ajustes que podemos realizar, siendo el más importante el mínimo y máximo de vCPUs que podemos tener. La cantidad de memoria estará relacionada precisamente con ese rango, teniendo una cota inferior y una superior. Debemos tener en cuenta que Azure SQL Database Serverless es mucho más agresiva a la hora de reducir la cantidad de memoria en uso, por lo que podemos tener ciertas lentitudes puntuales debido a estos ajustes y a los fallos de página asociados.

Otra opción que podemos ajustar es si queremos que se produzca el auto-pause de forma automatizada. Actualmente, el margen inferior es bastante elevado, y podemos ajustar este autopause entre 6 horas (mínimo) y 7 días (máximo). Es previsible que pronto se pueda controlar esto de forma manual con los comandos Suspend/Resume-AzSqlDatabase que actualmente únicamente funcionan para SQL Data Warehouse pero no para Azure SQL Database Serverless a día de hoy.

Un inconveniente del auto-pause es que debemos asumir que el primer intento tras encontrarse la base de datos pausada fallará y tendremos que esperar hasta aproximadamente 1 minuto hasta que esté disponible de nuevo, por lo que o bien debemos tener algún proceso que sea “tolerante” a estas latencias o bien asegurarnos mediante algún mecanismo que la base de datos despierta antes del momento en el que realmente la necesitemos activa.

Vamos a comprobar cómo se produce el escalado utilizando para ello una consulta que, aproximadamente, consume aproximadamente 1 segundo de CPU:

create procedure test 
as
select count(*) from 
(
  select top 40000000 s1.object_id 
  from sys.objects s1, sys.objects s2,
  sys.objects s3,sys.objects s4,sys.objects s5
) a

set statistics time on
exec test
-- SQL Server Execution Times:
-- CPU time = 1094 ms,  elapsed time = 1084 ms.

Si lanzamos este exec con un único thread veremos que aproximadamente se estabiliza el consumo en un 23%:

Si aumentamos a 2 threads concurrentes subimos a un 46% aproximadamente:

Finalmente, si subimos a 4 threads consumimos prácticamente el total de CPU disponible como máximo:

Desde el portal podemos ver esta información de consumo de CPU también:

Lo más interesante es que podemos observar también el consumo que se nos va a facturar:

Podemos ver que tenemos un consumo “base” remanente que no es despreciable que siempre vamos a tener hasta que se pause la instancia, lo cual no ocurrirá hasta que transcurra el tiempo configurado. La fórmula de cálculo se realiza teniendo en cuenta la memoria en uso también por lo que es un poco más complejo. Concretamente tenemos en la documentación la siguiente fórmula y el periodo sobre el que se reporta (cada minuto):

  • Metric: app_cpu_billed (vCore seconds)
  • Definition: max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
  • Reporting frequency: Per minute

En el portal o mediante powershell podremos comprobar cuando el estado ha pasado a paused por inactividad:

Get-AzSqlDatabase `
  -ResourceGroupName $resourcegroupname `
  -ServerName $servername `
  -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

 

También podremos ver que el coste asociado a la CPU/Memoria cae a cero durante este tiempo:

No hemos comentado nada respecto al coste del storage, el cual es un coste fijo de aproximadamente 1€/mes por cada 10 GB. Teniendo en cuenta que normalmente este tipo de escenarios serverless con “hasta 4 vCPUs” no van a tener bases de datos de gran tamaño es prácticamente despreciable dicho coste.

Una vez estemos en esta situación de pausa, si intentamos conectar, obtendremos un error:

Tras 47 segundos en mi caso, la conexión se aceptó y la query que estaba intentando lanzarse ejecutó:

En el portal o vía powershell ya nos aparecerá como activa de nuevo la base de datos también:

Y comenzarán a registrarse de nuevo los consumos hasta el siguiente pausado:

Idealmente creemos que este sistema “serverless” es muy potente y esperamos que con el tiempo se reduzcan algunas de sus limitaciones. Por ejemplo, sería deseable:

  • Poder realizar pausados y rearancados de la instancia bajo demanda de forma directa. Cuanto más ágiles sean mejor, para, por ejemplo, poder arrancar la base de datos antes de un ciclo de pruebas de QA y poderla pausar en cuanto hemos finalizado con las pruebas.
  • Permitir un mayor rango de vCPUs, siendo posible asumir cargas con más variabilidad y necesidades puntuales, por ejemplo, hasta 16 vCPUs (en vez de 4 vCPUs como máximo)
  • Permitir un ajuste mayor en el rango de memoria, valores mínimos y máximos no ligados necesariamente a la cantidad de CPU en uso. Esto podría ayudar a aquellas cargas que requieran un working set de memoria más elevado pero sin un consumo de CPU excesivo.

 

En conclusión, Microsoft sigue ofreciéndonos novedades a los profesionales de datos de forma que podamos darles un uso en nuestras organizaciones. Esta es la década de los datos sin duda y también lo será de la modernización de las plataformas de datos lo cual va a requerir por parte de todos los profesionales de un esfuerzo de adaptación y formación considerable. Si estás interesado en formarte con nosotros, puedes acceder a nuestro catálogo de training aquí: https://training.solidq.com/

Rubén Garrigós

Rubén Garrigós is an expert in high-availability enterprise solutions based on SQL Server design, tuning, and troubleshooting. Over the past fifteen years, he has worked with Microsoft data access technologies in leading companies around the world. He currently is a Microsoft SQL Server and .NET applications architect with SolidQ. Ruben is certified by Microsoft as a Solution Expert on the Microsoft Data Platform (MSCE: Data Platform) and as a Solution Expert on the Microsoft Private Cloud (MSCE: Private Cloud). As a Microsoft Certified Trainer (MCT), Ruben has taught multiple official Microsoft courses as well as other courses specializing in SQL Server. He has also presented sessions at official events for various Microsoft technologies user groups.

Latest posts by Rubén Garrigós (see all)