Datenisolierung in einer Tenant-Architektur auf der Google Cloud Platform (GCP)

Eine mandantenfähige Architektur, auch bekannt als Multi-Tenant-Architektur, ist eine Software-Architektur, bei der eine einzige Software-Instanz auf einem Server läuft und mehrere Mandanten bedient. Die Unterscheidung zwischen den Kunden wird während des Anwendungsdesigns getroffen, so dass die Kunden die Daten der anderen nicht teilen oder sehen. In den letzten Jahren war dies ein gängiges Muster, das Cloud-Anbietern half, die Kosten für die Infrastruktur zu senken.

Im Gegensatz dazu ist die Single-Tenancy-Architektur eine Architektur, bei der eine einzige Instanz der Softwareanwendung und der Infrastruktur für einen einzigen Kunden bestimmt ist, was zu einer stärkeren Isolierung führt.

Da die Kosten für die Cloud-Nutzung derzeit durch die On-Demand-Nutzung entstehen (bei BigQuery werden die meisten Kosten durch die Datenspeicherung und das Lesen von Bytes verursacht) und bei der Verwendung von serverlosen Lösungen wie Cloud Run, Cloud Functions keine Bereitstellung von Maschinen erforderlich ist, sollte die Tenant-Architektur von der On-Premise-Umgebung an die Cloud angepasst werden.

Vorwort

In diesem Artikel werde ich die Begriffe "Kunde" und "Mieter" synonym verwenden.

Dieser Artikel zeigt die Proportionen des Architekturdesigns auf hoher Ebene und die damit verbundenen Kompromisse auf.

Problemstellung

Nehmen wir an, Sie wurden gebeten, die Cloud-Architektur eines ganzen Startups zu entwerfen, das sich auf firmografische Datenanalyse und Prognosen spezialisiert hat und diese als Produkt verkauft. Das erste, was Sie brauchen, sind die Daten. Vorzugsweise firmenbezogene Daten von Ihren Kunden. Sie sind sich jedoch nicht sicher, welche Art von Daten verwendet werden soll und ob die Art der Daten bei allen Ihren Kunden gleich sein wird. Aufgrund dieser Ungewissheit brauchen Sie eine einfache Möglichkeit, die Daten zu analysieren.

Als erfahrener Dateningenieur wissen Sie, dass Daten organisiert werden müssen (am besten sogar katalogisiert).

Sie möchten auch auf die Abwanderung von Kunden vorbereitet sein, selbst wenn Sie sicher sind, dass Ihr Produkt die Welt der Datenanalyse revolutionieren wird und die Abwanderung marginal sein wird. Die Abwanderung von Kunden wurde lange Zeit nicht einmal als technisches Problem betrachtet, aber jetzt, wo es GDPR, CCPA und bald auch andere gesetzliche Einschränkungen geben könnte, muss eine durchdachte Datenarchitektur die Datenlöschung nach der Abwanderung unterstützen.

"Zero Trust Security", "Least-Privilege-Zugriff" sind keine Schlagworte und nicht nur reife Organisationen sollten diese Regeln befolgen. Sie wurden auch gebeten, ein feinkörniges Identitäts- und Zugriffsmanagement (IAM) in die Architektur einzubeziehen, vorzugsweise mit der Möglichkeit, dem Analyseteam in Zukunft einen temporären Zugriff auf die Daten zu ermöglichen.

Zusammenfassend lässt sich sagen, dass die Mieterarchitektur diese Probleme lösen muss:

Zum Glück für das Unternehmen entschied sich der CTO für die Google Cloud Platform als Cloud-Anbieter.

Lassen Sie uns nun einen Blick auf zwei mögliche Mieterarchitekturen werfen und prüfen, inwieweit sie die oben genannten Probleme lösen.

BigQuery Dataset Tenancy-Ansatz

Der erste Ansatz, der gut funktionieren könnte, ist "BigQuery-Datensätze pro Client zu trennen". Bei diesem Architekturdesign werden die Daten nicht vollständig isoliert. Eine mandantenübergreifende Datentrennung wird durch geeignete IAM-Einstellungen erreicht, da die Daten in einer einzigen BigQuery-Instanz verbleiben.

Die Idee dahinter ist recht einfach. Wenn sich ein neuer Kunde für ein Produkt registrieren möchte, wird eine eindeutige Kennung generiert: z.B. clever_beaver, sweet_borg usw. und ein neuer Datensatz wird in einem GCP-Projekt erstellt, das für die Speicherung von Mieterdaten ausgewählt wird (nennen wir es "Mieter-Produktion"). Dies kann mit einem einfachen Befehl geschehen:

bq --location=eu mk --dataset --label=tenant:clever_beaver --description="clever_beaver tenant dataset" tenants-production:clever_beaver

Lassen Sie uns nun die in der Einleitung aufgeworfenen Mietprobleme angehen:

