Guia para iniciantes em Snowpark Container Services: entenda os blocos de construção e os preços

O Snowpark Container Services permite executar aplicações em containers diretamente dentro do Snowflake. É a versão do Snowflake para o AWS ECS, o Google Cloud Run ou o Azure Container Instances. Só que, em vez de rodar na sua conta de nuvem, os containers rodam no ambiente de compute do Snowflake e têm acesso nativo aos seus dados no Snowflake.

O melhor é que os containers conseguem consultar tabelas do Snowflake diretamente, chamar funções do Snowflake e acessar seus dados sem precisar criar uma service account, gerenciar credenciais de acesso aos dados ou mover dados para fora da plataforma. Além disso, os usuários do seu app recebem acesso por meio de um simples grant statement, ou seja, você não precisa desenvolver software de autenticação nem gerenciar usuários, senhas etc. Recentemente implantei um app em container para um cliente AWS / Snowflake, e eles escolheram SPCS no lugar do ECS porque a gestão de usuários e a segurança são muito mais simples.

Existem vários artigos com exemplos de como implantar apps no Snowpark Container Services. Neste artigo, o foco fica nos blocos de construção (terminologia), preços e algumas nuances ou diferenças em relação aos serviços de containers tradicionais.

Vamos entender os quatro objetos principais com os quais você vai trabalhar:

1. Image Repository

É o container registry do Snowflake, parecido com o Docker Hub ou o Amazon ECR. Você faz push das suas imagens Docker para cá, e o Snowflake puxa essas imagens ao iniciar seus services.

1CREATE IMAGE REPOSITORY my_app_repo;

O Snowpark Container Services não puxa imagens de container diretamente de registries externos como o Docker Hub. Você pode usar imagens base públicas durante o build local, mas, antes de implantar no Snowflake, é preciso fazer push da imagem final para um Snowflake image repository dentro da sua conta. Os services só conseguem rodar imagens armazenadas no sistema de repositório do próprio Snowflake.

2. Compute Pool

Aqui as coisas fogem do que você talvez já conheça. Um compute pool é um conjunto de instâncias de máquinas virtuais que executam um ou vários containers. Pense nele como um cluster de nós capaz de rodar diversos services ou apps.

CREATE COMPUTE POOL my_pool
  MIN_NODES = 1
  MAX_NODES = 3
  INSTANCE_FAMILY = CPU_X64_XS
  AUTO_RESUME = TRUE
  AUTO_SUSPEND_SECS = 60;

Parâmetros principais:

• MIN_NODES / MAX_NODES: quantas instâncias de VM podem rodar (essa é a sua capacidade, não a quantidade de containers). O mínimo de nós precisa ser maior que zero. O pool entra em auto-suspend caso nenhum service esteja rodando.
• INSTANCE_FAMILY: o tamanho/tipo da VM (CPU_X64_S, CPU_X64_M, GPU_NV_S etc.)
• AUTO_RESUME: se o pool inicia automaticamente quando necessário
• AUTO_SUSPEND_SECS: por quanto tempo aguardar antes de suspender um pool ocioso sem services rodando.

3. Service

Um service é a aplicação em container em execução. Ele define qual imagem rodar, quantas instâncias (containers) iniciar e como direcionar o tráfego para elas.

-- código mínimo necessário:
CREATE SERVICE my_web_app
  IN COMPUTE POOL my_pool
  FROM @specs
  SPECIFICATION_FILE = 'service.yaml';

-- propriedades mais comuns...
CREATE SERVICE my_api_service
  IN COMPUTE POOL my_pool
  FROM @specs
  SPECIFICATION_FILE = 'service.yaml'
  MIN_INSTANCES = 1
  MAX_INSTANCES = 5 -- Escala até 5 com base na CPU
  MIN_READY_INSTANCES = 1 -- Precisa de pelo menos 1 para o service estar pronto
  EXTERNAL_ACCESS_INTEGRATIONS = (api_eai, cdn_eai)

Expandir código

O service lê um arquivo de especificação YAML (armazenado em um stage) que descreve seus containers, parecido com um deployment do Kubernetes ou um arquivo Docker Compose. Veja um exemplo de SPECIFICATION_FILE.yml que o service vai ler ao iniciar:

spec:
  containers:
  - name: my_app_container
    image: /dbt_dev/my_app/repo/my_app_container:latest
    env:
      # variáveis de ambiente do seu app aqui
      ## Este app lê dados do Snowflake usando essas variáveis
      SNOWFLAKE_WAREHOUSE: COMPUTE_WH
      SNOWFLAKE_DATABASE: FIVETRAN
      SNOWFLAKE_SCHEMA: SAP_ECC
      SNOWFLAKE_ROLE: DBT_ROLE
      APP_HOST: 0.0.0.0
      APP_PORT: "8080"
    readinessProbe:
      port: 8080

