BigQuery Autoscaling Public Preview: el análisis completo (edición DoiT)

Aquí va un repaso rápido de los términos que aparecen en este artículo. Si ya conoces BigQuery, la mayoría te resultarán familiares; si no, esto te servirá antes de seguir.

• Job: un job es una acción que se ejecuta en BigQuery para realizar una tarea, como consultar, cargar datos, copiar datos, etc. El tipo más común de job es una query, y ambos términos suelen usarse de forma intercambiable.
• Slot: la unidad básica de cómputo que BigQuery utiliza para ejecutar un job. Piénsalo como una "mini máquina virtual" que se combina con muchas otras para realizar el trabajo real de un job.
• Reserva: estructura que reserva un conjunto de slots para que los utilicen cero o más proyectos asociados a ella.
• Commitment: número fijo de slots reservados durante un período comprometido, normalmente un mes o un año, a cambio de un precio más bajo.
• Admin Project: proyecto designado como "administrador" de las reservas y commitments de BigQuery. Por lo general, una organización tiene uno solo (o unos pocos) para contar con un "single pane-of-glass" en la gestión de los recursos de BigQuery. En proyectos flat-rate y autoscaling, los SKUs de facturación de las reservas de toda la organización se asocian con este proyecto.
• Flex Slots: slots que pueden agregarse a una reserva para un aumento puntual y de corto plazo en la cantidad de slots. Se facturan por segundo, con un período mínimo de facturación de 60 segundos.
• Idle Slot: slot que en este momento no está siendo utilizado por ningún job.
• Workloads: un workload es un conjunto de jobs que se ejecutan dentro de un mismo proyecto.
• Slot/Hora: la métrica básica de facturación para los proyectos de BigQuery Autoscaling. Se define como un único slot utilizado en un job durante una hora.
• Autoscaling Slots: nueva estructura que escala el número de slots desde un valor base (Baseline) hasta un valor máximo, según lo necesite el workload en ejecución.
• Baseline Slots: cantidad mínima de slots que se mantienen "en caliente" y activos en un proyecto de BigQuery Autoscaling. Se utilizan primero, antes de que ocurra el autoscaling, y se facturan mientras la reserva esté activa.

Google acaba de poner en public preview una funcionalidad muy esperada: el slot autoscaling de BigQuery, para cuando los workloads necesitan más slots de los que permite la capacidad contratada.

En términos generales, le permite a BigQuery escalar hacia arriba y hacia abajo los slots que necesitan los workloads sin ninguna intervención manual, como una Cloud Function que ajustara una reserva de Flex Slots al alcanzarse ciertos umbrales de uso.

Como el modelo de facturación de BigQuery tiene más de 10 años y se basa en "pagar por datos escaneados" y "pagar por capacidad", no encajaba muy bien con el autoscaling de la capacidad de cómputo. Para resolverlo, Google introdujo un modelo de facturación más moderno, basado en el enfoque de "paga por lo que usas" para esta nueva funcionalidad.

Esta funcionalidad hace exactamente lo que su nombre indica: autoescala los slots. Es decir, cuando un workload necesita slots adicionales, BigQuery ahora autoescala el número de slots dentro de la reserva, hacia arriba y hacia abajo, según lo requieran los jobs en ejecución.

Junto con esto, como ya mencioné, llega un nuevo modelo de facturación basado en una unidad llamada "slot/hora": el precio por usar un único slot durante una hora, facturado por segundo.

* Ten en cuenta que este cambio afecta solo al lado de Precios de cómputo y análisis de BigQuery, no a los costos de almacenamiento. El almacenamiento no se ve afectado en absoluto. Tenlo presente al leer el resto del artículo.

Esto resulta enormemente útil si actualmente usas facturación flat-rate y necesitas más slots de los que tienes reservados. Los Flex Slots ofrecían una alternativa para conseguir más slots, pero no eran automáticos y requerían herramientas adicionales, normalmente una Cloud Function ejecutada por intervalos que revisaba la métrica de slots usados y agregaba o eliminaba Flex Slots de una reserva según fuera necesario. Hay un buen ejemplo aquí (sin afiliación con DoiT). Por desgracia, si necesitabas más slots de inmediato, no había mucho que hacer, a menos que construyeras y pagaras infraestructura adicional para lograrlo.