Speichern Sie Daten auf eine leicht zu analysierende Weise

Die Speicherung von Daten in BigQuery macht die Analyse mit Standard-SQL, Geospatial Analysis, BigQuery ML und die Präsentation mit BigQuery BI Engine zum Kinderspiel.

Organisieren der Daten

Die Trennung nach BigQuery-Datensätzen klingt nicht nach der besten Art, Daten zu organisieren. Stellen Sie sich vor, der Kunde verwendet Dutzende von Quellen und jede davon hat Dutzende von individuellen Ressourcen (z.B. kann Google Ads individuelle Ressourcen haben wie: "Kampagnen", "Nutzer", "Anzeigen" usw.). Das führt zu Hunderten von Tabellen, ganz zu schweigen von Datenkuration, Berichten und Prognosetabellen.

Dateneingabe-Tools wie Fivetran oder Airbyte erzeugen viele Tabellen, und selbst wenn sie korrekt eingerichtet sind, kann es zu einem potenziellen Namenskonflikt kommen.

Bereiten Sie sich auf die Abwanderung von Kunden vor

Auf den ersten Blick wird die Antwort positiv ausfallen - löschen Sie einfach den Datensatz und das war's.

ABER!!! Ein gängiger Ansatz zum Laden von Daten in BigQuery basiert auf Google Cloud Storage (GCS). Wenn bei dem Prozess, der die Daten lädt, etwas schief geht, können die GCS-Dateien nicht bereinigt werden.

GUT! Legen Sie also einfach eine Lebenszyklusrichtlinie für GCS-Buckets fest, um Dateien nach einer bestimmten Zeit zu löschen. ABER!!! Die Plattform erfordert die Speicherung von Client-Geheimnissen auf dem System, von dem die Daten gesammelt werden.

OK! Um dieses Problem zu lösen, verwenden Sie einfach den Google Secret Manager und entfernen im Falle einer Abwanderung des Kunden alle Geheimnisse, die zu diesem Mieter gehören...

Hier ging es nicht darum, alle potenziellen Daten zu erkennen, die beim Löschen übersehen werden können, sondern vielmehr darum, hervorzuheben, dass es schwierig ist, sich an alle Teile eines Systems zu erinnern, in dem Kundendaten gespeichert sind, und diese vollständig zu löschen, ohne dass versehentlich weitere Kundendaten gelöscht werden.

Feinkörnige Kontrolle über den Zugriff auf Daten

Google bietet IAM auf Datensatz- und Tabellenebene. Nach einiger Zeit, wenn das Geschäft wächst und die Anzahl der Tabellen und Datensätze in die Tausende geht, wird die IAM-Verwaltung sehr problematisch. Die Lösung dafür ist die richtige IaC-Einrichtung, die jedoch zusätzlichen Aufwand erfordert (Sie können über IaC in unserem anderen Artikel).

Darüber hinaus benötigen Tools wie Fivetran oder Airbyte Lese- und Schreibzugriff auf den gesamten Datensatz. Dies ist problematisch, da die Rohdaten theoretisch in kuratierte oder benutzerseitige Tabellen geschrieben werden könnten.

Profis

Nachteile

GCP Projekt Mietansatz

Ein anderer Ansatz, der dringend empfohlen wird, ist die Trennung von Mandanten pro GCP-Projekt. Bei diesem Ansatz müssen Sie für jeden Mandanten separate GCP-Projekte erstellen. Die folgende Abbildung zeigt ein Beispiel dafür, wie die Infrastruktur von drei Mandanten (clever_beaver, sweet_borg, zen_wing) aussehen könnte.

Wie Sie sehen können clever_beaver Mieter-ID haben unique_prefix_clever_beaverGCP-Projekt und 4 Datensätze: source_paypal, source_google_ads, analyticsund analytics_forecast. Es könnte eine unbegrenzte Anzahl von Tabellen in jedem dieser Datensätze geben, ebenso wie es eine unbegrenzte Anzahl von Datensätzen in jedem GCP-Projekt geben könnte.

Auf der anderen Seite erfordert dieser Ansatz mehr Vorarbeit und die Benutzerregistrierung ist wesentlich komplizierter.
Die Erstellung der erforderlichen Infrastruktur ist kein schneller Prozess und kann einige Minuten dauern.

‌

Es sei darauf hingewiesen, dass dieser Ansatz mit Tausenden von Mietern funktionieren könnte, aber einen direkten Kontakt mit dem GCP-Support erfordert. Der Kontakt mit dem Support ist angenehm, aber er könnte Fragen zum Geschäft und zum geschätzten Umfang stellen. Die Verwaltung des Cloud-Kontingents ist ein schrittweiser Prozess und es ist leider sehr unwahrscheinlich, dass der GCP-Support das Kontingent in der ersten Iteration auf einen Wert setzt, der für den gesamten Lebenszyklus des Startups ausreicht.