Expandir código

4. External Access Integration (opcional)

Se o seu container precisa chamar APIs ou serviços externos, fora do Snowflake, você vai precisar de uma external access integration. É a forma como o Snowflake controla o acesso de rede de saída.

CREATE EXTERNAL ACCESS INTEGRATION my_api_access
  ALLOWED_NETWORK_RULES = (my_network_rule)
  ENABLED = TRUE;

Como dá para perceber, há alguns conceitos novos bem específicos desse serviço. Conhecimento geral de Snowflake ou de nuvem ajuda a dar o pontapé inicial, mas é preciso dominar esses novos termos.

Na minha opinião, o preço do SPCS é bem razoável. Sai mais caro do que os serviços de containers tradicionais (ECS, Cloud Run, ACI), mas os benefícios adicionais da governança do Snowflake e da proximidade dos dados costumam compensar. Veja as cobranças associadas ao SPCS.

Compute Pools

O principal componente de cobrança do SPCS são os compute pools. À primeira vista, o SPCS parece bem acessível. Um Extra Small custa apenas 0,06 Credits por hora. A US$ 3 por crédito, um XS sai por US$ 4,32 por dia ou US$ 1.576 por ano. Hardware similar no Cloud Run custaria pouco menos de US$ 3 / dia. Ou seja, o SPCS é mais caro, mas tem os benefícios adicionais que comentamos.

Quando um compute pool é retomado, a cobrança mínima é de 5 minutos.

Comparação com os custos dos Virtual Warehouses do Snowflake

Em comparação com os virtual warehouses do Snowflake, o menor tamanho de warehouse custa 1 crédito por hora. O SPCS oferece uma alternativa bem mais barata para tarefas leves, como rodar scripts Python ou hospedar notebooks. Como mostrado acima, dá para rodar um compute node por 6% do custo total de um virtual warehouse XS!

Custos de armazenamento

Armazenamento é barato, e o SPCS não consome muito storage, mas vale ficar de olho nesse aspecto. Veja as formas pelas quais você pode ser cobrado por armazenamento:

• Image Repository: é implementado como um stage, então valem as tarifas padrão de storage.
• Block volumes para containers: armazenam o estado da sua aplicação, parecido com AWS EBS ou Google Persistent Disk. Esse é o aspecto mais caro em termos de armazenamento, variando de cerca de US$ 82 a US$ 100 por TB por mês.
• Logging na event table do Snowflake (storage padrão)
• Qualquer outro stage / tabela usado pelo seu app (storage padrão)

É aqui que muita gente que está começando (inclusive eu) se surpreende. Se você está acostumado com Cloud Run, AWS Lambda, ECS ou plataformas similares de containers "serverless", talvez espere que o service desligue automaticamente quando ninguém está usando. Mas não desliga.

A realidade dos custos do SPCS

Ben Franklin dizia: "A experiência é a melhor professora, mas o tolo não aprende com nenhuma outra." Infelizmente, aprendi o que vem a seguir na marra, então espero que você consiga aprender com meus erros!

Os compute pools têm AUTO_SUSPEND_SECS, mas isso só se aplica quando o pool está vazio. Se houver um service rodando no compute pool, o pool continua ativo. Definir AUTO_SUSPEND_SECS = 60 no seu compute pool não suspende o pool se um service estiver rodando, e services não se suspendem sozinhos.

Por padrão, os services rodam 24/7. Quando você cria um service com MIN_INSTANCES = 1 (0 não é permitido), o Snowflake mantém um container rodando o tempo todo. Isso significa que você paga por compute 24/7 até suspender o service explicitamente. Diferente do Cloud Run, ele não escala para zero quando ninguém está usando. A propriedade auto_suspend_secs do service é um recurso em preview; ela funciona para apps internos que não têm endpoints públicos, como Service Functions e comunicações Service to Service. Mas, para apps web rodando em containers, eles não vão fazer auto-suspend quando ociosos. O Snowflake só rastreia chamadas internas a service functions para determinar inatividade, e não tráfego HTTP de entrada.

Como dito acima, ainda é acessível por causa da baixa taxa de consumo de créditos, mesmo deixando rodar 24x7 (US$ 4,32 / dia considerando US$ 3 / crédito e XS). É só algo para ficar de olho, já que foi uma surpresa para mim.

A dança da suspensão em dois passos

Para o compute pool fazer auto-suspend, é preciso primeiro suspender o service:

-- Passo 1: Suspenda o service
ALTER SERVICE my_app SUSPEND;

-- Passo 2: Agora o AUTO_SUSPEND_SECS entra em ação se você esperar
-- OU você pode forçar imediatamente:
ALTER COMPUTE POOL my_pool SUSPEND;
-- dá para suspender o compute pool sozinho, o que vai suspender o service.

