Reverse ETL vs. Private Cloud: Ein konzeptioneller Überlebensleitfaden

Reverse ETL vs. Private Cloud: Ein konzeptioneller Überlebensleitfaden

Wenn eine „unaufhaltsame Kraft“ auf ein „unbewegliches Objekt“ trifft"

Moderne Datenarchitekturen verfolgen häufig ein gemeinsames Ziel: Warehouse-Daten für die Teams verfügbar zu machen, die sie benötigen. Bei strengen Netzwerksicherheitsvorgaben kommt es dabei jedoch schnell zu einem Patt.

Auf der einen Seite steht Segment Reverse ETL, das einen öffentlich erreichbaren HTTPS-Endpunkt benötigt. Auf der anderen Seite steht ein Databricks SQL Warehouse, das sicher in einem privaten Azure Virtual Network (VNet) abgeschirmt und aus dem öffentlichen Internet nicht erreichbar ist.

Daraus ergaben sich zwei zentrale Einschränkungen:

• Segment benötigt einen öffentlich zugänglichen HTTPS-Endpunkt.
• Das Databricks SQL Warehouse war nicht öffentlich zugänglich.

Damit waren die Anforderungen an die Konnektivität nicht mit der Netzwerkisolierung vereinbar. Eine direkte Integration war daher nicht möglich. Die Sicherheitsvorgaben sagen: „Kein öffentlicher Zugriff“. Segment sagt „Ich kann dich nicht sehen“. Also haben wir eine Brücke zwischen beiden gebaut, ohne die Regeln zu brechen.

Segment Reverse ETL in Aktion: Drei Wege zum Scheitern (und einer zum Erfolg)

Um diese Herausforderung zu anzugehen, haben wir im Rahmen des Proof of Concept (POC) mehrere Ansätze bewertet. Es klappte nicht gleich beim ersten Versuch. Wir nutzten den POC als Sprint, um die konkreten Hindernisse in der Verbindungskette zu identifizieren. Jeder Schritt zeigte uns genauer, was für eine funktionierende Lösung erforderlich war.

Direkter Verbindungsversuch

Zuerst versuchten wir den direkten Weg. Wir haben versucht, Segment Reverse ETL direkt mit dem Databricks SQL Warehouse zu verbinden.

• Das Ergebnis?Absolute Funkstille.
• Die Erkenntnis: Mit einem Server, der nicht auf der Gästeliste steht, gibt es keinen „Handshake“. Private Endpunkte sind nicht ohne Grund privat.

Der Versuch scheiterte aus zwei Gründen:

• Databricks war nicht öffentlich erreichbar.
• Segment konnte private Endpunkte nicht erreichen.

Damit war klar: Eine direkte Verbindung ist in einer privaten Netzwerkumgebung nicht möglich.

Als Nächstes testeten wir den Databricks-Connector von Segment mit der Standardkonfiguration.

Standardkonfiguration des Connectors

Im nächsten Versuch verwendeten wir den Databricks-Connector von Segment mit der Standardkonfiguration. Dabei stießen wir sofort auf zwei Hindernisse:

OAuth-Inkompatibilität: Segment erwartete einen bestimmten Authentifizierungsablauf (Basic/Client Credentials), während Databricks einen vollständigen OAuth-Handshake verlangte, mit dem der aktuelle Connector noch nicht umgehen konnte.

Der Hostname-Filter: Der Databricks-Treiber ist wählerisch. Mit einer strings.Contains-Prüfung sucht er im Hostnamen nach azuredatabricks.net. Fehlt dieser Bestandteil, versucht der Treiber gar nicht erst, eine Verbindung herzustellen.

Um schnell voranzukommen, erwies sich eine externe Proxy-Schicht als der praktikabelste Ansatz.

Benutzerdefinierter Hostname und DNS-Zuordnung

Um die Validierungsanforderungen des Connectors zu erfüllen, haben wir einen benutzerdefinierten Hostnamen eingerichtet, der azuredatabricks.net enthielt.

Beispiel:

• dev.staging.azuredatabricks.net.<custom-domain>

Diesen Hostnamen haben wir der öffentlichen IP-Adresse von Azure Application Gateway zugeordnet.

Damit war Folgendes gewährleistet:

• erfolgreiche DNS-Auflösung
• Kompatibilität mit der Hostname-Validierung des Connectors

Außerdem haben wir das Verhalten des Databricks-SQL-Treibers berücksichtigt:

• Der Treiber ermittelt den Cloud-Provider-Kontext anhand des Hostnamens.
• Da er mit strings.Contains nach einer Teilzeichenfolge sucht, konnten wir einen gültigen Hostnamen verwenden und die Anfragen trotzdem über unsere eigene Infrastruktur weiterleiten.

