Gouvernance des coûts du connecteur Snowflake pour ServiceNow¶

Cette rubrique présente les meilleures pratiques en matière de gouvernance des coûts et de recherche de la taille optimale de l’entrepôt pour le connecteur Snowflake pour ServiceNow.

Mesure du coût du connecteur¶

Si le connecteur dispose d’un compte séparé uniquement pour l’ingestion et le stockage des données, et que le compte ne présente aucune autre activité (telle que l’exécution de requêtes par des utilisateurs utilisant les données ingérées), vous pouvez lire le coût global au niveau du compte. Pour en savoir plus, reportez-vous à Explorer le coût global.

Si le compte n’est pas dédié uniquement au connecteur ou si vous devez étudier les coûts de manière plus approfondie, vous devez analyser séparément les coûts facturés pour les trois composants :

Coût de calcul
Coût de stockage
Coûts du transfert des données

Pour une introduction à ces trois composantes du coût, reportez-vous à Compréhension du coût global.

Recommandations générales¶

Pour obtenir le coût généré par le connecteur, nous vous recommandons de créer un compte séparé uniquement pour l’utilisation du connecteur. Vous pouvez ainsi suivre le transfert exact des données générées par le connecteur.

Si vous ne pouvez pas utiliser un compte distinct pour le connecteur, essayez ce qui suit :

Créez une base de données distincte pour le stockage des données ingérées afin de faciliter le suivi des coûts de stockage.
Allouez un entrepôt uniquement pour le connecteur afin d’obtenir le coût de calcul exact.
Utilisez les balises d’objet sur les bases de données et un entrepôt pour créer des rapports de coûts personnalisés.
Si vous utilisez une configuration sans serveur, vous pouvez interroger la vue SERVERLESS_TASK_HISTORY , filtrer sur le nom du connecteur et consulter la colonne CREDITS_USED pour obtenir le coût.

Coût de calcul¶

Nous vous recommandons de créer un entrepôt distinct uniquement pour le connecteur. Cette configuration vous permet de créer des moniteurs de ressources sur l’entrepôt. Vous pouvez utiliser les moniteurs pour envoyer des alertes par e-mail et suspendre l’entrepôt, en arrêtant le connecteur lorsque le quota de crédit défini est dépassé. Le connecteur reprend automatiquement après le renouvellement du quota de crédit. Notez que si le quota de crédit est trop bas dans les configurations où de grands volumes de données sont ingérés, le connecteur risque de ne pas ingérer toutes les données.

Pour obtenir des informations sur la manière de vérifier les crédits consommés par l’entrepôt, reportez-vous à Découverte des coûts de calcul. Vous pouvez également attribuer à l’entrepôt des balises d’objets et utiliser ces balises pour créer des rapports de coûts.

Si l’entrepôt utilisé par le connecteur est utilisé par d’autres flux de travail, vous pouvez répartir le coût par rôle. Pour répartir l’utilisation par rôle, utilisez la requête pour répartir l’utilisation de l’entrepôt et ajoutez la clause WHERE suivante à la vue QUERY_HISTORY :

WAREHOUSE_NAME = '<connector warehouse name>' AND
ROLE_NAME IN ('APP_PRIMARY', ‘<role created for the connector to ingest data>’)

Copy

La requête ne donne qu’une approximation du coût.

Note

Une seule application native peut utiliser l’entrepôt, sinon les coûts des différentes applications sont indissociables, car chaque application native utilise le même nom de rôle (APP_PRIMARY).

Pour les connecteurs configurés pour utiliser des tâches sans serveur, vous pouvez interroger la vue SERVERLESS_TASK_HISTORY. La vue présente les colonnes CREDITS_USED et DATABASE_NAME, cette dernière pouvant être utilisée pour filtrer le nom du connecteur.

Coût de stockage¶

Le connecteur Snowflake pour ServiceNow stocke les données à deux endroits :

La base de données du connecteur, qui est créée à partir du partage public et qui contient l’état interne du connecteur.
Le schéma spécifié par l’utilisateur dans lequel les données ingérées sont stockées.

