Databricks führt Ratenlimits und Zugriffskontrollen ein, um die Serverless-Kosten zu begrenzen

Warum die Kostenkontrolle eine Ebene nach oben wandert

Laut Databricks ist die Nutzung seines Serverless Compute im vergangenen Jahr um mehr als das Dreifache gewachsen, und Tausende Kunden betreiben mittlerweile geschäftskritische Notebooks, Jobs und Pipelines darauf. Mit der zunehmenden Verbreitung fragen Plattformteams immer häufiger, wie sie die Serverless-Kosten besser im Blick behalten und im Budget bleiben können.

Bei klassischem Compute lag die Kostenkontrolle nach Darstellung des Unternehmens in der Infrastruktur: Knotenanzahl, Instanztypen, Autoscaling-Bereiche und Cluster-Richtlinien. Serverless nimmt diese Stellschrauben bewusst weg, weshalb die Kontrolle stattdessen an Personen und Workloads ansetzt. Databricks beschreibt drei wiederkehrende Sorgen von Plattformteams:

• Ausufernde Ausgaben: Ein einziger unbegrenzter Notebook-Lauf kann an einem Tag Tausende kosten, weil es weder eine Clustergröße noch eine Autoscaling-Obergrenze gibt.
• Die falschen Hände: Serverless steht standardmäßig allen zur Verfügung, es gibt keine Berechtigung, die regelt, wer es nutzen darf.
• Fehlende Zurechenbarkeit: Teams steigen nicht auf Serverless um, wenn sie die Tag-Durchsetzung nicht erhalten, die sie von klassischem Compute kennen.

Kunden, die Serverless SQL und Model Serving einsetzen, ordnen Ausgaben nach Databricks-Angaben bereits zu, steuern den Zugriff und überwachen den Verbrauch. Diese Funktionen bringt das Unternehmen nun auch auf Serverless Compute für Notebooks, Jobs und Pipelines.

Zuordnung und Überwachung schon heute verfügbar

Die Zuordnung beginnt mit Tags. Mit Serverless Compute Tags versieht ein Team ein Serverless-Compute-Objekt einmal mit einem Tag, und die darauf laufenden Workloads werden dem richtigen Team, Projekt oder der richtigen Kostenstelle zugeordnet. Jede DBU, die dieses Compute verbraucht, trägt den Tag bis in die Abrechnung. Diese Funktion befindet sich derzeit in der Beta-Phase.

Laut Databricks landet außerdem jede Serverless-DBU in system.billing.usage, aufgeschlüsselt nach Nutzer, Produkt und Tag. Damit genügt für eine Ansicht der Kosten pro Team eine einzige Abfrage, und die Kosten-Dashboards in der Account-Konsole stellen sie ohne SQL dar. Dieselbe Tabelle zeigt, wer derzeit Serverless nutzt und wie viel er ausgibt. Databricks empfiehlt, das zu prüfen, bevor man jemandes Zugriff ändert.

Zur Überwachung versenden Budgets in der Account-Konsole E-Mail-Warnungen, sobald die Serverless-Ausgaben einen Schwellenwert überschreiten, und Dashboards zur Kostenverwaltung verfolgen den Verbrauch nach Produkt, Workspace und Tag. Die Überwachung ist auf AWS, Azure und Google Cloud allgemein verfügbar. Databricks räumt die Grenze ein: Monitoring ist reaktiv und meldet einen teuren Tag erst am nächsten Morgen, statt ihn zu verhindern.

Zugriffskontrollen und Ratenlimits

Serverless Compute Access Controls ist ab sofort allgemein verfügbar. Dabei gilt ein Serverless-Compute-Objekt als Berechtigungsgrenze. Jeder Workspace erhält standardmäßig zwei davon: Default Serverless Interactive Compute für Notebooks und Databricks Connect sowie Default Serverless Automated Compute für Jobs und Spark Declarative Pipelines. Die Berechtigungen sind die bekannten Stufen Can Use und Can Manage.

Das Modell ist laut Databricks standardmäßig sicher. Jeder Nutzer startet mit Can Use, sodass die Aktivierung der Funktion nichts ändert, bis ein Administrator tätig wird. Ein Admin kann die Seite Compute öffnen, zum Tab Serverless wechseln, ein Standard-Compute-Objekt öffnen, „All Users“ entfernen und eine bestimmte Gruppe hinzufügen. Nutzer außerhalb dieser Gruppe sehen Serverless in der Compute-Auswahl des Notebooks ausgegraut, laufende Workloads werden nicht unterbrochen.

Die Zugriffskontrolle entscheidet, ob ein Workload läuft, nicht aber, wie viel er kostet. Hier setzen die Ratenlimits für automatisierte Workloads an. Es sind Limits pro Compute-Objekt, die als T-Shirt-Größen (S, M, L, XL) angegeben werden und begrenzen, wie viel oder wie schnell ein Job oder eine Pipeline ausgeben darf. Admins können eigene Compute-Objekte anlegen und teamweise freigeben, sodass jedes Team sein eigenes Limit erhält.

Databricks weist auf einen Unterschied zu den DBSQL-Größen hin: Bei Notebooks und Jobs ist die Größe eine maximale Autoscaling-Obergrenze und keine feste Clustergröße. Ein Job, der nur Medium braucht, bekommt auch dann Medium zugewiesen, wenn XL gewählt wurde. Eine neue serverless_compute_id in system.billing.usage ordnet die Ausgaben je Compute-Objekt zu. Ratenlimits befinden sich in der Beta-Phase und werden über die Preview-Einstellungen von Databricks aktiviert.

Was das für Plattformteams bedeutet

Geteilte Budgets für interaktive Workloads sind noch nicht verfügbar. Databricks argumentiert, eine Obergrenze pro Sitzung allein könne das Budget eines Teams nicht schützen, da sich viele „Medium“-Sitzungen trotzdem summieren. Als erklärte Richtung nennt das Unternehmen ein gemeinsames Limit für die Gruppe, darunter eine Höchstgrenze pro Sitzung.

Für Teams, die jetzt auf Serverless umsteigen, empfiehlt Databricks eine feste Reihenfolge: zuerst die Tag-Durchsetzung einschalten, Kosten-Dashboards und eine Budgetwarnung einrichten, prüfen, wer Serverless derzeit nutzt, die Zugriffsstrategie für interaktive und automatisierte Arbeit festlegen und anschließend Serverless Compute Access Controls aktivieren. Die Dokumentation für AWS, Azure und Google Cloud behandelt jede der Funktionen.