Intelligentere Kostenkontrolle für Serverless

Bei Databricks ist unsere Nutzung serverloser Compute-Ressourcen im vergangenen Jahr um das Dreifache gestiegen, und Tausende von Kundinnen und Kunden führen darauf nun geschäftskritische Notebooks, Jobs und Pipelines aus. Mit zunehmender Verbreitung stellt sich jedem Platform Team unweigerlich die Frage: Wie erhalten wir mehr Transparenz über die Kosten für serverlose Workloads und halten diese im Budget?

Databricks Kundinnen und Kunden, die serverloses SQL und Model Serving nutzen, können Kosten bereits zuordnen, den Zugriff steuern und den Verbrauch überwachen, ohne auch nur einen einzigen Cluster-Regler anzupassen. Wir bringen diese Funktionalität nun auch für serverlose Compute-Ressourcen für Notebooks, Jobs und Pipelines. Damit sorgen wir dafür, dass die Kostenkontrolle für serverlose Workloads genau so funktioniert, wie Platform Teams es erwarten.

Serverless hat die Kostenkontrolle auf eine höhere Ebene gehoben

Bei klassischem Compute war die Kostenkontrolle in der Infrastruktur angesiedelt. Sie haben Ausgaben begrenzt, indem Sie Maschinen gedeckelt haben: Anzahl der Nodes, Instanztypen, Autoscaling-Bereiche und Cluster-Richtlinien, die festlegten, was Benutzerinnen und Benutzer bereitstellen durften. Diese Kontrollen waren notwendig, weil Sie die Infrastruktur selbst verwalten mussten.

Serverless nimmt Ihnen diese Regler ganz bewusst ab. Das Bereitstellen, Skalieren und Anpassen der Infrastruktur ist nun Aufgabe der Plattform und wird von Databricks übernommen – das macht einen großen Teil des Werts aus. Die Kostenkontrolle muss jedoch irgendwo stattfinden und wandert daher eine Ebene nach oben. Statt an Maschinen ist sie nun an Personen und Workloads gekoppelt. Wer darf serverlose Workloads ausführen, wie schnell darf ein Workload Kosten verursachen und wo schlagen die Kosten nieder – das sind jetzt die entscheidenden Fragen.

Platform Teams beschreiben ihre Anforderungen auf drei Arten:

• Ausufernde Kosten: Ein einziger unbegrenzter Notebook-Lauf kann an einem Tag Tausende kosten, da es keine Cluster-Größe oder kein Autoscaling-Limit gibt, das ihn einschränkt.
• In den falschen Händen: Serverless ist standardmäßig für alle verfügbar, auch für Benutzerinnen und Benutzer, die es nicht bereitstellen sollten, ohne dass Berechtigungen den Zugriff regeln.
• Keine Nachvollziehbarkeit: Teams werden Serverless nicht ohne die Tag-Durchsetzung nutzen, die sie von klassischem Compute gewohnt sind.

Klassisches Compute hat dies mit drei Tools beantwortet: Tags zur Kostenzuordnung, Berechtigungen zur Zugriffskontrolle und Limits für die Cluster-Größe zur Kostenbegrenzung. Serverless benötigt dieselben drei Tools. Zwei davon gibt es bereits, und das dritte folgt bald.

Die drei Ziele der Kostenkontrolle für serverlose Workloads

1. Kosten zuordnen: Wissen, zu welchem Team, Projekt oder welcher Person ein serverloses DBU gehört.
2. Zugriff steuern: Entscheiden, wer überhaupt serverlose Workloads ausführen darf und worauf.
3. Kosten begrenzen: Im Voraus statt im Nachhinein festlegen, wie viel oder wie schnell ein Workload oder ein Team ausgeben darf.

Wir schauen uns diese Punkte nun nacheinander an.

Kosten zuordnen

Die Zuordnung beginnt mit Tags. Bei klassischem Compute haben Sie das Cluster getaggt; bei Serverless taggen Sie die Compute-Ressource, und jedes DBU, das darauf ausgeführt wird, trägt dieses Tag bis zur Abrechnung mit sich.

