Contrôles des coûts plus intelligents pour le serverless

Chez Databricks, l'utilisation de nos calculs sans serveur a plus que triplé au cours de l'année écoulée, et des milliers de clients y exécutent désormais des notebooks, des tâches et des pipelines critiques. Alors que l'adoption augmente, la première question que se pose chaque équipe de plateforme devient encore plus pressante : comment obtenir une meilleure visibilité sur les coûts des calculs sans serveur et respecter notre budget ?

Les clients Databricks qui utilisent les requêtes SQL sans serveur et le service de modèles sans serveur (« Model Serving ») attribuent déjà les dépenses, gèrent les accès et surveillent la consommation sans modifier un seul paramètre de cluster. Nous étendons désormais cette même fonctionnalité aux calculs sans serveur pour les notebooks, les tâches et les pipelines. Nous faisons en sorte que les contrôles des coûts sans serveur répondent aux attentes des équipes de plateforme.

Les calculs sans serveur ont déplacé le contrôle des coûts vers le haut

Avec les calculs classiques, le contrôle des coûts résidait dans l'infrastructure. Vous plafonniez les dépenses en limitant les machines : le nombre de nœuds, les types d'instances, les plages de mise à l'échelle automatique et les règles de cluster qui encadraient ce que les utilisateurs pouvaient provisionner. Ces contrôles étaient indispensables, car vous deviez gérer l'infrastructure vous-même.

Les calculs sans serveur suppriment ces réglages intentionnellement. Le provisionnement, la mise à l'échelle et l'ajustement de la taille de l'infrastructure incombent désormais à la plateforme, gérée par Databricks, ce qui représente une grande partie de la valeur ajoutée. Toutefois, le contrôle des coûts doit bien s'appliquer quelque part, il se déplace donc vers le haut. Plutôt que d'être lié aux machines, il est lié aux utilisateurs et aux charges de travail. Les questions qui comptent désormais sont : qui est autorisé à exécuter des calculs sans serveur, à quelle vitesse une charge de travail peut-elle consommer du budget, et où ce coût est-il imputé ?

Les équipes de plateforme expriment leurs besoins de trois manières :

• Dépenses incontrôlées : une seule exécution de notebook non limitée peut coûter des milliers de dollars en une seule journée, car il n'y a pas de taille de cluster ni de limite de mise à l'échelle automatique pour la restreindre.
• Entre de mauvaises mains : les calculs sans serveur sont accessibles à tout le monde par défaut, y compris aux utilisateurs qui ne devraient pas les provisionner, sans aucun droit d'accès pour filtrer qui peut les exécuter.
• Absence de responsabilité : les équipes n'adopteront pas les calculs sans serveur sans l'application de balises dont elles disposaient sur les calculs classiques.

Les calculs classiques répondaient à ces défis à l'aide de trois outils : des balises pour attribuer les coûts, des droits d'accès pour contrôler ces derniers et des limites de taille de cluster pour plafonner les dépenses. Les calculs sans serveur ont besoin des trois mêmes outils. Deux d'entre eux existent déjà, et le troisième arrive.

Les trois objectifs du contrôle des coûts sans serveur

1. Attribuer les coûts : savoir à quelle équipe, à quel projet ou à quel utilisateur appartient un DBU sans serveur.
2. Contrôler les accès : décider qui peut exécuter des calculs sans serveur en premier lieu, et sur quoi.
3. Limiter les dépenses : définir des limites sur le montant ou la vitesse de dépense d'une charge de travail ou d'une équipe, en amont plutôt qu'en aval.

Nous allons examiner chacun de ces points dans l'ordre.

Attribuer les coûts

L'attribution commence par les balises. Sur les calculs classiques, vous balisiez le cluster ; sur les calculs sans serveur, vous balisez le calcul, et chaque DBU consommé par ce calcul transmet cette balise jusqu'à la facturation.

• Balises de calcul sans serveur : balisez un objet de calcul sans serveur une seule fois, et les charges de travail qui s'y exécutent sont attribuées à la bonne équipe, au bon projet ou au bon centre de coûts, sans qu'aucun autre objet de règle ne soit nécessaire.
• Tables système : chaque DBU sans serveur atterrit dans system.billing.usage, ventilé par utilisateur, par produit et par balise. Une vue « coût par équipe » prête pour la direction s'obtient avec une seule requête, et les tableaux de bord de coûts de la console de compte l'affichent pour vous sans que vous ayez à écrire la moindre ligne de SQL.

Cette même table répond à la question d'audit que vous voudrez poser avant de modifier l'accès d'un utilisateur : qui exécute réellement des calculs sans serveur aujourd'hui, et combien cela lui coûte-t-il ? C'est une requête de plus, classée par consommation, et les exemples complets se trouvent dans la documentation des tables système.

Disponibilité : Les balises de calcul sans serveur pour l'attribution sont actuellement disponibles en version Bêta.

L'observabilité est déjà disponible et les clients peuvent déjà surveiller les coûts sans serveur à l'aide des tables système sur AWS, Azure et Google Cloud.

Suivre l'évolution des dépenses : budgets, alertes et tableaux de bord

Les mêmes tables système qui attribuent les coûts vous permettent également de les suivre. Les budgets de la console de compte déclenchent des alertes par e-mail lorsque les dépenses sans serveur dépassent un seuil, et les tableaux de bord de gestion des coûts vous permettent de suivre la consommation par produit, par espace de travail et par balise. Une alerte SQL sur les dépenses sans serveur de la veille permet de boucler la boucle en quelques heures.

La surveillance est toutefois réactive : elle signale le jour où les coûts ont flambé le lendemain matin au lieu de les empêcher. C'est cet écart qui justifie l'existence des deux objectifs suivants.

Disponibilité : La surveillance est généralement disponible dès aujourd'hui. Configurez des budgets et des alertes de dépenses sur AWS, Azure et Google Cloud.

Contrôler les accès

Le premier contrôle proactif consiste à décider qui a le droit d'exécuter des calculs sans serveur. Cette autorisation est un droit : elle définit quels utilisateurs ou groupes peuvent accéder aux calculs sans serveur, tout comme les droits existants contrôlent qui peut créer des clusters ou se connecter à un entrepôt SQL. Le contrôle d'accès aux calculs sans serveur (« Serverless Compute Access Controls ») est désormais généralement disponible et vous permet de gérer les calculs sans serveur avec ce modèle : des autorisations sur un objet de calcul, et non des règles ajoutées à chaque charge de travail.

Un objet de calcul sans serveur constitue la limite d'autorisation pour les calculs sans serveur. Chaque espace de travail en reçoit deux par défaut :

• Calcul interactif sans serveur par défaut : pour les notebooks et Databricks Connect.
• Calcul automatisé sans serveur par défaut : pour les tâches et les pipelines déclaratifs Spark (« Spark Declarative Pipelines »).

Les autorisations sur ces objets sont les deux que vous connaissez déjà pour les entrepôts : Peut utiliser et Peut gérer. Si vous savez déterminer qui peut se connecter à un entrepôt SQL, vous savez déterminer qui peut exécuter des calculs sans serveur.

Le modèle est sûr par défaut. Chaque utilisateur commence avec l'autorisation « Peut utiliser », de sorte que l'activation de la fonction ne change rien tant qu'un administrateur n'agit pas. Lorsqu'un administrateur agit, le processus est celui auquel vous vous attendez : ouvrez la page Calcul, allez dans l'onglet Sans serveur, ouvrez un objet de calcul par défaut, supprimez « Tous les utilisateurs » et ajoutez un groupe spécifique. Un utilisateur situé en dehors de ce groupe voit désormais l'option Sans serveur grisée dans le sélecteur de calcul des notebooks, et aucune exécution en cours n'est interrompue.

Disponibilité : Généralement disponible dès aujourd'hui. Consultez la documentation pour AWS, Azure et Google Cloud.

Définir des limites de dépenses

Le contrôle des accès détermine si une charge de travail s'exécute, mais pas combien elle peut dépenser une fois lancée. Combler cet écart est la troisième tâche, à savoir les limites de débit (« Rate Limits »), et cela s'applique aux mêmes objets de calcul que vous venez de voir.

• Limites de débit sur les charges de travail automatisées : des limites par calcul, exprimées sous forme de tailles de t-shirt (S, M, L, XL) qui encadrent le montant ou la vitesse des dépenses d'une tâche ou d'un pipeline, plutôt de définir simplement s'ils peuvent s'exécuter. Les administrateurs peuvent créer des objets de calcul personnalisés et les partager avec chaque équipe, ce qui attribue à chacune sa propre limite. C'est le modèle classique des politiques de cluster, adapté au mode sans serveur.
• Budgets partagés pour les calculs interactifs (bientôt disponible) : un plafond par session ne suffit pas à protéger le budget d'une équipe, car un grand nombre de sessions de taille « Moyenne » s'additionnent rapidement. Notre objectif est de proposer une limite partagée pour le groupe, avec un maximum par session comme filet de sécurité en dessous.

L'attribution s'améliore en même temps. Un nouveau serverless_compute_id dans system.billing.usage attribue les coûts par objet de calcul, de sorte que le "coût par objet de calcul" devient aussi simple que le "coût par équipe".

Une précision pour tous ceux qui connaissent les tailles de t-shirt DBSQL : pour les notebooks et les tâches, la taille est un plafond d'autoscale maximal, et non une taille de cluster fixe. Choisissez XL pour une tâche qui n'a besoin que de Medium, et elle se verra attribuer Medium.

Disponibilité : Les limites de débit sont désormais disponibles en version bêta. Activez les limites de débit via vos paramètres de prévisualisation Databricks ; consultez la documentation pour AWS, Azure et Google Cloud.

Vue d'ensemble

Assemblez à nouveau les trois tâches :

• Attribuer les coûts : des balises natives sur le calcul sans serveur ainsi que serverless_compute_id dans les tables système, utilisables dans les budgets et les tableaux de bord.
• Contrôler l'accès : des droits sur les objets de calcul sans serveur.
• Limiter les dépenses : des limites de débit, partagées au sein d'un groupe et limitées par charge de travail.

Commencer dès aujourd'hui

Vous pouvez commencer à appliquer les contrôles des coûts sans serveur dès aujourd'hui. Voici comment procéder :

1. Activer l'application des balises : balisez votre calcul sans serveur afin que l'attribution soit en place avant tout le reste.
2. Mettre en place la surveillance : ajoutez des tableaux de bord des coûts sur system.billing.usage ainsi qu'une alerte budgétaire sur les dépenses sans serveur.
3. Auditer les utilisateurs du calcul sans serveur : afin de connaître l'impact potentiel avant de modifier les accès.
4. Définir votre stratégie d'accès : qui doit pouvoir exécuter des tâches interactives sans serveur et qui doit exécuter des tâches automatisées ?
5. Activer les contrôles d'accès au calcul sans serveur : activez un calcul rapide et entièrement géré pour les groupes de votre choix.

Les contrôles d'accès au calcul sans serveur sont désormais généralement disponibles. Pour approfondir l'attribution et la surveillance dès aujourd'hui, consultez la documentation sur les tables système (AWS | Azure| GCP) et le balisage sans serveur (AWS | Azure | GCP).

En savoir plus :

• Gérer le calcul sans serveur sur AWS | Azure | GCP
• Se connecter au calcul sans serveur | Databricks sur AWS
• Se connecter au calcul sans serveur - Azure Databricks
• Outils de gestion des coûts sur Databricks - Azure Databricks
• Le calcul sans serveur à l'échelle du pétaoctet : Derniers lancements, feuille de route et migration
• Moins d'infrastructure, plus d'impact : la transformation sans serveur de Nationwide

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original