Public Preview do BigQuery Autoscaling: o que você precisa saber (Edição DoiT)

Aqui vai uma rápida introdução aos termos usados ao longo deste artigo. Se você já conhece o BigQuery, a maior parte vai soar familiar; caso contrário, esta seção serve de apoio antes de seguir em frente.

• Job Um job é uma ação executada no BigQuery para realizar algum trabalho, como consultas, carregamento de dados, cópia de dados etc. O tipo mais comum é a consulta, e os dois termos são usados quase como sinônimos.
• Slot A unidade básica de computação que o BigQuery usa para executar o trabalho de um job. Pense nele como uma "mini máquina virtual" que se junta a várias outras para fazer o trabalho de fato.
• Reservation Estrutura que reserva um conjunto de slots para ser utilizado por zero ou mais projetos vinculados a ela.
• Commitment Um número fixo de slots reservados por um período predeterminado, geralmente um mês ou um ano, em troca de um preço menor.
• Admin Project Projeto designado como o "gerente" das reservations e commitments do BigQuery. Em geral, uma organização tem um único (ou poucos) projetos desse tipo, criando um "painel único" para gerenciar os recursos do BigQuery. Em projetos flat-rate e de autoscaling, os SKUs de cobrança das reservations de toda a organização ficam associados a esse projeto.
• Flex Slots Slots que podem ser adicionados a uma reservation para um pico de curta duração no número de slots. Vale notar que são cobrados por segundo, com período mínimo de cobrança de 60 segundos.
• Idle Slot Um slot que não está sendo utilizado em nenhum job no momento.
• Workloads Um workload é um conjunto de jobs executados dentro de um único projeto.
• Slot/Hora Métrica básica de cobrança em projetos com BigQuery Autoscaling. É definida como um único slot utilizado em um job por uma hora.
• Autoscaling Slots Nova estrutura que escala o número de slots a partir de um valor base (baseline) até um valor máximo, conforme a necessidade do workload em execução.
• Baseline Slots A quantidade mínima de slots mantidos "quentes" e ativos em um projeto com BigQuery Autoscaling. Eles são utilizados primeiro, antes do autoscaling entrar em ação, e ficam sendo cobrados enquanto a reservation estiver ativa.

O Google acaba de colocar em public preview um recurso muito aguardado: o autoscaling de slots do BigQuery, para quando os workloads precisam de mais slots do que a capacidade contratada permite.

Em linhas gerais, ele permite que o BigQuery suba e desça os slots conforme a demanda dos workloads, sem qualquer intervenção manual — como uma Cloud Function que ajusta uma reservation de Flex Slots quando determinados limites de uso são atingidos.

Como o modelo de cobrança do BigQuery tem mais de 10 anos e se baseia em "pague pelos dados escaneados" e "pague pela capacidade", ele não combina muito bem com autoscaling de capacidade computacional. Para acomodar essa mudança, o Google introduziu um modelo de cobrança mais moderno, baseado no "pague pelo que usar", para esse novo recurso.

O recurso é exatamente o que o nome diz: autoscaling de slots. Ou seja, quando um workload precisa de mais slots, o BigQuery passa a escalar o número de slots dentro da reservation para cima e para baixo conforme a necessidade dos jobs em execução.

Junto com isso, como mencionei, vem um novo modelo de cobrança baseado em uma estrutura chamada "slot/hora", que nada mais é do que o preço pelo uso de um único slot por uma hora, faturado por segundo.

* Note que essa mudança afeta apenas o lado de preços de computação/análise do BigQuery, e não os custos de armazenamento. O armazenamento não é afetado em nada por essas mudanças. Tenha isso em mente ao ler o restante deste artigo.

Isso é extremamente poderoso se você usa cobrança flat-rate hoje e precisa de mais slots do que tem reservados. Os Flex Slots ofereciam uma forma de obter mais slots, mas não eram automáticos e exigiam ferramentas extras, normalmente uma Cloud Function rodando em intervalos para checar a métrica de slots usados e adicionar ou remover Flex Slots de uma reservation conforme necessário. Um bom exemplo disso está aqui (sem afiliação com a DoiT). Infelizmente, se você precisasse de mais slots na hora, não havia muito a fazer — a menos que construísse e pagasse por uma infraestrutura adicional só para isso.