• Serverless Compute Tags: Taggen Sie ein serverloses Compute-Objekt einmal, und die darauf ausgeführten Workloads werden dem richtigen Team, Projekt oder Kostenzentrum zugeordnet – ganz ohne separates Richtlinienobjekt, das gepflegt werden muss.
• Systemtabellen: Jedes serverlose DBU landet in system.billing.usage, aufgeschlüsselt nach Benutzerin bzw. Benutzer, Produkt und Tag. Eine führungskräftetaugliche Ansicht der Kosten nach Team ist nur eine einzige Abfrage entfernt, und die Kosten-Dashboards der Account Console zeigen dies an, ohne dass Sie auch nur eine Zeile SQL schreiben müssen.

Dieselbe Tabelle beantwortet die Audit-Frage, die Sie klären möchten, bevor Sie den Zugriff von irgendjemandem ändern: Wer führt aktuell überhaupt serverlose Workloads aus und wie viel geben diese Personen aus? Das ist eine weitere Abfrage, sortiert nach Verbrauch, und die vollständigen Beispiele finden Sie in der Dokumentation zu den Systemtabellen.

Verfügbarkeit: Serverless Compute Tags für die Zuordnung sind derzeit als Beta verfügbar.

Die Observability ist bereits verfügbar, und Kundinnen und Kunden können serverlose Kosten bereits mit Systemtabellen auf AWS, Azure und Google Cloud überwachen.

Kosten bei der Entwicklung im Blick behalten: Budgets, Benachrichtigungen und Dashboards

Dieselbe Systemtabelle, die Kosten zuordnet, ermöglicht Ihnen auch deren Nachverfolgung. Budgets in der Account Console lösen E-Mail-Benachrichtigungen aus, wenn die serverlosen Kosten einen Schwellenwert überschreiten, und mit den Kostenmanagement-Dashboards können Sie den Verbrauch nach Produkt, Workspace und Tag verfolgen. Eine SQL-Benachrichtigung zu den serverlosen Kosten des gestrigen Tages schließt den Kreis innerhalb weniger Stunden.

Die Überwachung ist jedoch reaktiv: Sie meldet den kostenintensiven Tag am nächsten Morgen, anstatt ihn zu verhindern. Genau deshalb gibt es die nächsten beiden Ziele.

Verfügbarkeit: Die Überwachung ist ab heute allgemeine Verfügbarkeit (GA). Richten Sie Budgets und Ausgabenbenachrichtigungen auf AWS, Azure und Google Cloud ein.

Zugriff steuern

Die erste proaktive Kontrolle besteht darin zu entscheiden, wer überhaupt serverlose Workloads ausführen darf. Diese Berechtigung ist ein sogenanntes Entitlement: Sie legt fest, welche Benutzerinnen, Benutzer oder Gruppen auf Serverless zugreifen können – genau wie bestehende Berechtigungen steuern, wer Cluster erstellen oder sich mit einem SQL Warehouse verbinden kann. Serverless Compute Access Controls sind jetzt allgemein verfügbar (GA) und ermöglichen Ihnen die Verwaltung von Serverless über dieses Modell: Berechtigungen für ein Compute-Objekt statt Richtlinien, die an jeden Workload geknüpft sind.

Ein serverloses Compute-Objekt ist die Berechtigungsgrenze für Serverless. Jeder Workspace erhält standardmäßig zwei davon:

• Default Serverless Interactive Compute: Notebooks und Databricks Connect.
• Default Serverless Automated Compute: Jobs und Spark Declarative Pipelines.

Die Berechtigungen für diese Objekte entsprechen den beiden, die Sie bereits von Warehouses kennen: Can Use und Can Manage. Wenn Sie nachvollziehen können, wer sich mit einem SQL Warehouse verbinden darf, können Sie auch nachvollziehen, wer serverlose Workloads ausführen darf.

Das Modell ist standardmäßig sicher. Jede Person beginnt mit Can Use. Das Einschalten der Funktion ändert also erst einmal nichts, bis ein Admin aktiv wird. Wenn ein Admin aktiv wird, verläuft der Prozess wie erwartet: Öffnen Sie die Compute-Seite, rufen Sie den Tab „Serverless“ auf, öffnen Sie ein standardmäßiges Compute-Objekt, entfernen Sie „All Users“ und fügen Sie eine spezifische Gruppe hinzu. Benutzerinnen oder Benutzer außerhalb dieser Gruppe sehen Serverless im Notebook-Compute-Auswahlmenü nun grau hinterlegt, und bereits laufende Prozesse werden nicht unterbrochen.

Verfügbarkeit: Ab heute allgemein verfügbar. Weitere Informationen finden Sie in der Dokumentation für AWS, Azure und Google Cloud.

Ausgabenlimits festlegen

Die Zugriffskontrolle entscheidet, ob ein Workload ausgeführt wird, aber nicht, wie viel er kosten darf, sobald er läuft. Diese Lücke zu schließen ist die dritte Aufgabe – Rate Limits – und sie betrifft dieselben Compute-Objekte, die Sie gerade gesehen haben.

• Rate Limits für automatisierte Workloads: Limits pro Compute-Ressource, ausgedrückt in T-Shirt-Größen (S, M, L, XL), die begrenzen, wie viel oder wie schnell ein Job oder eine Pipeline Kosten verursachen kann, anstatt nur zu bestimmen, ob er bzw. sie ausgeführt werden darf. Admins können benutzerdefinierte Compute-Objekte erstellen und diese für jedes Team freigeben, sodass jedes Team sein eigenes Limit erhält. Dies ist das klassische Cluster-Richtlinien-Muster, übertragen auf Serverless.
• Gemeinsame Budgets für interaktive Workloads (demnächst verfügbar): Ein Limit pro Sitzung allein kann das Budget eines Teams nicht schützen, da viele „Medium“-Sitzungen sich summiert läppern. Unser Ziel ist ein gemeinsames Limit für die Gruppe, flankiert von einem Maximum pro Sitzung als Sicherheitsnetz darunter.

Die Zuordnung verbessert sich gleichzeitig. Eine neue serverless_compute_id in system.billing.usage ordnet die Ausgaben pro Compute-Objekt zu, sodass „Kosten nach Compute-Objekt“ genauso einfach werden wie „Kosten nach Team“.

Eine Klarstellung für alle, die DBSQL-T-Shirt-Größen kennen: Bei Notebooks und Jobs ist die Größe eine maximale Obergrenze für das Autoscaling und keine feste Clustergröße. Wählen Sie XL für einen Job, der nur Medium benötigt, wird ihm Medium zugewiesen.

Verfügbarkeit: Ratenlimits sind jetzt in der Beta-Version verfügbar. Aktivieren Sie Ratenlimits über Ihre Databricks-Vorschau-Einstellungen; weitere Informationen finden Sie in der Dokumentation für AWS, Azure und Google Cloud.

Das Gesamtbild

Fügen Sie die drei Jobs wieder zusammen:

• Kostenzuordnung: Native Tags für serverloses Compute sowie serverless_compute_id in Systemtabellen, nutzbar in Budgets und Dashboards.
• Zugriffskontrolle: Berechtigungen für serverlose Compute-Objekte.
• Ausgaben begrenzen: Ratenlimits, gemeinsam genutzt in einer Gruppe und begrenzt pro Workload.

Jetzt starten

Sie können noch heute mit der Implementierung von serverlosen Kostenkontrollen beginnen. So geht's:

1. Tag-Durchsetzung aktivieren: Taggen Sie Ihr serverloses Compute, damit die Zuordnung vor allem anderen eingerichtet ist.
2. Monitoring einrichten: Fügen Sie Kostendashboards auf system.billing.usage sowie eine Budgetwarnung für serverlose Ausgaben hinzu.
3. Überprüfen Sie, wer heute serverloses Compute nutzt: Damit Sie die Auswirkungen kennen, bevor Sie den Zugriff ändern.
4. Legen Sie Ihre Zugriffsrichtlinie fest: Wer sollte interaktives serverloses Compute ausführen dürfen und wer automatisiertes?
5. Zugriffskontrollen für serverloses Compute aktivieren: Ermöglichen Sie schnelles, vollständig verwaltetes Compute für die von Ihnen ausgewählten Gruppen.

Zugriffskontrollen für serverloses Compute sind ab sofort allgemein verfügbar. Um sich heute intensiver mit Zuordnung und Monitoring zu befassen, ist die Dokumentation zu Systemtabellen (AWS | Azure| GCP) und serverlosem Tagging (AWS | Azure | GCP) der ideale Ausgangspunkt.

Weitere Informationen:

• Serverloses Compute auf AWS verwalten | Azure | GCP
• Verbindung mit serverlosem Compute herstellen | Databricks auf AWS
• Verbindung mit serverlosem Compute herstellen – Azure Databricks
• Tools zur Kostenverwaltung auf Databricks – Azure Databricks
• Serverloses Compute im Petabyte-Maßstab: Neueste Launches, Roadmap und Migration
• Weniger Infrastruktur, höhere Wirkung: Die serverlose Transformation von Nationwide

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag