Gestion et mise à l’échelle des services¶

Comment fonctionne la mise à l’échelle automatique ?¶

Le service s’initialise avec le nombre de nœuds spécifié dans min_instances et s’adapte dynamiquement depuis votre plage définie en fonction du volume de trafic en temps réel et de l’utilisation du matériel.

Échelle à zéro (suspension automatique) : si min_instances est défini sur 0 (valeur par défaut), le service sera automatiquement suspendu si aucun trafic n’est détecté pendant 30 minutes.

Latence de la mise à l’échelle : les déclencheurs de mise à l’échelle s’activent généralement après une minute de remplissage de la condition requise. Notez que le temps de mise à l’échelle total comprend cette période de déclenchement plus le temps nécessaire pour provisionner et initialiser de nouvelles instances de service.

Bonnes pratiques en matière de configuration¶

Dans Snowsight¶

Vous pouvez surveiller les services Model Serving dans Snowsight :

1. Dans le menu de navigation, sélectionnez Surveillance » Services et tâches.

2. Dans l’onglet Services, sélectionnez votre service pour voir la page de détails du service.

3. L’onglet Aperçu affiche les informations sur le service, notamment le pool de calcul, les points de terminaison et le nombre d’instances.

4. Les onglets Journaux, Métriques et Événements fournissent des journaux, des mesures de performances et des événements de service (tels que le provisionnement et les arrêts des instances). Filtrez les résultats par instance et par nom de conteneur, selon vos besoins.

Accès aux journaux des services¶

Vous pouvez accéder aux journaux de vos services Model Serving en utilisant l’une des méthodes suivantes :

-- Retrieve logs using the service helper function
SELECT * FROM TABLE(mydb.myschema.my_model_service!SPCS_GET_LOGS())
WHERE
timestamp > dateadd(hour, -1, current_timestamp())
AND instance_id = 0  -- choose all instances or one particular
AND container_name = 'model-inference';

-- Find the event table for your account
SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;

-- Query the event table for model service logs
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.service.name" = '<model_service_name>'
    AND RECORD_TYPE = 'LOG'
    AND RESOURCE_ATTRIBUTES:"snow.service.container.instance" = '0'  -- choose all instances or one particular
    AND RESOURCE_ATTRIBUTES:"snow.service.container.name" = 'model-inference'
ORDER BY timestamp DESC
LIMIT 10;

-- Retrieve logs from a specific service instance
SELECT SYSTEM$GET_SERVICE_LOGS('model_service_name', '0', 'model-inference', 10);

Accès aux métriques de service¶

Les services Model Serving émettent des métriques de performances et de santé qui peuvent vous aider à surveiller l’utilisation des ressources, les taux de requête, la latence et d’autres caractéristiques opérationnelles. Ces métriques sont capturées dans le tableau des événements et peuvent être interrogées pour analyser les performances du service au fil du temps.

Pour plus d’informations sur les métriques de service SPCS, consultez Accès aux métriques de service du tableau des événements.

-- Retrieve metrics using the service helper function
SELECT *
FROM TABLE(mydb.myschema.my_model_service!SPCS_GET_METRICS())
WHERE
timestamp > dateadd(hour, -1, current_timestamp())
AND instance_id = 0  -- choose all instances or one particular
AND container_name = 'model-inference';

-- Find the event table for your account
SHOW PARAMETERS LIKE 'event_table' IN ACCOUNT;

-- Query the event table for model service metrics
SELECT
    timestamp,
    RESOURCE_ATTRIBUTES:"snow.service.container.instance" as instance,
    RESOURCE_ATTRIBUTES:"snow.service.container.name" as container,
    RECORD:metric:"name" as metric,
    value
FROM my_event_table_db.my_event_table_schema.my_event_table
WHERE timestamp > DATEADD(hour, -1, CURRENT_TIMESTAMP())
    AND RESOURCE_ATTRIBUTES:"snow.service.name" = '<model_service_name>'
    AND RECORD_TYPE = 'METRIC'
    AND RESOURCE_ATTRIBUTES:"snow.service.container.instance" = '0'  -- choose all instances or one particular
    AND RESOURCE_ATTRIBUTES:"snow.service.container.name" = 'model-inference'
ORDER BY timestamp DESC
LIMIT 100;

Résilience face aux échecs de nœuds¶

Pour tolérer les échecs de nœuds standard, Snowflake recommande un sur-provisionnement de 50 % ou le maintien d’un minimum de 3 instances (la valeur la plus élevée étant retenue).

Exemple : si vous avez besoin de 4 instances pour prendre en charge le pic de trafic, vous devez provisionner 6 instances.

Résilience face aux échecs de zones¶

Pour les charges de travail critiques qui nécessitent une résilience face à un échec de zone complet, vous pouvez utiliser un :doc:` pool de calcul </sql-reference/sql/create-compute-pool>` distribué lors de la création d’un service. Les pools de calcul distribués sont créés avec le paramètre PLACEMENT_GROUP défini sur DISTRIBUTED. Pour plus d’informations sur les pools de calcul distribués, voir Placement du pool de calcul.

Guide de configuration¶

ALTER COMPUTE POOL my_pool SUSPEND;

ALTER COMPUTE POOL my_pool
  SET PLACEMENT_GROUP = 'DISTRIBUTED';

ALTER COMPUTE POOL my_pool RESUME;

ALTER COMPUTE POOL my_pool SUSPEND;

ALTER COMPUTE POOL my_pool
  UNSET PLACEMENT_GROUP;

ALTER COMPUTE POOL my_pool RESUME;

DESCRIBE COMPUTE POOL my_service_pool;