Snowpark Container Services: guida pratica a componenti e prezzi

Snowpark Container Services consente di eseguire applicazioni containerizzate direttamente all'interno di Snowflake. È l'equivalente Snowflake di AWS ECS, Google Cloud Run o Azure Container Instances. La differenza è che, invece di girare nel suo account cloud, i container vengono eseguiti nell'ambiente di calcolo di Snowflake con accesso nativo ai suoi dati Snowflake.

Il vantaggio principale è che i container possono interrogare direttamente le tabelle Snowflake, richiamare le funzioni Snowflake e accedere ai dati senza dover creare un service account, gestire credenziali di accesso o spostare i dati al di fuori della piattaforma. Inoltre, gli utenti della sua app riceveranno l'accesso tramite una semplice istruzione grant: non dovrà sviluppare software di autenticazione né gestire utenti, password e così via. Di recente ho rilasciato un'app containerizzata per un cliente AWS / Snowflake, che ha scelto SPCS al posto di ECS proprio per la maggiore semplicità nella gestione di utenti e sicurezza.

Esistono molti articoli con esempi di deployment di app su Snowpark Container Services. Qui ci concentreremo soprattutto sui componenti fondamentali (terminologia), sui prezzi e su alcune sfumature o differenze rispetto ai servizi container tradizionali.

Vediamo i quattro oggetti principali con cui dovrà lavorare:

1. Image Repository

È il container registry di Snowflake, analogo a Docker Hub o Amazon ECR. Qui carica le sue immagini Docker e Snowflake le preleva all'avvio dei service.

1CREATE IMAGE REPOSITORY my_app_repo;

Snowpark Container Services non preleva le immagini container direttamente da registry esterni come Docker Hub. Può usare immagini di base pubbliche durante la build in locale, ma prima del deployment su Snowflake deve caricare l'immagine finale in un image repository Snowflake all'interno del suo account. I service possono eseguire solo immagini archiviate nel repository di Snowflake.

2. Compute Pool

Qui le cose iniziano a discostarsi da ciò che conosce. Un compute pool è un insieme di istanze di macchine virtuali che eseguono uno o più container. Lo immagini come un cluster di nodi in grado di ospitare diversi service o app.

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

Parametri principali:

• MIN_NODES / MAX_NODES: quante istanze VM possono essere eseguite (è la capacità, non il numero di container). Min nodes deve essere maggiore di zero. Il pool si sospende in automatico se non sono in esecuzione service.
• INSTANCE_FAMILY: dimensione/tipo di VM (CPU_X64_S, CPU_X64_M, GPU_NV_S, ecc.)
• AUTO_RESUME: indica se il pool si avvia in automatico quando serve
• AUTO_SUSPEND_SECS: tempo di attesa prima di sospendere un pool inattivo senza service in esecuzione.

3. Service

Un service è l'applicazione containerizzata in esecuzione. Definisce quale immagine eseguire, quante istanze (container) avviare e come instradare il traffico verso di esse.

-- codice minimo richiesto:
CREATE SERVICE my_web_app
  IN COMPUTE POOL my_pool
  FROM @specs
  SPECIFICATION_FILE = 'service.yaml';

-- proprietà più comuni...
CREATE SERVICE my_api_service
  IN COMPUTE POOL my_pool
  FROM @specs
  SPECIFICATION_FILE = 'service.yaml'
  MIN_INSTANCES = 1
  MAX_INSTANCES = 5 -- Scala fino a 5 in base alla CPU
  MIN_READY_INSTANCES = 1 -- Ne serve almeno 1 perché il service sia pronto
  EXTERNAL_ACCESS_INTEGRATIONS = (api_eai, cdn_eai)

Espandi codice

Il service legge un file di specifica YAML (archiviato in uno stage) che descrive i container, in modo simile a un deployment Kubernetes o a un file Docker Compose. Ecco un esempio di SPECIFICATION_FILE.yml che il service leggerà all'avvio:

spec:
  containers:
  - name: my_app_container
    image: /dbt_dev/my_app/repo/my_app_container:latest
    env:
      # variabili d'ambiente della tua app qui
      ## Questa app legge i dati da Snowflake usando queste variabili
      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

Espandi codice

4. External Access Integration (facoltativo)

Se il container deve richiamare API o service esterni a Snowflake, le serve un'external access integration. È il meccanismo con cui Snowflake controlla l'accesso di rete in uscita.

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

Come può notare, ci sono concetti nuovi e specifici di questo servizio. Una conoscenza generale di Snowflake o del cloud aiuta a partire, ma è indispensabile prendere confidenza con questi termini.

A mio parere, i prezzi di SPCS sono piuttosto ragionevoli. Risulta più costoso rispetto ai servizi container tradizionali (ECS, Cloud Run, ACI), ma i vantaggi della governance Snowflake e della vicinanza ai dati spesso giustificano la spesa. Ecco le varie voci di costo legate a SPCS.

Compute Pools

La voce principale della fatturazione SPCS sono i compute pool. A prima vista, SPCS appare molto conveniente. Un Extra Small costa appena 0,06 credit all'ora. A 3 $ per credit, un XS costa 4,32 $ al giorno o 1576 $ all'anno. Un hardware analogo su Cloud Run costerebbe poco meno di 3 $ al giorno. SPCS è quindi più caro, ma offre i vantaggi aggiuntivi di cui abbiamo parlato.

Quando un compute pool riprende l'attività, le vengono addebitati almeno 5 minuti.

Confronto con i costi dei Virtual Warehouse Snowflake

Rispetto ai virtual warehouse di Snowflake, il warehouse di dimensioni minori costa 1 credit all'ora. SPCS è un'alternativa molto più economica per attività leggere come l'esecuzione di script Python o l'hosting di notebook. Come si è visto, può eseguire un nodo di calcolo al 6% del costo totale di un virtual warehouse XS!

Costi di storage

Lo storage costa poco e SPCS non ne consuma grandi quantità, ma è bene tenerlo presente. Ecco le varie modalità di fatturazione dello storage:

• Image Repository: è implementato come uno stage, quindi si applicano le tariffe standard di storage.
• Block volume per i container: archiviano lo stato dell'applicazione, in modo simile ad AWS EBS o Google Persistent Disk. È la voce più onerosa sul fronte storage, con prezzi che vanno da circa 82 a 100 $ per TB al mese.
• Logging nella event table di Snowflake (storage standard)
• Qualsiasi altro stage / tabella usato dall'app (storage standard)

Qui molti nuovi utenti (me compreso) restano sorpresi. Se è abituato a Cloud Run, AWS Lambda, ECS o ad altre piattaforme container "serverless", potrebbe aspettarsi che il service si arresti da solo quando nessuno lo usa. Non è così.

La realtà dei costi SPCS

Ben Franklin diceva: "L'esperienza è il miglior maestro, ma uno sciocco non imparerà da nessun altro." Purtroppo ho imparato a mie spese quanto segue: spero quindi che possa evitare i miei stessi errori!

I compute pool hanno AUTO_SUSPEND_SECS, ma il parametro si applica solo quando il pool è vuoto. Se sul compute pool è in esecuzione un service, il pool resta attivo. Impostare AUTO_SUSPEND_SECS = 60 sul compute pool non lo sospende se un service è in esecuzione e i service non si sospendono da soli.

Per impostazione predefinita, i service sono attivi 24 ore su 24, 7 giorni su 7. Quando crea un service con MIN_INSTANCES = 1 (lo 0 non è ammesso), Snowflake mantiene un container costantemente in esecuzione. Significa che pagherà il calcolo 24/7 finché non sospenderà esplicitamente il service. A differenza di Cloud Run, non scala a zero quando nessuno lo utilizza. La proprietà auto_suspend_secs del service è una funzionalità in preview: funziona per app interne senza endpoint pubblici, come le Service Functions e le comunicazioni Service to Service. Per le web app in container, invece, non c'è auto-sospensione in caso di inattività. Snowflake misura l'inattività solo sulla base delle chiamate interne alle service function, non del traffico HTTP in ingresso.

Come accennato, resta comunque un costo contenuto grazie al basso consumo di credit, anche lasciando tutto attivo 24/7 (4,32 $/giorno ipotizzando 3 $/credit e un XS). È solo un aspetto a cui prestare attenzione, perché per me è stata una sorpresa.

La sospensione in due passaggi

Perché il compute pool si sospenda automaticamente, deve prima sospendere il service:

-- Passo 1: sospendere il service
ALTER SERVICE my_app SUSPEND;

-- Passo 2: ora AUTO_SUSPEND_SECS entrerà in azione se si attende
-- OPPURE è possibile forzarlo immediatamente:
ALTER COMPUTE POOL my_pool SUSPEND;
-- è possibile sospendere il compute pool da solo, il che sospenderà il service.

