Snowpark Container Services : utilisation des tâches¶

Créer plusieurs instances de service et configurer la mise à l’échelle automatique¶

Par défaut, Snowflake exécute une instance du service dans le pool de calcul spécifié. Pour gérer des charges de travail importantes, vous pouvez exécuter plusieurs instances de service en définissant les propriétés MIN_INSTANCES et MAX_INSTANCES, qui spécifient le nombre minimum d’instances du service au début et le nombre maximum d’instances que Snowflake peut ajouter en cas de besoin.

Exemple

CREATE SERVICE echo_service
   IN COMPUTE POOL tutorial_compute_pool
   FROM @tutorial_stage
   SPECIFICATION_FILE='echo_spec.yaml'
   MIN_INSTANCES=2
   MAX_INSTANCES=4;

Lorsque plusieurs instances de service sont en cours d’exécution, Snowflake fournit automatiquement un équilibreur de charge pour répartir les requêtes entrantes.

Pour configurer Snowflake afin qu’il évalue automatiquement le nombre d’instances de service en cours d’exécution, procédez comme suit :

1. Spécifiez les exigences en matière de mémoire et de CPU pour votre instance de service dans le fichier de spécification du service. Pour plus d’informations, voir le champ container.resources.

   Exemple

   resources:
     requests:
      memory: <memory-reserved>
      cpu: <cpu-units>
   

   Copy

2. Lors de l’exécution de la commande CREATE SERVICE, définissez les paramètres MIN_INSTANCES et MAX_INSTANCES. Vous pouvez également utiliser ALTER SERVICE pour modifier ces valeurs.

Snowflake commence par créer le nombre minimum d’instances de service sur le pool de calcul spécifié, puis augmente automatiquement le nombre d’instances en fonction des besoins. Snowflake utilise un seuil de 80 % (pour le CPU et la mémoire) afin d’augmenter ou de réduire le nombre d’instances de service.

À tout moment, une ou plusieurs instances de service peuvent être en cours d’exécution sur le pool de calcul spécifié. Snowflake surveille en permanence l’utilisation des ressources (mémoire ou CPU) dans le pool de calcul, en agrégeant les données d’utilisation de toutes les instances de service en cours d’exécution.

Lorsque l’utilisation agrégée des ressources (pour toutes les instances de service) dépasse 80 %, Snowflake déploie une instance de service supplémentaire dans le pool de calcul. Si l’utilisation des ressources agrégées tombe en dessous de 80 %, Snowflake procède à une diminution en supprimant une instance de service en cours d’exécution. Snowflake utilise une fenêtre de stabilisation de cinq minutes pour éviter les mises à l’échelle fréquentes.

Notez les comportements de mise à l’échelle suivants :

• La mise à l’échelle des instances de service est limitée par les paramètres MIN_INSTANCES et MAX_INSTANCES configurés pour le service.

• Si une mise à l’échelle est nécessaire et que les nœuds du pool de calcul n’ont pas la capacité de ressources nécessaire pour démarrer une autre instance de service, la mise à l’échelle automatique du pool de calcul peut être déclenchée. Pour plus d’informations, voir Mise à l’échelle automatique des nœuds d’un pool de calcul.

• Si vous spécifiez les paramètres MAX_INSTANCES et MIN_INSTANCES lors de la création d’un service, mais que vous ne spécifiez pas les exigences en matière de mémoire et de CPU pour votre instance de service dans le fichier de spécification du service, aucune mise à l’échelle automatique ne se produit ; Snowflake démarre avec le nombre d’instances spécifié par la propriété MIN_INSTANCES et ne fera pas de mise à l’échelle automatique.

Utilisation de SYSTEM$GET_SERVICE_LOGS¶

Vous fournissez le nom du service, l’ID d’instance, le nom du conteneur et, éventuellement, le nombre de lignes de journal les plus récentes à récupérer. Si une seule instance de service est en cours d’exécution, l’ID d’instance de service est 0. Par exemple, la commande GET_SERVICE_LOGS suivante récupère les 10 dernières lignes du journal d’un conteneur nommé echo qui appartient à l’instance 0 d’un service nommé echo_service :

CALL SYSTEM$GET_SERVICE_LOGS('echo_service', '0', 'echo', 10);

Si vous ne connaissez pas les informations sur le service (comme l’ID d’instance ou le nom du conteneur), vous pouvez d’abord exécuter GET_SERVICE_STATUS pour obtenir des informations sur les instances de service et les conteneurs en cours d’exécution dans chaque instance.

Exemple de sortie :

+--------------------------------------------------------------------------+
| SYSTEM$GET_SERVICE_LOGS                                                  |
|--------------------------------------------------------------------------|
| 10.16.6.163 - - [11/Apr/2023 21:44:03] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:08] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:13] "GET /healthcheck HTTP/1.1" 200 - |
| 10.16.6.163 - - [11/Apr/2023 21:44:18] "GET /healthcheck HTTP/1.1" 200 - |
+--------------------------------------------------------------------------+
1 Row(s) produced. Time Elapsed: 0.878s

La sortie SYSTEM$GET_SERVICE_LOGS a les limitations suivantes :

• Elle fusionne simplement les flux de sortie et d’erreur standard, ce qui rend impossible la distinction entre les messages de sortie normaux et d’erreur.

• Elle rapporte les données capturées pour un conteneur spécifique dans une instance de service unique.

• Elle ne signale que les journaux d’un conteneur en cours d’exécution. La fonction ne peut pas récupérer les journaux d’un conteneur précédent qui a été redémarré ou d’un conteneur d’un service qui est arrêté ou supprimé.

• La fonction renvoie jusqu’à 100 KB de données.

Utilisation d’une table d’événements¶

Snowflake peut capturer et enregistrer la sortie standard et les erreurs standard de vos conteneurs dans la table d’événements configurée pour votre compte. Pour plus d’informations, voir Vue d’ensemble de la journalisation et du traçage.

Par exemple, la requête SELECT suivante récupère les événements de services et de tâches Snowflake enregistrés au cours de l’heure écoulée :

SELECT TIMESTAMP, RESOURCE_ATTRIBUTES, RECORD_ATTRIBUTES, VALUE
FROM <current-event-table-for-your-account>
WHERE timestamp > dateadd(hour, -1, current_timestamp())
AND RESOURCE_ATTRIBUTES:"snow.executable.type" = 'SnowparkContainers'
ORDER BY timestamp DESC
LIMIT 10;

Snowflake recommande d’inclure un horodatage dans la clause WHERE des requêtes de tables d’événements, comme le montre cet exemple. Ceci est particulièrement important en raison du volume potentiel de données générées par les différents composants de Snowflake. En appliquant des filtres, vous pouvez extraire un sous-ensemble de données plus restreint, ce qui améliore les performances de la requête.

Vous contrôlez le niveau des journaux (tous, erreurs uniquement ou aucun) que vous souhaitez conserver dans une table d’événements en utilisant le champ spec.logExporters dans le fichier de spécification du service.

La table d’événements comprend les colonnes suivantes, qui fournissent des informations utiles sur les journaux collectés par Snowflake depuis votre conteneur :

• TIMESTAMP : indique quand Snowflake a collecté le journal.

• RESOURCE_ATTRIBUTES : chaque objet de cette colonne identifie le service Snowflake et le conteneur du service qui a généré le journal. Par exemple, il fournit des détails tels que le nom du service, le nom du conteneur et le nom du pool de calcul qui ont été spécifiés lors de l’exécution du service.

  {
  "snow.containers.compute_pool.id": 549816068,
  "snow.containers.compute_pool.name": "TUTORIAL_COMPUTE_POOL",
  "snow.containers.container.name": "echo",
  "snow.containers.instance.name": "0",
  "snow.containers.restart.id": "cd0cf2",
  "snow.database.id": 549816076,
  "snow.database.name": "TUTORIAL_DB",
  "snow.executable.id": 980991015,
  "snow.executable.name": "ECHO_SERVICE",
  "snow.executable.type": "SnowparkContainers",
  "snow.schema.id": 549816076,
  "snow.schema.name": "DATA_SCHEMA"
  }
  

  Copy

• RECORD_ATTRIBUTES : pour un service Snowflake, il identifie une source d’erreur (sortie standard ou erreur standard).

  { "log.iostream": "stdout" }
  

  Copy

• VALUE : la sortie standard et l’erreur standard sont divisées en lignes, et chaque ligne génère un enregistrement dans la table d’événements.

  "echo-service [2023-10-23 17:52:27,429] [DEBUG] Sending response: {'data': [[0, 'Joe said hello!']]}"
  

Fonctions de service : utilisation d’un service à partir d’une requête SQL¶

Une fonction de service est une fonction définie par l’utilisateur (UDF) que vous créez à l’aide de CREATE FUNCTION. Cependant, au lieu d’écrire directement le code de l’UDF, vous associez l’UDF à votre service. Par exemple, dans le tutoriel 1, vous créez un service nommé echo_service qui expose un point de terminaison (echoendoint) tel que défini dans la spécification du service :

spec:
…
  endpoints:
  - name: echoendpoint
    port: 8080

echoendpoint est un nom de point de terminaison convivial qui représente le port correspondant (8080). Pour communiquer avec ce point de terminaison de service, vous créez une fonction de service en fournissant les paramètres SERVICE et ENDPOINT comme indiqué :

CREATE FUNCTION my_echo_udf (text varchar)
   RETURNS varchar
   SERVICE=echo_service
   ENDPOINT=echoendpoint
   AS '/echo';

Le paramètre AS fournit le chemin HTTP vers le code de service. Vous obtenez cette valeur de chemin à partir du code du service (par exemple, voir service.py dans le tutoriel 1).

@app.post("/echo")
def echo():
...

