Snowpark Container Services pour les débutants : comprendre les briques et la tarification

Snowpark Container Services permet d'exécuter des applications conteneurisées directement au sein de Snowflake. C'est l'équivalent Snowflake d'AWS ECS, Google Cloud Run ou Azure Container Instances. Mais au lieu de tourner dans votre compte cloud, vos conteneurs s'exécutent dans l'environnement de calcul de Snowflake et disposent d'un accès natif à vos données Snowflake.

Le gros avantage : vos conteneurs peuvent directement interroger les tables Snowflake, appeler des fonctions Snowflake et accéder à vos données sans avoir à créer de compte de service, gérer des identifiants ou sortir les données de la plateforme. De plus, les utilisateurs de votre application obtiennent un accès via une simple instruction GRANT : pas besoin de développer une couche d'authentification ni de gérer des utilisateurs/mots de passe, etc. J'ai récemment déployé une application conteneurisée pour un client AWS / Snowflake, qui a choisi SPCS plutôt qu'ECS parce que la gestion des utilisateurs et de la sécurité y est nettement plus simple.

De nombreux articles présentent des exemples de déploiement d'applications dans Snowpark Container Services. Ici, nous nous concentrerons surtout sur les briques de base (la terminologie), la tarification et quelques nuances ou différences par rapport aux services de conteneurs traditionnels.

Voyons les quatre principaux objets que vous allez manipuler :

1. Image Repository

C'est le registre de conteneurs de Snowflake, équivalent de Docker Hub ou d'Amazon ECR. Vous y poussez vos images Docker, et Snowflake les récupère au démarrage de vos services.

1CREATE IMAGE REPOSITORY my_app_repo;

Snowpark Container Services ne tire pas directement les images de conteneurs depuis des registres externes comme Docker Hub. Vous pouvez utiliser des images de base publiques pour le build local, mais avant de déployer sur Snowflake, vous devez pousser l'image finale dans un Image Repository Snowflake au sein de votre compte. Les services ne peuvent exécuter que des images stockées dans le registre interne de Snowflake.

2. Compute Pool

C'est ici que les choses divergent de ce que vous connaissez peut-être. Un compute pool est un ensemble d'instances de machines virtuelles qui exécutent un ou plusieurs conteneurs. Voyez-le comme votre cluster de nœuds capable de faire tourner plusieurs services ou applications.

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

Paramètres clés :

• MIN_NODES / MAX_NODES : nombre d'instances VM pouvant tourner (il s'agit de votre capacité, pas de vos conteneurs). Le nombre minimum de nœuds doit être supérieur à zéro. Le pool se met automatiquement en pause si aucun service ne tourne.
• INSTANCE_FAMILY : la taille/le type de VM (CPU_X64_S, CPU_X64_M, GPU_NV_S, etc.)
• AUTO_RESUME : indique si le pool démarre automatiquement à la demande
• AUTO_SUSPEND_SECS : durée d'attente avant la mise en pause d'un pool inactif sur lequel aucun service ne tourne.

3. Service

Un service correspond à l'application conteneurisée en cours d'exécution. Il définit l'image à exécuter, le nombre d'instances (conteneurs) à lancer et la façon de router le trafic vers celles-ci.

-- code minimum requis :
CREATE SERVICE my_web_app
  IN COMPUTE POOL my_pool
  FROM @specs
  SPECIFICATION_FILE = 'service.yaml';

-- propriétés plus courantes...
CREATE SERVICE my_api_service
  IN COMPUTE POOL my_pool
  FROM @specs
  SPECIFICATION_FILE = 'service.yaml'
  MIN_INSTANCES = 1
  MAX_INSTANCES = 5 -- Monte jusqu'à 5 selon la charge CPU
  MIN_READY_INSTANCES = 1 -- Au moins 1 nécessaire pour que le service soit prêt
  EXTERNAL_ACCESS_INTEGRATIONS = (api_eai, cdn_eai)

Déplier le code

Le service lit un fichier de spécification YAML (stocké dans un stage) qui décrit vos conteneurs, à la manière d'un déploiement Kubernetes ou d'un fichier Docker Compose. Voici un exemple de SPECIFICATION_FILE.yml que le service lira au démarrage :

spec:
  containers:
  - name: my_app_container
    image: /dbt_dev/my_app/repo/my_app_container:latest
    env:
      # variables d'environnement de votre app ici
      ## Cette app lit les données de Snowflake via ces variables
      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

Déplier le code

4. External Access Integration (facultatif)

Si votre conteneur doit appeler des API ou services en dehors de Snowflake, il vous faut une External Access Integration. C'est le mécanisme par lequel Snowflake contrôle l'accès réseau sortant.

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

Comme vous le voyez, certains concepts sont vraiment spécifiques à ce service. Une bonne connaissance de Snowflake ou du cloud vous donnera une longueur d'avance, mais il faudra vous approprier ces nouveaux termes.

La tarification de SPCS est, à mon avis, tout à fait raisonnable. Elle reste plus élevée que celle des services de conteneurs classiques (ECS, Cloud Run, ACI), mais les avantages liés à la gouvernance Snowflake et à la proximité des données justifient souvent ce surcoût. Voici les différents frais associés à SPCS.

Compute Pools

Le principal poste de facturation de SPCS, ce sont les compute pools. En apparence, SPCS paraît très abordable. Un Extra Small ne coûte que 0,06 crédit par heure. À 3 $ le crédit, un XS revient à 4,32 $ par jour ou 1576 $ par an. Un matériel équivalent sur Cloud Run coûterait un peu moins de 3 $/jour. SPCS est donc plus cher, mais offre les avantages évoqués précédemment.

Lorsqu'un compute pool reprend, vous êtes facturé pour un minimum de 5 minutes.

Comparaison avec le coût des Virtual Warehouses Snowflake

Côté virtual warehouses Snowflake, la plus petite taille coûte 1 crédit par heure. SPCS offre une alternative bien plus économique pour des tâches légères comme l'exécution de scripts Python ou l'hébergement de notebooks. Comme indiqué plus haut, vous pouvez faire tourner un nœud de calcul pour 6 % du coût total d'un virtual warehouse XS !

Coûts de stockage

Le stockage est bon marché et SPCS n'en consomme pas énormément, mais autant garder cet aspect en tête. Voici les différents postes de facturation possibles pour le stockage :

• Image Repository : implémenté sous forme de stage, donc les tarifs de stockage standard s'appliquent.
• Volumes de blocs pour les conteneurs : ils stockent l'état de votre application, à la manière d'AWS EBS ou de Google Persistent Disk. C'est le poste le plus coûteux en matière de stockage, avec un tarif d'environ 82 à 100 $ par To et par mois.
• Journalisation dans l'event table de Snowflake (stockage standard)
• Tout autre stage / table utilisé par votre application (stockage standard)

C'est ici que beaucoup de débutants (moi y compris) sont pris de court. Si vous avez l'habitude de Cloud Run, AWS Lambda, ECS ou d'autres plateformes de conteneurs dites \"serverless\", vous pourriez vous attendre à ce que votre service s'arrête tout seul quand plus personne ne l'utilise. Ce n'est pas le cas.

La réalité des coûts SPCS

Ben Franklin disait : \"L'expérience est la meilleure école, mais le sot n'apprend nulle part ailleurs.\" J'ai malheureusement appris ce qui suit à la dure ; profitez de mes erreurs !

Les compute pools disposent d'AUTO_SUSPEND_SECS, mais ce paramètre ne s'applique que lorsque le pool est vide. Si un service tourne sur le compute pool, le pool reste actif. Définir AUTO_SUSPEND_SECS = 60 sur votre compute pool ne le mettra pas en pause tant qu'un service y tourne, et les services ne se mettent pas en pause d'eux-mêmes.

Par défaut, les services tournent 24/7. Quand vous créez un service avec MIN_INSTANCES = 1 (0 n'est pas autorisé), Snowflake maintient un conteneur actif en permanence. Autrement dit, vous payez du calcul 24/7 jusqu'à ce que vous suspendiez explicitement le service. Contrairement à Cloud Run, il ne descend pas à zéro lorsque personne ne l'utilise. La propriété auto_suspend_secs du service est une fonctionnalité en preview ; elle fonctionnera pour des applications internes sans endpoints publics, comme les Service Functions et les communications Service to Service. Mais pour les applications web tournant dans des conteneurs, elles ne se mettront pas automatiquement en pause à l'inactivité. Snowflake ne suit que les appels internes de service functions pour évaluer l'inactivité, et non le trafic HTTP entrant.

Comme indiqué plus haut, cela reste abordable grâce au faible taux de consommation de crédits, même en laissant tourner 24x7 (4,32 $/jour avec 3 $/crédit et un XS). C'est simplement un point à surveiller, car cela m'a moi-même surpris.

La mise en pause en deux temps

Pour que le compute pool se mette en pause automatiquement, vous devez d'abord suspendre le service :

-- Étape 1 : suspendre le service
ALTER SERVICE my_app SUSPEND;

-- Étape 2 : maintenant AUTO_SUSPEND_SECS s'activera si vous patientez
-- OU vous pouvez le forcer immédiatement :
ALTER COMPUTE POOL my_pool SUSPEND;
-- vous pouvez suspendre le compute pool seul, ce qui suspendra le service.

L'auto-resume fonctionne (mais uniquement pour les services)

Bonne nouvelle : même si les services ne se mettent pas en pause automatiquement, ils reprennent automatiquement dès que quelqu'un accède à leur endpoint — à condition d'avoir activé l'option :

ALTER SERVICE my_app SET AUTO_RESUME = TRUE;

-- Désormais :
-- 1. Vous suspendez le service manuellement
-- 2. Quelqu'un sollicite l'endpoint de votre service
-- 3. Le service se réveille automatiquement
-- 4. Le compute pool reprend automatiquement (car AUTO_RESUME = TRUE sur le pool)

Stratégies de gestion des coûts pour Snowpark Container Services

Compte tenu de ces limites, voici quelques approches concrètes si vous ne souhaitez pas laisser votre application tourner 24x7 :

1. Suspendre/reprendre manuellement (idéal en dev/test)

-- Quand vous avez fini de travailler :
ALTER SERVICE my_app SUSPEND;

-- Le service reprendra automatiquement quand quelqu'un y accède
-- C'est manuel, mais fiable

2. Tâches planifiées (idéal pour un usage prévisible)

-- Suspendre tous les soirs à 18h
CREATE TASK suspend_service_nightly
  SCHEDULE = 'USING CRON 0 18 * * * America/New_York'
AS
  ALTER SERVICE my_app SUSPEND;

-- il reprendra automatiquement à la prochaine utilisation.

3. Surveiller et alerter (indispensable en production)

-- les commandes show ne s'exécutent pas sur un warehouse
SHOW SERVICES;

-- Si vous souhaitez utiliser SQL pour calculer et filtrer...
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';

Accéder à une URL SPCS suspendue

Quand le service est suspendu, l'utilisateur tombe sur cette erreur en visitant l'URL :

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

Tant que l'auto-resume est activé sur le service et le compute pool, ils démarrent dès que l'utilisateur tente d'accéder à l'URL. Cela prend environ 39 à 60 secondes, après quoi il pourra rafraîchir la page. L'expérience n'est pas idéale, mais reste acceptable si les utilisateurs sont prévenus.

Comme les compute pools SPCS ont un coût par crédit bien plus faible, on peut en tirer parti pour exécuter à moindre coût des jobs batch en Python (ou dans tout autre langage) au sein de Snowflake. Imaginons que vous ayez un job Python conteneurisé et poussé dans un registre Snowflake, ainsi qu'un fichier YAML décrivant le service poussé dans un stage. Vous pouvez alors lancer la commande execute job service ... pour exécuter le code dans ce conteneur. Ces services s'arrêtent une fois terminés, ce qui permet au compute pool de se mettre en pause normalement. Une belle astuce pour exploiter du calcul moins cher dans Snowflake !

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

L'interface Snowsight offre un moyen pratique de suivre les dépenses SPCS. Avec le rôle accountadmin ou un rôle disposant d'un accès au suivi de la consommation, rendez-vous dans Admin → Cost Management → Consumption, puis changez le filtre Service Type en SPCS.

✅ Créer un rôle dédié à la gestion des conteneurs

✅ Mettre en place la base de données, le schéma, l'image repository et le stage

✅ Configurer une external access integration si vous appelez des API externes

✅ Créer un compute pool avec une taille et des paramètres d'auto-suspend adaptés

✅ Téléverser la spécification du service dans le stage

✅ Créer le service avec AUTO_RESUME = TRUE

✅ Documenter les procédures de suspension manuelle ou créer des tâches planifiées

✅ Mettre en place des requêtes de monitoring pour suivre les services en cours et les coûts

✅ Tester le cycle suspend/resume avant de déployer en production

Snowpark Container Services rapproche la puissance des applications conteneurisées directement de vos données dans Snowflake. Mais il y a une courbe d'apprentissage : il faut comprendre les image repositories, les compute pools, les services et leurs interactions. Une fois ces briques et les subtilités de gestion des coûts maîtrisées, vous pouvez bâtir des applications data puissantes qui s'exécutent au plus près de vos données, sans jamais quitter la plateforme Snowflake.

Jeff est consultant Data et Analytics, fort de plus de 15 ans d'expérience dans l'automatisation des insights et l'exploitation des données pour piloter les processus métier. Côté technologie, il est spécialisé dans Snowflake + dbt + Tableau. Côté métier, il a travaillé dans les services publics, les essais cliniques, l'édition, les biens de grande consommation et l'industrie manufacturière. N'hésitez pas à le contacter, [email protected].