Antes de profundizar, conviene tener presente que este nuevo modelo de facturación se puede aplicar a una sola reserva, que puede contener cero o más proyectos. Esto significa que puedes combinar on-demand, flat-rate y autoscaling como prefieras entre reservas y proyectos para optimizar uso o costos.

En la práctica, cuando tienes un proyecto con un valor baseline definido, todos los jobs comenzarán usando esa cantidad de baseline slots y empezarán a escalar una vez que se hayan agotado. Ten en cuenta que estos forman un pool compartido de slots entre todos los jobs que se ejecutan en los proyectos dentro de una reserva, igual que en una reserva flat-rate. Cuando dejan de usarse, se reducen para que no se te facturen, y ahí está la diferencia con los Flex Slots, que se facturan hasta que se eliminan.

Dicho esto, hay una ventana de 60 segundos durante la cual BigQuery decide cómo escalar. Esto evita que las queries cortas escalen hasta tu máximo de slots y te facturen de más por slots que en realidad no eran necesarios.

Como pasa DEMASIADO seguido en el mundo cloud, la respuesta es: depende. Esa respuesta no convence a nadie, así que veamos algunos escenarios donde este nuevo modelo de autoscaling sería ideal:

Imagina que tienes un workload que se ejecuta solo unas pocas veces al día durante un período corto, pero que usa una cantidad enorme de slots (digamos un par de miles). Aquí podrías usar Flex Slots, pero muchas veces este job termina en menos de un minuto, así que terminas pagando de más por el período mínimo de facturación de 60 segundos cuando ya no se está usando.

Y si tienes workloads que usan cantidades enormes de slots (más de 2k para igualar el conteo de slots on-demand) y son muy intensivos en lectura, lo que hace que la facturación on-demand no tenga sentido, entonces son candidatos perfectos para Autoscaling. Además, muchas veces estos workloads se inician por una acción del cliente, así que no hay tiempo de crear una reserva de Flex Slots para ejecutarlos.

Por último, si tus workloads son muy variables, puedes comparar su uso de slots con tu configuración actual en nuestra calculadora de Autoscaling Slots de BigQuery y ver si te conviene más.

Las reservas bajo este nuevo modelo de autoscaling son en su mayoría iguales a las reservas anteriores de facturación flat-rate, pero suman algunos conceptos nuevos junto con varias diferencias.

Se siguen creando dentro de un management project y, dentro de cada reserva, hay cero o más proyectos a los que se les asignan slots para su uso.

Como esto introduce un nuevo concepto de escalado, ahora hay un valor mínimo de escalado, llamado "Baseline Slots", y un valor máximo de escalado, llamado "tamaño máximo de reserva" o "max slots".

El valor de max slots se define como la suma del valor de Baseline Slots y el número de slots autoescalados configurados para toda la reserva.

Por defecto, si un job o un conjunto de jobs supera la cantidad máxima de autoscaling de su reserva, puede tomar prestados slots de otras reservas del mismo management project. Hay una casilla llamada "Ignore idle slots" que permite desactivar esta funcionalidad en la pantalla "Create Reservation":

Los Precios son completamente distintos a los modelos tradicionales que BigQuery ha mantenido por bastante tiempo. El nuevo modelo se basa en el concepto de slot/hora: un cargo por slot por una hora de uso, facturado por segundo.

Autoscaling factura tu uso según cuánto tiempo usas un slot. Se factura por segundo, pero usa la hora como punto de redondeo para los números. Así, si usas un solo slot durante 900 segundos (1/4 de hora en segundos), se te facturarán 0.25 slot/horas. Por 3.600 segundos (1 hora en segundos), se te facturará 1.0 slot/hora. Lo más probable es que uses más de un slot por job, así que multiplicar esto por la cantidad de slots usados te dará el total de slot/horas a facturar.