Dieser Ansatz allein reichte jedoch nicht aus:

• Es gab keine Back-End-Logik zur Verarbeitung der Anfragen.
• Die Authentifizierungslogik war noch nicht implementiert.
• Es fehlte eine Logik zum Weiterleiten und Transformieren von Anfragen.

Damit war klar: Die passende DNS-Konfiguration war für die Validierung notwendig, reichte für die eigentliche Integration aber nicht aus.

Ansatz nur mit Application Gateway

Wir haben Azure Application Gateway hinzugefügt, um den öffentlichen Ingress zu verarbeiten. Damit war das „Sichtbarkeitsproblem“ gelöst. Für den komplexen Token-Austausch mit Databricks fehlte dem Gateway jedoch die nötige Logik.

Application Gateway übernahm erfolgreich folgende Aufgaben:

• öffentlicher Ingress
• TLS-Terminierung
• Anforderungsrouting

Der Ansatz scheiterte jedoch aus folgenden Gründen:

• Application Gateway konnte keinen OAuth-Token-Austausch durchführen.
• Es konnte keine Authentifizierungsendpunkte bereitstellen.
• Es konnte keine Transformationen einzelner Anfragen durchführen.

Damit war klar, dass Routing allein für die Integration nicht ausreichte.

Authentifizierung und Routing über eine Proxy-Schicht

Wir haben einen benutzerdefinierten Proxy-Dienst eingerichtet, um die Lücken bei Authentifizierung und Konnektivität zwischen Segment und Databricks zu schließen.

Der Proxy wurde so konzipiert, dass er die Anforderungen von Segment erfüllt und gleichzeitig sicher mit Databricks kommuniziert.

Authentifizierungsschicht

• Stellt OIDC-kompatible Endpunkte bereit:
• /oidc/v1/token
• /oidc/.well-known/oauth-authorization-server
• /oidc/jwks.json
• Akzeptiert die Basic-Authentifizierung von Segment
• Stellt signierte JWT-Tokens (RS256) aus.
• Validiert eingehende JWT-Tokens mithilfe öffentlicher und privater Schlüsselpaare.
• Verwaltet den Lebenszyklus der Tokens mithilfe eindeutiger Kennungen (jti).

Token-Austausch mit Databricks

• Ruft mit dem client_credentials-Flow Zugriffstokens von Databricks ab.
• Speichert Tokens zwischen, um wiederholte Authentifizierungsanfragen zu vermeiden.
• Ersetzt die vom Proxy ausgestellten eingehenden Tokens durch gültige OAuth-Tokens von Databricks.

Schicht zur Anfrageweiterleitung

• Leitet Anfragen an die Databricks-Endpunkte (/api, /sql) weiter.
• Normalisiert Header und entfernt widersprüchliche Header vor der Weiterleitung.
• Stellt die Kompatibilität mit den Databricks-SQL-APIs sicher.

Funktionen für den Betrieb

• Health-Endpunkt (/health) für das Monitoring
• TLS-Unterstützung für eine sichere Kommunikation
• Request-Tracing mit Einblick in die Latenzzeiten von Proxy und Upstream

Damit konnten wir folgende Probleme beheben:

• Probleme bei der Connector-Validierung
• Inkompatibilitäten bei der Authentifizierung
• Fehler bei der Abfrageausführung

Der Proxy fungierte damit als Übersetzungsschicht für die Authentifizierung und als kontrollierter Routing-Mechanismus.

Der Durchbruch: Der Proxy mit „Identitätswechsel“

Für den Durchbruch brauchten wir mehr als nur eine Leitung: Wir brauchten einen Übersetzer. Deshalb haben wir einen benutzerdefinierten Proxy-Dienst entwickelt, der zwischen dem Gateway und Databricks sitzt.

Das Erfolgsrezept

Unser Proxy nutzt ein wenig technische „Magie“, damit beide Seiten zusammenspielen:

• Die DNS-Maske: Wir haben dem Proxy einen benutzerdefinierten Hostnamen wie dev.staging.azuredatabricks.net.custom-domain.com gegeben. Da der Hostname die „magische Zeichenfolge“ enthielt, akzeptierte der Databricks-Treiber die Verbindung.
• Der Token-Austausch: Der Proxy stellt OIDC-kompatible Endpunkte bereit. Er verwendet die Zugangsdaten von Segment, holt bei Databricks ein „echtes“ OAuth-Token, speichert es für schnellere Zugriffe zwischen und fügt es in die Anfrage ein.
• Header-Bereinigung: Der Proxy bereinigt und normalisiert die Header während der Verarbeitung, sodass die Anfrage bei Databricks wie eine native Anfrage aussieht.

Die endgültige Architektur

Anfragefluss: