Bereitstellung der Databricks-Netzwerkkonfiguration für zig Millionen Serverless-VMs

Zusammenfassung

• Die Serverless-Plattform von Databricks startet täglich zig Millionen VMs, und jede VM benötigt eine Netzwerkkonfiguration (wie zulässige Ziele und private Endpunkte), bevor sie Kunden-Workloads verarbeiten kann. Da jeder Knoten beim Start die Konfiguration abruft und während seiner gesamten Lebensdauer nach Updates pollt, führt dies zu Milliarden von Netzwerkkonfigurationsanfragen pro Tag. Die alte Architektur rief diese Daten synchron von mehreren Upstream-Diensten ab, was zu Latenz- und Verfügbarkeitsengpässen führte.
• Wir haben die Bereitstellung der Netzwerkkonfiguration mithilfe von ereignisgesteuerten Pipelines und Snapshot-Vorberechnung neu strukturiert. Dadurch konnten wir die RPC-Latenz um 97,5 % senken (5.000 ms → 125 ms) und eine Serviceverfügbarkeit von 99,99 % erreichen.

Problemstellung

Die Serverless-Compute-Plattform von Databricks bildet die Basis für praktisch alle unsere Daten- und KI-Produkte, wie SQL-Warehouses, Notebooks, ML-Serving-Endpunkte und mehr. Die Plattform startet täglich zig Millionen VMs auf AWS, Azure und GCP.

Bevor ein Serverless-Workload ausgeführt werden kann, muss die VM ihre Netzwerkkonfiguration kennen: Auf welche Speicherziele kann sie zugreifen? Gibt es Private-Link-Endpunkte, über die der Datenverkehr geleitet werden soll? Gibt es aktuelle Änderungen in Unity Catalog, die Zugriff auf neue Speicherziele gewähren? Beginnen wir mit der Nutzung neuer Ziele, die über Delta Sharing freigegeben wurden?

Die Herausforderung besteht darin, dass die Netzwerkkonfiguration nicht an einem einzigen Ort gespeichert ist. Sie muss aus mehreren Upstream-Diensten zusammengestellt werden, von denen jeder einen Teil zum Gesamtbild beiträgt.

Die alte Architektur

Im ursprünglichen Design rief unser Netzwerkkonfigurationsdienst bei jedem Start eines Serverless-Clusters synchron alle Upstream-Dienste auf, aggregierte deren Antworten, berechnete die Netzwerkkonfiguration pro Workspace und gab sie an die Serverless-Dataplane zurück. Dies geschah auf dem kritischen Pfad der Cluster-Erstellung.

Obwohl die alte Architektur einfach war und bei geringer Skalierung gut funktionierte, litt sie unter grundlegenden Problemen, die sich in den folgenden Metriken auf unserem Betriebs-Dashboard widerspiegelten:

1. Latenz: Da sich mehrere Upstream-Dienste auf dem kritischen Pfad befanden, betrug die RPC-Latenz für die Bereitstellung der Netzwerkkonfiguration 5.000 ms bei p99. Dies beeinträchtigte die Startlatenz von Serverless-Clustern.
2. Server-Erfolgsrate: Jeder Upstream-Dienst hat seine eigenen Verfügbarkeitsmerkmale. Bei mehreren hintereinander geschalteten Diensten sinkt die Gesamtverfügbarkeit schnell, was zu einer höheren Wahrscheinlichkeit von Startfehlern bei Serverless-Clustern pro Jahr führt.

Mit dem rasanten Wachstum der Serverless-Nutzung wurde das synchrone Modell zunehmend untragbar. Jeder synchrone Aufruf löste teure Operationen über alle Workspaces hinweg aus, was häufig zu doppelten Berechnungen führte. Dies verursachte eine zusätzliche Last, die proportional zur Anzahl der Tenants und ihrer konfigurierten Ressourcen anstieg.

Lösung: Ereignisgesteuerte Vorberechnung

Wir haben die Art und Weise, wie Databricks Netzwerkkonfigurationen bereitstellt, von Grund auf neu konzipiert. Sie basiert auf folgenden Kernprinzipien:

1. Ereignisgesteuerte Pipeline: Anstatt synchrone Aufrufe an alle Upstream-Dienste zu senden, abonniert das neue System Änderungsereignisse über eine Message Queue. Wenn ein Kunde eine neue Unity Catalog-Verbindung erstellt oder eine Netzwerkrichtlinie ändert, löst der Upstream-Dienst ein Ereignis aus. Das System verarbeitet dieses und aktualisiert die vorberechnete Konfiguration.
2. Snapshot-Vorberechnung: Netzwerkkonfigurationen werden asynchron im Hintergrund berechnet und in einem vorberechneten Snapshot-Speicher abgelegt. Der Bereitstellungspfad wird auf einen einzigen, schlanken Speicherabruf reduziert, der vollständig von den Upstream-Diensten entkoppelt ist.
3. Statische Stabilität: Im Falle eines Ausfalls eines Upstream-Dienstes können wir eine statische Konfiguration beibehalten und so eine statische Stabilität für die Serverless-Cluster gewährleisten.

Die Architektur trennt zwei Pfade sauber voneinander. Der Verwaltungspfad läuft asynchron im Hintergrund: Upstream-Dienste senden Änderungsereignisse an eine Message Queue, die von einem Ereignisprozessor verarbeitet wird, um zu ermitteln, welche Workspaces betroffen sind, und um Update-Benachrichtigungen pro Workspace zu verteilen. Ein lokaler Ereignismanager ruft dann die relevanten Details vom Upstream ab, berechnet die Netzwerkkonfiguration des Workspaces neu und speichert das Ergebnis in einem vorberechneten Snapshot-Speicher. Ein periodischer Abgleichsdienst (Reconciler) synchronisiert zudem alle Workspaces im Hintergrund neu, um Eventual Consistency zu gewährleisten, selbst wenn Ereignisse verloren gehen. Der Bereitstellungspfad hingegen ist kritisch und schnell: Wenn ein Serverless-Cluster startet und eine Netzwerkkonfiguration benötigt, stellt der Netzwerkkonfigurationsdienst diese direkt aus dem Snapshot-Speicher mit einem einzigen Lesezugriff bereit. Dies erfordert keine Aufrufe von Upstream-Diensten und reduziert deren Last erheblich.

Wichtige Designentscheidungen

• Upstream-Dienste pushen Änderungsereignisse in die Message Queue. Das System verarbeitet diese Ereignisse im Hintergrund. Ein niederfrequenter Abgleichsdienst synchronisiert alle Workspaces regelmäßig als Sicherheitsnetz neu und bietet so die Zuverlässigkeit eines synchronen Frameworks gepaart mit der Effizienz von Push-Verfahren.
• Netzwerkkonfigurationen werden lokal innerhalb jeder Dienstpartition berechnet und gespeichert, direkt bei den Workspaces, die sie bedienen. Dies verteilt die Rechenlast, verringert den Schadensradius bei Vorfällen und eliminiert partitionsübergreifende Abhängigkeiten auf dem Bereitstellungspfad.
• Ereignisse enthalten nur Workspace- und Ressourcen-IDs. Dadurch bleiben die Ereignisse schlank, sind idempotent (sie können in beliebiger Reihenfolge wiederholt werden) und es wird vermieden, dass sensible Kundendaten über die Messaging-Pipeline übertragen werden.

Ablauf von Ereignissen

Wenn ein Kunde eine neue Unity Catalog-Verbindung erstellt, sendet Unity Catalog ein Änderungsereignis an die Message Queue. Der Ereignisprozessor empfängt das Ereignis, ermittelt, welche Workspaces mit dem betroffenen Metastore verknüpft sind, und verteilt eine Update-Benachrichtigung pro Workspace. In der Partition des jeweiligen Workspaces empfängt der Ereignismanager diese Benachrichtigung, ruft die aktualisierten Verbindungsdetails ab, berechnet die Netzwerkkonfiguration des Workspaces neu und speichert sie mit einer neuen Versionskennzeichnung. Ab diesem Zeitpunkt wird die Netzwerkkonfiguration bei einer Anfrage eines Serverless-Clusters direkt aus dem Snapshot-Speicher bereitgestellt, ohne dass Upstream-Aufrufe erforderlich sind.

Auswirkungen

Nach der Einführung der neuen Architektur zeigten sich bahnbrechende Ergebnisse bei allen Betriebskennzahlen:

Über die Hauptkennzahlen hinaus:

1. Das Upstream-Aufrufvolumen sank um 86 %. Das System ruft Upstream-Dienste nur dann auf, wenn ein Ereignis eine Änderung anzeigt, und nicht bei jeder Anfrage.
2. Wir konnten eine deutliche Verbesserung der Aktualität der Netzwerkkonfiguration feststellen.
3. Das veraltete synchrone Framework wurde vollständig abgelöst.

Fazit

Dieses Projekt hat uns einige Lehren über den Betrieb von Netzwerkinfrastrukturen im Cloud-Maßstab aufgezeigt:

Vorberechnung entkoppelt kritische Pfade. Durch das Verschieben aufwendiger Aggregationen in den Hintergrund wird der Bereitstellungspfad denkbar einfach und schnell. Dies ist die architektonische Entscheidung mit den größten Auswirkungen. Sie hat eine Abhängigkeitskette über mehrere Dienste hinweg in einen einzigen Speicherlesevorgang verwandelt.

Ereignisgesteuerte Architektur tauscht Konsistenz gegen Skalierbarkeit ein, und der Abgleich (Reconciliation) bietet das Sicherheitsnetz. Ereignisbasiertes Push verarbeitet den Regelfall effizient, während ein periodischer Abgleichsdienst alles auffängt, was durchs Raster fällt.

Design auf Erweiterbarkeit von Tag eins an. Dank der modularen, stufenbasierten Architektur erfordert die Unterstützung einer neuen Upstream-Datenquelle lediglich die Implementierung einer neuen Stufe – ganz ohne Änderungen an der Kern-Pipeline. Wenn sich die Produktpalette von Databricks erweitert, skaliert das Netzwerkkonfigurationssystem einfach mit.

Heute verarbeitet dieses System täglich Milliarden von Netzwerkkonfigurationsanfragen für die weltweite Serverless-Flotte von Databricks – mit einer Latenz von ca. 125 ms und einer Verfügbarkeit von 99,99 %. Da Serverless-Compute weiterhin rasant wächst, stellt die ereignisgesteuerte Architektur sicher, dass die Bereitstellung der Netzwerkkonfiguration direkt mitskaliert.

Wir sind immer auf der Suche nach Ingenieurinnen und Ingenieuren, die gerne Herausforderungen im Bereich verteilter Systeme auf globaler Ebene anpacken. Wenn dich solche Aufgaben begeistern, würden wir uns freuen, von dir zu hören. Schau dir einfach die offenen Stellen auf databricks.com/careers an!

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