Antes de aprofundar, vale notar que esse novo modelo de cobrança pode ser aplicado a uma única reservation, que pode conter zero ou mais projetos. Ou seja, dá para combinar on-demand, flat-rate e autoscaling como achar melhor entre reservations e projetos, otimizando uso ou custos.

Na prática, quando você tem um projeto com um valor baseline definido, todos os jobs começam usando os baseline slots e só começam a escalar quando esses se esgotam. Vale notar que se trata de um pool de slots compartilhado entre todos os jobs em execução nos projetos dentro de uma reservation, igual ao que acontece em uma reservation flat-rate. Quando deixam de ser usados, os slots são reduzidos novamente, e você não é cobrado por eles — esse é o grande diferencial em relação aos Flex Slots, que são cobrados até serem removidos.

Dito isso, há uma janela de 60 segundos em que o BigQuery decide como vai escalar. Isso evita que consultas de curta duração escalem até o seu valor máximo de slots e gerem cobrança excessiva por slots que nem eram necessários.

Como acontece com frequência DEMAIS no mundo da nuvem, a resposta é: depende. Essa resposta é frustrante, então vamos direto a alguns cenários em que esse novo modelo de autoscaling seria ideal:

Suponha que você tenha um workload executado só algumas vezes por dia, por períodos curtos, mas que consome uma quantidade enorme de slots (pense em alguns milhares). Os Flex Slots até podem ser usados, mas muitas vezes esse job roda em menos de um minuto, então você acaba pagando a mais pelo período mínimo de cobrança de 60 segundos dos Flex Slots, mesmo sem usá-los nesse intervalo.

E se você tem workloads que usam quantidades enormes de slots (mais de 2 mil, para igualar a contagem on-demand) e são muito intensivos em leitura — o que faz com que a cobrança on-demand não compense —, então é um candidato perfeito para o Autoscaling. Além disso, muitas vezes esses workloads são disparados por uma ação do cliente, e não há tempo de criar uma reservation de Flex Slots para executá-los.

Por fim, se seus workloads são bem irregulares, dá para comparar o uso de slots na nossa calculadora de BigQuery Autoscaling Slots com o seu setup atual e ver se o novo modelo se encaixa melhor.

As reservations nesse novo modelo de autoscaling são, em grande parte, iguais às anteriores da cobrança flat-rate, mas trazem alguns conceitos novos e algumas diferenças.

Elas continuam sendo criadas dentro de um projeto de gerenciamento e, dentro de cada reservation, há zero ou mais projetos aos quais os slots são alocados.

Como agora existe a ideia de escalonamento, há um valor mínimo de escala, chamado "Baseline Slots", e um valor máximo, chamado "tamanho máximo da reservation" ou "max slots".

O valor de max slots é definido como a soma do valor de Baseline Slots com o número de slots autoscalados configurados para a reservation inteira.

Por padrão, se um job (ou conjunto de jobs) ultrapassar o limite de autoscaling da sua reservation, ele pode pegar slots emprestados de outras reservations do mesmo projeto de gerenciamento. Há uma caixa de seleção chamada "Ignore idle slots" que permite desativar esse comportamento na tela de "Create Reservation":

O preço é totalmente diferente dos modelos tradicionais que o BigQuery vinha adotando há um bom tempo. O novo modelo se baseia em um conceito chamado slot/hora, que é o valor cobrado por slot por uma hora de uso, faturado por segundo.

O Autoscaling cobra com base em quanto tempo você usa um slot. A cobrança é por segundo, mas usa a hora como referência prática para arredondar os números. Então, se você usar um único slot por 900 segundos (1/4 de hora em segundos), será cobrado por 0,25 slot/hora. Para 3.600 segundos (1 hora em segundos), serão 1,0 slot/hora. Espera-se que você use mais de um slot por job, então basta multiplicar pelo número de slots usados para descobrir quantos slot/horas serão cobrados.

O que falta para definir o preço é o custo por slot/hora, que no public preview é de US$ 0,06 por slot/hora. Esse valor pode mudar, já que o recurso ainda está em preview.

A fórmula geral para calcular o custo de um job é:

Preço = 0,06 * (<Slots usados> * (<Segundos usados>/3600))

Não é a coisa mais fácil de ler, mas, no fundo, você está multiplicando os slots usados pelas horas em que foram usados (segundos usados / 3600 segundos). Parece mais difícil do que é.

Foi por isso que criamos uma calculadora para facilitar a sua estimativa de preço e as comparações. A planilha é somente leitura, então faça uma cópia para o seu ambiente do Workspace antes de usar.

Como esse é um recurso novo do Google, há novos SKUs de preço associados, para você acompanhar seus gastos no DoiT Console (antiga Cloud Management Platform, ou CMP).

Os custos de slot/hora são cobertos por um SKU com nome semelhante a este:

BigQuery Autoscale Preview for US (multi-region)

O ID desse SKU é: B8BE-01DC-0ECF

Os commitments anuais (descritos abaixo) são cobertos por um SKU com nome semelhante a este:

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

O ID dele é: C0F6–38AB-6629

A região, ou multirregião, varia nos nomes dos SKUs, mas o formato é o mesmo para todas as regiões.

Assim como na cobrança flat-rate, o Autoscaling tem um recurso de commitment em que você se compromete a usar um número fixo de slots, em conjuntos de 100, por um período determinado em troca de um preço menor. Funcionam da mesma forma que um commitment flat-rate, exceto que, no Autoscaling, só são permitidos commitments anuais. São por região ou por multirregião, igual ao commitment flat-rate, ou seja, você precisa utilizá-los na região ou multirregião específica em que foram contratados para aproveitar a economia.

*Vale notar que, ao fechar um commitment, você é cobrado pelo valor total, da mesma forma que ocorreria em um commitment flat-rate. Em termos de cobrança, eles são tratados exatamente como commitments flat-rate.

O preço de um commitment anual é US$ 0,05 por slot/hora, contratado em conjuntos de 100. Isso equivale a aproximadamente US$ 3.504 por mês para 100 slots, contra cerca de US$ 4.380 por mês para 100 slots executados durante o mês inteiro (considerando 730 horas por mês) sem commitment.

O método mais simples para migrar da cobrança flat-rate para o Autoscaling é apenas editar a reservation, alterando-a de flat-rate para Autoscaling. O Google facilitou essa troca: não é preciso excluir e recriar reservations.

Já migrar de on-demand para Autoscaling (ou flat-rate) é um processo um pouco mais elaborado. Recomendo fortemente ler a documentação do Google sobre o assunto aqui antes de migrar e, depois, seguir o passo a passo para criar uma reservation, mas selecionando Autoscaling em vez de flat-rate no menu.

Por fim, essa pergunta provavelmente está sendo feita porque muitos usuários do BigQuery não fazem ideia. Não se preocupe, a gente te ajuda!

Em uma série anterior de artigos que escrevi sobre otimização de custos no BigQuery, publiquei um conjunto de consultas em um repositório no GitHub com várias queries que ajudam nessa tarefa. Antes de executar qualquer coisa desse repositório, fique de olho no volume de dados escaneados, pois elas podem processar quantidades enormes (>2 TB em alguns dos nossos datasets internos) com facilidade.

Embora o tema seja extenso e fuja bastante do escopo deste artigo, recomendo executar as seguintes consultas:

• Slots por minuto Essa consulta gera uma série temporal sobre o período analisado e mostra o número de slots usados em cada minuto.
• Top consultas complexas Essa consulta retorna as consultas mais complexas (neste caso, definidas como as que mais usaram slots) no período especificado.
• Informações do job Essa consulta retorna estatísticas sobre um Job ID, incluindo informações de slots. É muito útil quando você identifica que um job está com problemas de desempenho e quer ver se ele precisa de mais slots para executar mais rápido.