Lorsque vous invoquez la fonction de service, Snowflake dirige la requête vers le point de terminaison et le chemin du service associé.

Lorsque vous exécutez plusieurs instances de votre service, vous pouvez créer une fonction de service en spécifiant le paramètre facultatif MAX_BATCH_ROWS pour limiter la taille du lot, c’est-à-dire le nombre maximum de lignes que Snowflake envoie par lot au service. Par exemple, supposons que MAX_BATCH_ROWS soit 10 et que vous appeliez la fonction de service my_echo_udf avec 100 lignes d’entrée. Snowflake divise les lignes d’entrée en lots, chaque lot ayant au plus 10 lignes, et envoie une série de requêtes au service avec le lot de lignes dans le corps de la requête. La configuration de la taille des lots peut être utile lorsque le traitement prend un temps non négligeable, de même que la répartition des lignes sur tous les serveurs disponibles.

Vous pouvez utiliser ALTER FUNCTION pour modifier une fonction de service. La commande ALTER FUNCTION suivante modifie le point de terminaison de service auquel elle s’associe et la taille du lot :

ALTER FUNCTION my_echo_udf(VARCHAR)
   SET SERVICE=other_service
   ENDPOINT=otherendpoint
   MAX_BATCH_ROWS=100

"Alex", "2014-01-01 16:00:00"
"Steve", "2015-01-01 16:00:00"
…

SELECT service_func(col1, col2) FROM input_table;

{
   "data":[
      [
         0,
         "Alex",
         "2014-01-01 16:00:00"
      ],
      [
         1,
         "Steve",
         "2015-01-01 16:00:00"
      ],
      …
      [
         <row_index>,
         "<column1>",
         "<column2>"
      ],
   ]
}

{
   "data":[
      [0, "a"],
      [1, "b"],
      …
      [ row_index,  output_column1]
   ]
}

USE ROLE service_owner;
GRANT USAGE ON service service_db.my_schema.my_service TO ROLE func_owner;

USE ROLE func_owner;
CREATE OR REPLACE test_udf(v VARCHAR)
  RETURNS VARCHAR
  SERVICE=service_db.my_schema.my_service
  ENDPOINT=endpointname1
  AS '/run';

SELECT test_udf(col1) FROM some_table;

ALTER FUNCTION test_udf(VARCHAR) SET
  SERVICE = service_db.other_schema.other_service
  ENDPOINT=anotherendpoint;

GRANT USAGE ON FUNCTION test_udf(varchar) TO ROLE func_user;
USE ROLE func_user;
SELECT my_test_udf('abcd');

Entrée : utilisation d’un service en dehors de Snowflake¶

Un service peut exposer un ou plusieurs points de terminaison comme étant publics pour permettre aux utilisateurs d’utiliser le service à partir du Web public.

CREATE SECURITY INTEGRATION SNOWSERVICES_INGRESS_OAUTH
TYPE=oauth
OAUTH_CLIENT=snowservices_ingress
ENABLED=true;

Marquez le point de terminaison comme public dans votre fichier de spécification de service :

spec
  ...
  endpoints
  - name: <endpoint name>
    port: <port number>
    public: true

Pour plus d’informations sur les spécifications de service, voir Référence de spécification.

Communications de service à service¶

Les services peuvent communiquer entre eux en utilisant le nom DNS que Snowflake attribue automatiquement à chaque service. Pour un exemple, voir le tutoriel 3.

Le format du nom DNS est le suivant :

<service-name>.<schema-name>.<db-name>.snowflakecomputing.internal

Utilisez SHOW SERVICES (ou DESCRIBE SERVICE) pour obtenir le nom DNS d’un service. Le nom DNS qui précède est un nom complet. Les services créés dans le même schéma peuvent communiquer en utilisant uniquement <service-name>. Les services qui se trouvent dans la même base de données, mais dans des schémas différents doivent fournir le nom du schéma, par exemple <service-name>.<schema-name>.

Snowflake autorise les communications réseau entre les services créés par le même rôle et bloque les communications réseau entre les services créés par des rôles différents. Si vous souhaitez empêcher vos services de communiquer entre eux (pour des raisons de sécurité, par exemple), utilisez différents rôles Snowflake pour créer ces services.

Les noms DNS présentent les limitations suivantes :

• Les noms de votre base de données, de votre schéma ou de votre service doivent être des étiquettes DNS valides. (Voir aussi https://www.ietf.org/rfc/rfc1035.html#section-2.3.1). Sinon, la création d’un service échouera.

• Snowflake remplace le trait de soulignement (_) dans les noms (base de données, schéma et nom de service) par un tiret (-) dans le nom DNS.

• Après avoir créé un service, ne modifiez pas le nom de la base de données ou du schéma, car Snowflake ne mettra pas à jour le nom DNS du service.

• Un nom DNS est uniquement destiné aux communications internes au sein de Snowflake entre les services fonctionnant dans le même compte. Il n’est pas accessible depuis Internet.