Wie verwaltet man die Infrastruktur?

Um ein System zu schaffen, das auf diese Weise funktioniert, muss die Erstellung, Änderung und Löschung von Infrastrukturen automatisiert werden. IaC geht diese Probleme an, aber nicht direkt.

Nehmen wir an, dass es ein Terraform-Modul gibt, das alle erforderlichen und richtig benannten Ressourcen enthält: google_project, google_secret_manager_secret, google_service_account usw. Dann ist die einzige erforderliche Konfiguration, die an das Modul übergeben werden muss, eine Mieter-ID wie: cleaver_beaver.

Das Terraform-Modul mit den erforderlichen Ressourcen muss in der realen Infrastruktur ausgeführt werden. Hierfür gibt es mehrere Ansätze. In dem Diagramm unten sehen Sie einen, der den Cloud Build Service nutzt. Nach dem Empfang einer Pubsub-Nachricht mit der Tenant-ID im Body führt Cloud Build Trigger einen Job aus, der für die Ausführung von Terraform verantwortlich ist (oder Terragrunt, falls eine Trennung des Status erforderlich ist).

Eine prüfenswerte Erweiterung zu den reinen google_projects Ressourcen ist die GCP native Tenancy-Unterstützung, die derzeit die Erstellung von Projekten für jeden Tenant unterstützt.

‌

Bei der Entwicklung einer solchen Architektur ist es notwendig, zentralisierte Projekte in Betracht zu ziehen. Separate Projekte könnten den Cloud Monitoring Service enthalten, der Metriken über die Projekte der Mieter sammelt, den Artifact Registry Service, der benutzerdefinierte Docker-Images oder Pakete speichert, sowie Cloud Build für CICD. Separate übergeordnete GCP-Projekte für spezielle Zwecke sind mehr als willkommen.

Lassen Sie uns nun die in der Einleitung aufgeworfenen Probleme angehen:

Speichern Sie Daten auf eine leicht zu analysierende Weise

Es gibt keinen Unterschied zum vorherigen BigQuery Dataset Tenancy-Ansatz.

Organisieren der Daten

Die Trennung durch das GCP-Projekt ist großartig, da sie zwei Ebenen für die Kategorisierung von Datasets und Tabellen bietet. Zum Beispiel könnte der Datensatz `source_paypal` Tabellen haben, die paypal_transacions, paypal_balances und andere darstellen. Auch gängige Tools wie Fivetran oder Airbyte erzeugen neben den Ergebnisdaten viele Zwischentabellen. Diese Zwischentabellen würden nur ein Dataset überladen.

Bereiten Sie sich auf die Abwanderung von Kunden vor

Es gibt nur eine Regel, die befolgt werden muss. Wenn es Mieterdaten gibt, müssen diese in einem mandantenspezifischen GCP-Projekt gespeichert werden und nirgendwo sonst. Im Falle einer Abwanderung genügt es, das gesamte Projekt zu löschen. Dabei ist zu beachten, dass es sich um eine weiche Löschung handelt, d.h. nach 30 Tagen ist ein Rollback möglich.

Feinkörnige Kontrolle über den Zugriff auf Daten

Die IAM-Verwaltung kann auf der gesamten Projektebene erfolgen. Wenn Sie davon ausgehen, dass das Projekt im GCP-Ordner erstellt wird, ist es relativ einfach, Berechtigungen für eine bestimmte Google-Gruppe festzulegen. Das Datenanalyseteam hat beispielsweise Data Viewer-Berechtigungen für den gesamten Ordner, während das Ingenieursteam Berechtigungen für den Betrieb der Compute Engine haben könnte. Berechtigungen von der Ordnerebene werden auf die Projektebene vererbt.

Profis

Nachteile

Zusammenfassung

In diesem Artikel werden zwei Ansätze zur Organisation von Daten in einer Tenant-Umgebung unter Verwendung von BigQuery vorgestellt. Beide bringen Kompromisse mit sich, die Sie verstehen und berücksichtigen müssen. Unsere Kundenfallstudie zeigt, dass sich der GCP Project Tenancy Approach nach der Anfangsinvestition besser skalieren lässt. Außerdem war es zu Beginn hilfreich, schnell voranzukommen, da im Gegensatz zum BigQuery Dataset Tenancy Approach beim Experimentieren keine Reste übrig bleiben.

Der aktuelle Stand des Cloud Computing hat die Art und Weise, wie Anwendungen entwickelt werden, verändert. Heutzutage gibt es keine strikte Grenze mehr zwischen Single- und Multi-Tenancy, da das Lastmanagement für serverlose Dienste Sache des Cloud-Anbieters ist und sich die Cloud-Nutzer auf die Lösung von Geschäftsproblemen konzentrieren können. Deshalb ist die hybride Tenancy, die diese Ansätze miteinander verbindet, derzeit das gängige Muster.