La pieza que falta para calcular el precio es el costo por slot/hora, que durante el public preview se fijó en $0.06 USD por slot/hora. Ten en cuenta que esto puede cambiar al estar la funcionalidad en preview.

Entonces, la fórmula general para determinar el costo de un job es:

Precio = 0.06 * (<Slots usados> * (<Segundos usados>/3600))

No es la más fácil de leer, pero esencialmente se multiplican los slots usados por las horas en que se usaron (segundos usados / 3600 segundos). Parece más complicado de lo que es.

Por eso creamos una calculadora para que te resulte más fácil estimar Precios y comparar. Es de solo lectura, así que primero crea una copia en tu entorno de Workspace para sacarle provecho.

Como esta es una nueva funcionalidad de Google, también hay nuevos SKUs de Precios para que puedas hacer seguimiento de tu gasto en la DoiT Console (anteriormente Cloud Management Platform o CMP).

Los costos de slot/hora se cubren con un SKU con un nombre como este:

BigQuery Autoscale Preview for US (multi-region)

El ID de este SKU es: B8BE-01DC-0ECF

Los commitments anuales (que veremos más abajo) se cubren con un SKU con un nombre como este:

BigQuery Autoscale Preview 1 Year for US (multi-region)

El ID es: C0F6–38AB-6629

La región, o multi-región, cambiará en los nombres de los SKUs, pero el formato se mantiene igual para todas las regiones.

Al igual que en los Precios flat-rate, Autoscaling cuenta con una funcionalidad de commitment con la que puedes comprometerte a usar un número fijo de slots, en bloques de 100, durante un período definido a cambio de un precio más bajo. Funcionan igual que un commitment flat-rate, salvo que en Autoscaling solo se permiten commitments anuales. Son por región o por multi-región, igual que un commitment flat-rate, lo que significa que debes usarlos en la región o multi-región específica donde se compraron para obtener el ahorro.

*Ten en cuenta que al adquirir un commitment se te cobrará por el valor total del compromiso, igual que con un commitment flat-rate. En términos de facturación, se tratan exactamente igual que los commitments flat-rate.

El precio de un commitment anual es de $0.05 USD por slot/hora, comprado en bloques de 100. Esto se traduce en aproximadamente $3.504 USD al mes por 100 slots, frente a aproximadamente $4.380 USD al mes por 100 slots ejecutados durante un mes completo (asumiendo 730 horas al mes) sin commitment.

La forma más sencilla de pasar de facturación flat-rate a Autoscaling es simplemente editar la reserva y cambiarla de flat-rate a Autoscaling. Google facilitó el cambio y no hace falta eliminar ni recrear reservas.

Pasar de on-demand a Autoscaling (o flat-rate) implica un proceso un poco más extenso. Recomiendo encarecidamente leer la documentación de Google sobre el tema aquí antes de hacer el cambio, y luego seguir los procedimientos para crear una reserva, pero seleccionando Autoscaling en lugar de flat-rate en el menú.

Por último, esta pregunta seguramente surge porque muchos usuarios de BigQuery no tienen idea. ¡Tranquilo, te tenemos cubierto!

En una serie de artículos anterior que escribí sobre optimización de costos en BigQuery, publiqué un conjunto de queries de BigQuery en un repositorio de GitHub con varias consultas que te ayudarán con esto. Antes de ejecutar cualquier cosa de este repositorio, presta atención a la cantidad de datos escaneados, ya que estas queries pueden procesar volúmenes enormes de datos (>2 TB en algunos de nuestros datasets internos) con facilidad.

Aunque este tema es muy amplio y queda fuera del alcance de este artículo, te recomiendo ejecutar las siguientes queries:

• Slots by Minute: esta query crea una serie temporal sobre el rango de fechas y muestra el número de slots usados durante ese período de un minuto.
• Top Complex Queries: esta query devuelve las queries más complejas (en este caso, definidas como las que más slots usan) durante el rango de tiempo especificado.
• Job Information: esta query devuelve estadísticas sobre un Job ID, incluida la información de slots. Es muy útil cuando detectas que un job tiene problemas de rendimiento y quieres ver si necesita slots adicionales para ejecutarse más rápido.