Auto-resume funciona (mas só para services)

O lado bom: embora os services não façam auto-suspend, eles fazem auto-resume quando alguém acessa o endpoint — mas só se você habilitar:

ALTER SERVICE my_app SET AUTO_RESUME = TRUE;

-- Agora:
-- 1. Você suspende o service manualmente
-- 2. Alguém acessa o endpoint do seu service
-- 3. O service acorda automaticamente
-- 4. O compute pool retoma automaticamente (porque AUTO_RESUME = TRUE no pool)

Estratégias de gestão de custos para o Snowpark Container Services

Diante dessas limitações, veja abordagens práticas caso você não queira que seu app rode 24x7:

1. Suspend/Resume manual (melhor para Dev/Teste)

-- Quando terminar o trabalho:
ALTER SERVICE my_app SUSPEND;

-- O service vai fazer auto-resume quando alguém acessá-lo
-- É manual, mas confiável

2. Tasks agendadas (boa para uso previsível)

-- Suspende toda noite às 18h
CREATE TASK suspend_service_nightly
  SCHEDULE = 'USING CRON 0 18 * * * America/New_York'
AS
  ALTER SERVICE my_app SUSPEND;

-- vai fazer auto-resume quando alguém usar de novo.

3. Monitorar e alertar (essencial para produção)

-- comandos show não rodam em um warehouse
SHOW SERVICES;

-- Se quiser usar SQL para cálculos e filtragem...
SELECT
  service_name,
  status,
  compute_pool_name,
  current_instances,
  DATEDIFF('hour', last_resumed, CURRENT_TIMESTAMP()) as hours_running
FROM INFORMATION_SCHEMA.SERVICES
WHERE status = 'RUNNING';

Acessando URLs de SPCS suspensos

Quando o service está suspenso, o usuário vai se deparar com este erro ao acessar a URL:

{
  "responseType": "ERROR",
  "requestId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "detail": "Service EXAMPLE_SERVICE not reachable: no service hosts found."
}

Desde que o service e o compute pool tenham auto-resume habilitado, eles começam a subir quando o usuário tenta acessar a URL. Leva cerca de 39 a 60 segundos, e depois é só atualizar a página. A experiência não é das melhores, mas também não é péssima, desde que os usuários saibam o que esperar.

Como os Compute Pools do SPCS têm um custo por crédito bem menor, dá para aproveitar isso como uma forma muito mais barata de rodar batch jobs em Python (ou em qualquer linguagem) no Snowflake. Digamos que você tenha um job Python em container, com push feito para um registry do Snowflake, e um arquivo YAML que descreve o service enviado para um Stage. Aí basta executar um comando execute job service ... para rodar o código nesse container. Esses services se desligam quando terminam, permitindo que o Compute Pool faça auto-suspend normalmente. É um truque bacana para aproveitar compute mais barato no Snowflake!

EXECUTE JOB SERVICE
  IN COMPUTE POOL my_compute_pool
  NAME = my_batch_job
  FROM @my_stage
  SPEC = 'job_spec.yaml';

A interface do Snowsight oferece uma forma prática de acompanhar o gasto com SPCS. Usando a role accountadmin (ou outra com permissão para monitorar uso), vá em Admin → Cost Management → Consumption e mude o filtro Service Type para SPCS.

✅ Crie uma role dedicada para gerenciamento de containers

✅ Configure database, schema, image repository e stage

✅ Configure a external access integration se for chamar APIs externas

✅ Crie o compute pool com tamanho e configurações de auto-suspend adequados

✅ Faça upload da especificação do service para o stage

✅ Crie o service com AUTO_RESUME = TRUE

✅ Documente os procedimentos de suspensão manual ou crie tasks agendadas

✅ Configure queries de monitoramento para acompanhar services em execução e custos

✅ Teste o ciclo de suspend/resume antes de implantar em produção

O Snowpark Container Services traz o poder das aplicações em containers direto para os seus dados no Snowflake. Mas existe uma curva de aprendizado: é preciso entender image repositories, compute pools, services e o comportamento que conecta tudo isso. Depois de dominar esses blocos de construção e as peculiaridades de gestão de custos, dá para criar aplicações de dados poderosas que rodam ao lado dos seus dados, sem nunca sair da plataforma Snowflake.

Jeff é Consultor de Data e Analytics com mais de 15 anos de experiência em automatizar insights e usar dados para controlar processos de negócio. Do ponto de vista tecnológico, é especialista em Snowflake + dbt + Tableau. Em áreas de negócio, tem experiência em Serviços Públicos, Ensaios Clínicos, Editorial, Bens de Consumo (CPG) e Manufatura. Fique à vontade para entrar em contato a qualquer momento: [email protected].