Foto de Rob Wicks en Unsplash
Introducción
Las ediciones de BigQuery les presentaron a los clientes nuevos modelos de Precios y actualizaciones bastante relevantes a los modelos existentes.
En DoiT trabajamos con muchos clientes para diseñar sistemas bien arquitecturados, aprovechar los servicios de la nube de forma eficiente y optimizar costos. A raíz de los cambios en BigQuery, varios clientes nos contactaron para reducir los costos de cómputo y evaluar la transición de 'On-Demand' al nuevo modelo de Precios, la 'Standard Edition'.
A continuación te guiaremos paso a paso para determinar si la migración resulta rentable y cómo ejecutarla y monitorearla.
El código SQL que se referencia en el post requiere acceso a estas vistas INFORMATION_SCHEMA: JOBS_BY_PROJECT, JOBS_TIMELINE_BY_PROJECT, RESERVATION_CHANGES_BY_PROJECT.
Requisitos previos para acceder a las tablas: roles/bigquery.resourceViewer (a nivel de proyecto)
El núcleo de la reserva de Standard Edition
La Standard Edition, una oferta basada en cómputo (Slot hours), se diferencia de otras opciones basadas en cómputo porque opera a nivel de proyecto (igual que On-Demand) y no a nivel de organización.
Su principal ventaja es el acceso a la función de autoscaling a bajo costo y sin ningún compromiso: "BigQuery ajusta dinámicamente tus slots según el aumento o la disminución de tu workload." ( Introduction to slots autoscaling )
Las diferencias clave entre On-Demand y Standard Edition son:
1. Unidades de cobro: On-Demand cobra según los datos escaneados, mientras que la Standard Edition usa un modelo de slot/hora.
2. Disponibilidad de slots: en On-Demand los slots se consideran "calientes" y están disponibles al instante; en Standard Edition, el AutoScaler identifica la capacidad de slots necesaria para los jobs antes de asignarlos (con una demora de unos 10 segundos), lo que afecta la latencia de las consultas.
3. Slots máximos disponibles: On-Demand tiene 2000 slots y Standard Edition, 1600.
\[1\] Checklist de features y limitaciones
El primer paso es verificar la compatibilidad de tu proyecto con la Standard Edition. Revisa con detalle la lista de features y asegúrate de entender bien las capacidades y restricciones:
Aquí encontrarás una comparación detallada y completa: BigQuery editions features.
\[2\] Analiza el uso del workload
Una vez revisadas las features y restricciones, el siguiente paso es estimar los gastos según si tu proyecto está orientado a I/O o a CPU (Slot). En la vista INFORMATION_SCHEMA.JOBS puedes obtener estos datos a partir de total_bytes_billed (I/O) y total_slot_ms (CPU).
El objetivo es comparar el gasto por datos escaneados con el gasto aproximado por uso de slots. Calcular el gasto basado en I/O es relativamente sencillo, ya que es la suma del costo de todas las consultas. En cambio, la estimación basada en slots queda algo subestimada porque no considera el comportamiento del autoscaler (bloques de 100 slots y reducción tras un mínimo de un minuto). Para corregir esa diferencia, aplicaremos un multiplicador de 1.5 a la estimación basada en slots.
La tabla siguiente compara los costos mensuales con el ratio entre el costo de Slot y el de On-Demand, e indica el cambio de costo estimado al pasar de On-Demand a Standard Edition.
Un ratio inferior a 100 sugiere una posible reducción de costo, mientras que un valor superior a 100 indica un posible incremento.
Por ejemplo:
Gasto mensual del cliente — On-Demand resulta más caro
Gasto mensual del cliente — On-Demand resulta más barato
Código para crear la tabla anterior: BigQuery OnDemand vs. SE.sql
Como la Standard Edition tiene menos features que la edición On-Demand, recomendamos quedarte con On-Demand si el ratio supera el 75%. El ahorro esperado será mínimo y, a cambio, se pierden funcionalidades.
\[3\] Configuración de slots máximos
La Standard Edition requiere una única configuración: el máximo de slots, que actúa como límite superior del AutoScaling.
¿Cómo determinar la configuración adecuada?
Lamentablemente no existe una solución única. El parámetro probablemente requerirá ajustes después de la configuración inicial, según el patrón de tu workload y cómo quieras balancear costo y rendimiento.
Una forma de calcular un valor inicial es con esta fórmula:
Identifica la hora del percentil 90 dentro del período seleccionado en la que el uso de slots haya superado los 100 (configuración básica) y redondea al múltiplo de 100 más cercano hacia arriba.
Configuración máxima basada en la hora P90 del período seleccionado
Ejemplo de fragmento de código para definir la configuración máxima inicial: BQ SE max configuration.sql
Crear la reserva
Aquí tienes una guía paso a paso bien documentada para crear una reserva: Get started with reservations.
Selecciona Standard Edition, define 'max Slots' y elige la región o multi-región adecuada; de lo contrario, la reserva no funcionará correctamente.
\[4\] Monitoreo del rendimiento y evaluación de costos
Impacto en el rendimiento
Para hacer seguimiento al rendimiento de tu aplicación, recopila métricas como los tiempos de procesamiento de jobs y los tiempos de respuesta de consultas ad-hoc antes de la migración y compáralos con los resultados posteriores. Conviene avisar a los usuarios de BigQuery sobre los cambios previstos y recoger su opinión.
Puedes evaluar el rendimiento desde la perspectiva del sistema consultando los Administrative resource charts que veremos en la siguiente sección.
Beneficios en costos
Para evaluar la rentabilidad, revisa tus gastos en el dashboard diario de billing. Selecciona los SKU de Analysis y Standard Edition en la sección de billing.
La tabla siguiente suma, en intervalos de una hora, la asignación total de slots y los costos estimados. Con esta información puedes calcular de manera aproximada el costo real según las acciones del autoscaler.
Ejemplo de fragmento de código: Standard Edition cost estimation.sql
Distribución estimada de costo por hora
\[5\] Ajuste fino
Ajustar la configuración de la Standard Edition implica modificar el máximo de slots para mejorar el rendimiento (subiendo slots) o reducir gastos (bajándolos). La meta es un sistema bien balanceado, sin recursos subutilizados ni sobreasignados.
Monitorear la eficiencia de tu workload te mostrará si el sistema está balanceado, subutilizado o sobreaprovisionado. Para ello, observa los Administrative resource charts o consulta directamente las vistas de INFORMATION_SCHEMA.
Administrative resource charts:
Los administradores de BigQuery monitorean el uso de Slots en su organización y el rendimiento de los jobs de BigQuery a lo largo del tiempo. Estos charts están en la sección 'Monitoring' del menú lateral de BigQuery y ofrecen distintas vistas para responder distintas preguntas. Para familiarizarte con estas funcionalidades, consulta la guía sobre administrative resource charts.
- Análisis del uso de slots: usa la métrica P90 o P99 para examinar la relación entre el uso y la asignación de slots (que incluye "baseline + Autoscaled slots") y el tiempo necesario para escalar hacia arriba o hacia abajo.
Uso de slots
El gráfico anterior usa datos de la vista RESERVATION_CHANGES_BY_PROJECT, que contiene información sobre las modificaciones de la reserva.
La tabla siguiente muestra la asignación de slots y la duración hasta el siguiente cambio (escalado hacia arriba o hacia abajo). La métrica 'allocated_slots' representa la cantidad de slots asignados en un momento dado hasta que ocurre un nuevo 'UPDATE', mientras que 'Estimated total slots' representa la asignación total durante todo el período.
Ejemplo de fragmento de código: Monitor BQ edition autoscaling.sql
Asignaciones reales de slots con su duración
- Concurrencia de jobs: para identificar los cuellos de botella del sistema, revisa la métrica 'pending jobs'.
Jobs pendientes
- Rendimiento de los jobs: monitorea los jobs con alta latencia con la medida del percentil 90 (P90).
Latencia de jobs
Resumen y recomendación
En casos con bursts o picos pueden existir enfoques más adecuados que este, que requieren un análisis más profundo. Aun así, las herramientas aportan información valiosa durante todo el análisis.
La transición depende sobre todo del tipo de uso que hagan los usuarios en cada proyecto: orientado a I/O (lo que encarece 'On-Demand') u orientado a CPU (lo que encarece 'Standard Edition').
Google recomienda principalmente la Standard Edition para proyectos de investigación y desarrollo, e indica: "Por ejemplo, la Standard Edition es ideal para workloads ad-hoc, de desarrollo y de testing."
Como el término 'workload de producción' puede significar cosas distintas según el cliente, algunos podrían considerar usar la Standard Edition incluso para workloads de producción ETL/ELT. Esto sería aceptable si se cumplen las limitaciones de la edición (sobre todo el SLA del 99.9), si la carga se mantiene estable en el tiempo y si ningún usuario final se ve afectado por la latencia de las consultas.
Ahora que conoces el proceso, ponlo en práctica y cuéntanos cómo te fue.