Snowflake veut abstraire davantage l’accès aux ressources de calcul

Adaptive Compute et Warehouses : un nouveau mode de gestion des ressources de calcul

En parallèle, Snowflake a présenté en préversion privée Adaptive Compute et les Adaptive Warehouses qui ajoutent une couche d’abstraction supplémentaire dans le contrôle des ressources.

« Le modèle de séparation du calcul du stockage dont nous sommes l’un des pionniers a prouvé son efficacité », déclare Christian Kleinerman, vice-président exécutif du produit chez Snowflake. « Mais nous avons également appris qu’à grande échelle et pour de nombreux clients, l’effort et le processus de décision consistant à déterminer quelles requêtes vont à quel cluster de calcul et quelle est la bonne taille du cluster, affectent la facilité d’utilisation et le coût d’exploitation de la plateforme ».

Les calculs et les entrepôts « adaptatifs » correspondent, selon le dirigeant, à une « évolution de ce modèle » de séparation des charges de travail.

« Les clients définiront un jeu de règles, par exemple la durée maximale d’une requête suivant son type et notre plateforme décidera quelles ressources de calcul sont nécessaires pour l’exécuter, sans avoir à spécifier la taille ou le nombre de clusters », informe Christian Kleinerman.

Par cette optimisation de l’allocation des requêtes, Snowflake entend ajuster le rapport performance-prix de son offre. « Nous faisons également en sorte d’améliorer la gestion des ressources déjà utilisées par les clients », avance le dirigeant. Il faudra faire confiance dans le système de Snowflake pour éteindre et relancer sans interversions les objets Adaptive Compute.

Concernant les entrepôts adaptatifs, la sélection du cluster sera automatiquement effectuée dans un pool de ressources alloué à un compte client. L'administrateur spécifie le nombre maximal de crédits par heure et la taille limite (xSmall, Small, Medium, etc.) de l’entrepôt virtuel.

 Le fournisseur assure que ses clients pourront toujours utiliser le volet FinOps de la plateforme (Budget) pour contrôler les coûts. Pfizer teste déjà cette solution d’allocation des ressources qui n’affectent pas (encore) le modèle tarifaire pratiqué par Snowflake. Pfizer observerait un gain de 32 % de vitesse d’exécution des requêtes les plus complexes, la suppression de leur mise en attente et une diminution significative de l’effet « voisin bruyant » lors des pics de charges de travail concurrentes.

Justement, pour tous les clients, Snowflake dit avoir amélioré l’observabilité de l’ingestion de données dans les tables et ajoute la prise en charge des traces liées aux requêtes SQL issues de procédures stockées. Il est également possible de consulter les logs, les traces et les métriques dédiées aux applications lancées à travers Snowpark Container Services.

Sur le volet FinOps, en préversion publique, un algorithme de détection d’anomalie notifie les pics de consommation jugés anormaux. Il était auparavant intégré dans un package Streamlit, mais l’éditeur vient de terminer son infusion dans l’interface de gestion des coûts. Des labels, bientôt en disponibilité générale, permettront de fixer des limites de ressources, tandis que l’explorateur de performance est accessible. Les indicateurs sur les requêtes et les lots de requêtes entrent en préversion privée.

Sécurité : Snowflake n’a pas traîné

Du côté de la gouvernance, l’éditeur complète sa couche Horizon. Un outil de synchronisation automatique (Catalog-Link Databases) doit assurer la réunion des objets (métadonnées) gérés par les catalogues Iceberg REST, Apache Polaris, Snowflake Open Catalog et AWS Glue. La couche Universal Search permettra de rechercher des données dans des bases de données relationnelles, dont PostgreSQL et MySQL. Un Chatbot Cortex facilitera l’interrogation de l’ensemble des données en langage naturel tout en respectant les politiques d’accès. Bref, l’éditeur suit la feuille de route présentée l’année dernière, en prenant son temps.

En revanche, en matière de sécurité, Snowflake a mis moins d’un an à appliquer les leçons tirées des brèches ayant impacté TicketMaster et Santander. Même s’il n’est pas directement responsable, il avait enclenché par défaut l’authentification multifacteur. Le fournisseur ajoute la prise en charge progressive des moyens d’authentification sans mots de passe (TouchID, FaceID, Windows Hello et les clés physiques de sécurité).

De plus, Snowflake lance ses tokens d’accès programmatique, temporaire par nature, à la place des mots de passe statiques. Ceux-là servent aux accès des utilisateurs et des charges de travail. L’éditeur n’a pas donné de nouvelles de la fonction de confidentialité différentielle, toujours en préversion publique.

Le centre de « confiance » permettra de déployer des scanners de détection de menaces spécifiques aux environnements et aux configurations des clients. Ces extensions présentées l’année dernière arrivent en disponibilité générale, mais aucune date n’est précisée. Le Trust Center embarque déjà un moteur de règles et, en préversion privée, un modèle d’IA pour détecter les comportements anormaux des utilisateurs. L’analyse de mots de passe sur le Dark Web, et la demande de changement automatique est accessible, à l’instar du blocage des IP considérées comme suspectes.

Snowflake entend par ailleurs introduire un dispositif pour déceler les données sensibles afin de notifier les administrateurs et d’établir des rapports. Un mécanisme de génération de données synthétiques permet déjà de remplacer les copies de données de production dans les environnements de développement.

En outre, la connexion au VPC de Google (Private Link) entrante et sortante est désormais prise en charge, comme avec AWS et Azure. La gestion de la réplication et des failovers est aussi disponible. Cependant, Snowflake accuse un certain retard en matière d’administration des backups. Sa fonction de snapshot sera « bientôt » en préversion publique.