L'auto-resume funziona (ma solo per i service)

C'è però un lato positivo: anche se i service non si sospendono in automatico, si riattivano da soli quando qualcuno accede al loro endpoint, a patto di abilitare l'opzione:

ALTER SERVICE my_app SET AUTO_RESUME = TRUE;

-- Ora:
-- 1. Sospende manualmente il service
-- 2. Qualcuno raggiunge l'endpoint del service
-- 3. Il service si riattiva automaticamente
-- 4. Il compute pool si riattiva automaticamente (perché AUTO_RESUME = TRUE sul pool)

Strategie di gestione dei costi su Snowpark Container Services

Alla luce di questi limiti, ecco alcuni approcci pratici se non vuole tenere la sua app attiva 24/7:

1. Sospensione/ripresa manuale (ideale per Dev/Test)

-- Quando hai finito di lavorare:
ALTER SERVICE my_app SUSPEND;

-- Il service si riattiverà automaticamente quando qualcuno vi accederà
-- È manuale ma affidabile

2. Task pianificati (ottimi per utilizzi prevedibili)

-- Sospende ogni notte alle 18:00
CREATE TASK suspend_service_nightly
  SCHEDULE = 'USING CRON 0 18 * * * America/New_York'
AS
  ALTER SERVICE my_app SUSPEND;

-- si riattiverà automaticamente al prossimo utilizzo.

3. Monitoraggio e alert (essenziali in produzione)

-- i comandi show non vengono eseguiti su un warehouse
SHOW SERVICES;

-- Se vuoi usare SQL per calcoli e filtri...
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';

Accesso agli URL di service SPCS sospesi

Quando il service è sospeso, l'utente che visita l'URL vedrà questo errore:

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

Finché su service e compute pool è abilitato l'auto-resume, entrambi inizieranno ad avviarsi quando l'utente proverà l'URL. Servono circa 39-60 secondi, dopodiché basta aggiornare la pagina. È un'esperienza non ottimale, ma accettabile se gli utenti sanno cosa aspettarsi.

Poiché i Compute Pool di SPCS hanno un costo per credit molto più basso, possiamo sfruttarli come modo decisamente più economico per eseguire batch job in Python (o in qualsiasi altro linguaggio) all'interno di Snowflake. Immaginiamo di avere un job Python containerizzato e caricato in un registry Snowflake, oltre a un file YAML che descrive il service caricato in uno Stage. A quel punto basta eseguire un comando execute job service ... per lanciare il codice all'interno di quel container. Questi service si arrestano al termine, permettendo al Compute Pool di sospendersi normalmente in automatico. Un trucco utile per sfruttare risorse di calcolo più economiche su Snowflake!

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

L'interfaccia Snowsight offre un modo comodo per monitorare la spesa SPCS. Con il ruolo accountadmin o un ruolo abilitato al monitoraggio dell'utilizzo, vada in Admin → Cost Management → Consumption e imposti il filtro Service Type su SPCS.

✅ Creare un ruolo dedicato alla gestione dei container

✅ Configurare database, schema, image repository e stage

✅ Configurare l'external access integration in caso di chiamate ad API esterne

✅ Creare il compute pool con dimensioni e impostazioni di auto-suspend adeguate

✅ Caricare la specifica del service nello stage

✅ Creare il service con AUTO_RESUME = TRUE

✅ Documentare le procedure di sospensione manuale o creare task pianificati

✅ Predisporre query di monitoraggio per tracciare service in esecuzione e costi

✅ Testare il ciclo di sospensione/ripresa prima del deployment in produzione

Snowpark Container Services porta la potenza delle applicazioni containerizzate direttamente accanto ai suoi dati in Snowflake. C'è però una curva di apprendimento: serve capire image repository, compute pool, service e il modo in cui interagiscono. Una volta padroneggiati questi componenti e le particolarità della gestione dei costi, potrà costruire potenti applicazioni dati che girano accanto ai dati stessi, senza mai uscire dalla piattaforma Snowflake.

Jeff è un consulente Data & Analytics con oltre 15 anni di esperienza nell'automazione degli insight e nell'uso dei dati per governare i processi di business. Sul piano tecnologico è specializzato in Snowflake + dbt + Tableau. Sul piano dei settori, ha esperienza in Public Utility, Clinical Trials, editoria, CPG e manifatturiero. Lo contatti pure quando vuole: [email protected].