Le stockage de données est également utilisé par la fonctionnalité Fail-safe de Snowflake. La quantité de données stockées dans Fail-safe dépend des mises à jour de tables effectuées par le connecteur. La quantité de données augmente si les lignes de la table ingérées à partir de ServiceNow sont fréquemment mises à jour ou si la table entière est rechargée. En général, sept à dix jours après la mise en place du connecteur, la quantité de données Fail-safe se stabilise (en supposant qu’aucun rechargement n’est effectué et que le flux de données ingérées se maintient à un rythme régulier).

Si vous souhaitez vérifier l’utilisation du stockage dans Snowsight, nous vous recommandons de disposer d’une base de données distincte pour le stockage des données ingérées. Vous pouvez ainsi filtrer les graphiques d’utilisation du stockage par objet, qui indiquent l’utilisation par bases de données distinctes. Vous pouvez également le faire en interrogeant la vue DATABASE_STORAGE_USAGE_HISTORY et en filtrant par les deux bases de données utilisées par le connecteur.

Si la base de données contient d’autres schémas sans rapport avec le connecteur, vous pouvez interroger l’utilisation du stockage d’un schéma spécifique dédié aux données ingérées à partir du connecteur. Vous pouvez obtenir les informations à partir de la vue TABLE_STORAGE_METRICS après avoir filtré par nom de base de données et de schéma et agrégé les colonnes avec l’utilisation du stockage.

Coûts du transfert des données¶

Le connecteur utilise des fonctions externes pour récupérer des données depuis ServiceNow. Snowflake ne facture que le trafic de sortie généré par le connecteur, en fonction de la taille des requêtes du connecteur vers ServiceNow. Les réponses de ServiceNow ne génèrent pas de coûts du côté de Snowflake.

Les informations sur l’utilisation du transfert de données ne sont disponibles que sous une forme agrégée pour toutes les fonctions externes au niveau du compte. Pour accéder au nombre d’octets transférés, utilisez la vue DATA_TRANSFER_HISTORY et filtrez par type de transfert EXTERNAL_FUNCTION.

Détermination de la taille optimale de l’entrepôt pour l’instance du connecteur¶

Pour trouver la taille optimale de l’entrepôt pour le connecteur, vous devez prendre en compte les facteurs qui affectent les performances du connecteur, tels que la taille de l’instance ServiceNow, le nombre de tables activées et la planification de synchronisation de chaque table. Par exemple, si seules quelques tables sont activées, le connecteur peut ne pas bénéficier d’une parallélisation accrue.

Nous vous recommandons de définir un ensemble d’attentes mesurables, telles que les intervalles de temps dans lesquels toutes les tables doivent être synchronisées, et de choisir la plus petite taille d’entrepôt qui réponde à ces attentes. Pour de grandes quantités de données ingérées avec des dizaines de tables synchronisées, la recommandation par défaut est « entrepôt de grande taille ». En revanche, si vous souhaitez simplement tester le connecteur et activer une seule table pour l’ingestion, un entrepôt X-Small devrait suffire. Pour savoir si vous pouvez réduire la taille de l’entrepôt, reportez-vous à Surveillance de charge d’entrepôt.

Démarrage et arrêt automatique du connecteur dans un délai déterminé¶

Pour réduire les coûts, vous pouvez exécuter le connecteur uniquement pendant une période donnée (par exemple, en dehors des heures de bureau), en appelant les procédures STOP_CONNECTOR et RESUME_CONNECTOR.

Vous pouvez automatiser le démarrage et l’arrêt du connecteur avec des tâches sans serveur. Par exemple, pour exécuter le connecteur en dehors des heures d’ouverture UTC, vous pouvez utiliser la requête suivante :

CREATE TASK start_connector_after_business_hours
   SCHEDULE USING CRON 0 17 * * MON-FRI Europe/London
   AS CALL <my_connector_servicenow>.PUBLIC.RESUME_CONNECTOR();

CREATE TASK stop_connector_before_business_hours
   SCHEDULE USING CRON 0 9 * * MON-FRI Europe/London
   AS CALL <my_connector_servicenow>.PUBLIC.STOP_CONNECTOR();

Copy