Multi-Tenant-SaaS-Architektur: Isolation, Abrechnung, KI-Funktionen und Skalierungsoptionen

Dieser technische Artikel richtet sich an CTOs, Architekten und Senior Engineers, die ein SaaS-Produkt entwerfen oder eines überarbeiten, das über sein erstes Design hinausgewachsen ist. Unser SaaS-Plattform-Engineering-Leitfaden stellt die Silo-, Pool- und Bridge-Mandantenmodelle sowie die Control Plane vor; dieser Artikel geht eine Ebene tiefer: wie Isolation auf jeder Schicht durchgesetzt wird, wie Daten partitioniert werden, wie die Abrechnung verdrahtet ist, wie KI-Funktionen innerhalb der Tenant-Grenzen bleiben und wie die Plattform skaliert. Marktplätze werden in Marktplatz-Plattformarchitektur behandelt.

Kontext: Tenants, Benutzer und Deployments

Beginnen Sie mit der Definition des Tenants. In Business-to-Business-SaaS ist ein Tenant in der Regel eine Kundenorganisation mit vielen Benutzern; manche Kunden benötigen mehrere Tenants, zum Beispiel separate Tochtergesellschaften oder separate Test- und Produktionsumgebungen. In Business-to-Consumer-Produkten kann ein Tenant eine einzelne Person, eine Familie oder eine Gruppe sein. Microsofts Azure Architecture Center weist darauf hin, dass diese Definition – und ob ein Mandantenmodell für Kunden akzeptabel ist – eine kommerzielle Entscheidung ist, ebenso wie eine technische.

Trennen Sie den logischen Tenant vom Deployment, das ihn bedient. Ein Deployment, manchmal auch Stamp genannt, ist ein Satz Infrastruktur. Viele Tenants können ein Deployment gemeinsam nutzen, oder ein Tenant kann sein eigenes haben. Eine Tenant-zu-Deployment-Zuordnung von Beginn an zu führen ermöglicht es Ihnen, Tenants später zwischen Deployments zu verschieben, ohne die Anwendung neu zu schreiben.

Isolation wird je Schicht entschieden

Das AWS-Whitepaper zu SaaS-Tenant-Isolationsstrategien bezeichnet Isolation als grundlegend für das SaaS-Design und beschreibt das Überschreiten einer Tenant-Grenze als potenziell nicht wiederherstellbares Ereignis für das Unternehmen. Microsoft beschreibt Isolation als Spektrum statt als einzelnen Schalter. In der Praxis erhält jede Schicht ihre eigene Antwort:

Ein verbreitetes und sinnvolles Ergebnis ist ein gepoolter Application-Tier mit isolierten Daten für die Tenants, die dies benötigen. Microsoft bezeichnet das Aufteilen bestimmter Komponenten je Tenant bei gleichzeitiger gemeinsamer Nutzung anderer als horizontale Partitionierung; ausgewählten Tenants ein vollständiges dediziertes Deployment zu geben als vertikale Partitionierung.

Optionen zur Datenpartitionierung

Bei einer gepoolten Datenbank sollte die Isolation in der Datenbank selbst erzwungen werden, nicht nur im Anwendungscode. PostgreSQLs Zeilensicherheitsrichtlinien sind ein Weg: Sobald sie für eine Tabelle aktiviert sind, werden Zeilen verborgen, es sei denn, eine Richtlinie erlaubt sie – eine Abfrage ohne Tenant-Filter gibt also nichts zurück statt alles. Zwei Details sind wichtig. Richtlinien müssen je Tabelle aktiviert werden, und Tabelleneigentümer, Superuser sowie Rollen mit dem BYPASSRLS-Attribut umgehen sie standardmäßig. Die Anwendung sollte sich daher mit einer Rolle verbinden, die die Tabellen nicht besitzt, oder die Tabellen sollten Row Security erzwingen, damit die Richtlinien auch für den Eigentümer gelten.

Architektur für Abrechnung und Metering

Abrechnung in Multi-Tenant-SaaS ist eine Pipeline, keine einzelne Integration.

KI-Funktionen: Datenisolation und Modellkosten je Tenant

Assistenten, KI-Suche und Zusammenfassungen lesen in einer einzigen Anfrage mehr Tenant-Daten als die meisten Masken, daher benötigen sie dieselben Grenzen, die an denselben Stellen erzwungen werden. KI-Governance legt die dahinterliegende Richtlinie fest.

• Abruf außerhalb des Prompts filtern. Der Abrufdienst wendet den Tenant und die Benutzerberechtigungen aus dem Sitzungskontext an. Eine Prompt-Anweisung wie "Verwende nur die Daten dieses Kunden" ist keine Isolation.
• Jeden KI-Cache nach Tenant schlüsseln. Gecachte Antworten und Embeddings ohne Tenant-Schlüssel können die Inhalte eines Kunden einem anderen zurückgeben.
• Tenant-Daten aus gemeinsamen Trainings heraushalten. Kein Feintuning eines gemeinsamen Modells auf die Daten eines Tenants; wählen Sie Modellanbieter, deren Bedingungen ein Training auf Ihre Anfragen ausschließen. Regulierte Tenants benötigen möglicherweise eine Region oder ein dediziertes Modell-Deployment.
• Modellkosten je Tenant erfassen. Tokens und Aufrufe variieren stark zwischen Tenants; ordnen Sie sie je Feature zu und setzen Sie Limits über Berechtigungen durch.
• Beim Offboarding löschen. Embeddings, Indizes und protokollierte Prompts eines abgehenden Tenants werden zusammen mit seinen Datenbankzeilen entfernt.

Skalierungsoptionen

Planen Sie den Tenant-Migrationspfad frühzeitig: wie die Daten eines Tenants von der gemeinsamen Datenbank in eine eigene wechseln, wie der Traffic umgeschaltet wird und wie das Ergebnis verifiziert wird. Es ist einfacher, dies früh zu entwerfen als auf Abruf zu erfinden.

Betrieb: Releases, Migrationen und Wiederherstellungen

• Releases in Ringen ausrollen. Zunächst an interne Tenants, dann an einen kleinen Anteil der Kunden, dann an alle – mit tenant-spezifischen Feature-Flags.
• Schema-Migrationen über die gesamte Fleet automatisieren. Bei Schema-per-Tenant oder Datenbank-per-Tenant bedeutet ein Release viele Migrationen; verfolgen Sie, welcher Tenant auf welcher Version ist.
• Einen Tenant wiederherstellen, nicht nur die gesamte Plattform. Kunden werden die Wiederherstellung der Daten eines einzelnen Tenants anfordern; testen Sie dies, bevor sie es tun.
• Kosten je Tenant messen. Kombinieren Sie Metering mit der Cloud-Rechnung, um zu sehen, welche Tenants und Pläne ihre Kosten decken.

Testnachweis: Was zu testen ist

Dies sind allgemeine Engineering-Praktiken, keine Ergebnisse aus einem bestimmten Projekt:

• Mandantenübergreifende Zugriffstests. Automatisierte Tests für jeden Endpunkt und Job, die versuchen, die Daten eines anderen Tenants zu lesen oder zu ändern, und fehlschlagen müssen.
• Zeilenrichtlinien-Tests. Abfragen, die ohne Tenant-Kontext ausgeführt werden, müssen keine Zeilen zurückgeben – auch unter der Datenbankrolle der Anwendung.
• Noisy-Neighbour-Lasttests. Ein Tenant erzeugt hohe Last, während die Antwortzeiten der anderen gemessen werden.
• Einzeltenant-Wiederherstellungstests. Einen Tenant aus einem Backup in eine saubere Umgebung wiederherstellen und die Datensätze vergleichen.
• Metering-Tests. Wiederholte und duplizierte Ereignisse müssen dieselben Nutzungssummen ergeben.
• Mandantenübergreifende KI-Tests. Ein Assistent, der nach den Datensätzen eines anderen Tenants gefragt wird, muss nichts finden – auch nicht über gecachte Antworten.

Die umfassenderen Prüfungen finden sich in unserer SaaS-Sicherheits-Checkliste.

Beispiel: Printcart

Printcart, eine der fünf Netbase Business Divisions, ist eine Web-to-Print- und Print-on-Demand-Plattform, die Online-Bestellungen in druckfertige Dateien und geroutete Auftragsabwicklung umwandelt. Sie läuft im eigenen Shop eines Händlers oder als Shopify-, Wix- und WooCommerce-App, mit einer Einrichtung in etwa 7 Tagen, und bedient 2.000+ Shops. So viele Händler von einem Produkt aus zu bedienen ist das Multi-Tenant-Problem, das dieser Artikel beschreibt: Jeder Händler benötigt seinen eigenen Katalog, seine eigenen Bestellungen und seine eigene Shop-Anbindung auf einer gemeinsamen Plattform. Der Printcart-Portfolioeintrag beschreibt, was Netbase entwickelt hat und betreibt, und Druck und Verpackung zeigt den Branchenkontext.

Außerhalb eigener Produkte arbeitet Netbase seit 2020 als Offshore-Entwicklungs- und Managing-Partner an einem Multi-Tenant-Cloud-ERP für einen nicht genannten US-Kunden, das als SaaS an kleine und mittelständische Unternehmen verkauft wird.

Netbases Ansatz bei Multi-Tenant-Projekten

Netbase arbeitet mit AWS, Google Cloud, DigitalOcean und Cloudflare; es wird kein Cloud-Partner-Tier oder Cloud-Zertifizierung beansprucht. Typische Zeitrahmen sind 8 bis 12 Wochen für ein SaaS-MVP, 3 bis 6 Monate für ein Mid-Tier-Produkt und 6 bis 12 Monate oder mehr für eine Enterprise-Plattform, je nach Umfang; dies sind Spannen, keine Angebote. Sicherheit wird von Beginn des ersten Sprints an eingebaut: Secure Code Review, TLS im Transit und AES im Ruhezustand, rollenbasierte Zugriffskontrolle, MFA für Admin-Dashboards, Schwachstellen-Scanning und Disaster-Recovery-Planung. KI-Modelle werden je Produkt ausgewählt, nicht an einen Anbieter gebunden. Der Service SaaS-Entwicklung baut das Produkt, und der SaaS-Produkt-Accelerator startet mit wiederverwendbaren Modulen für Konten, Tenants, Rollen und Abrechnung.

Grenzen dieses Artikels

• Er beschreibt gängige Muster und allgemeine Praxis; der richtige Mix hängt von Ihren Tenants, Daten, Regionen und Kundenverträgen ab.
• Das zitierte AWS-Whitepaper ist von AWS als historische Referenz gekennzeichnet; seine Isolationsprinzipien sind weiterhin weit verbreitet, aber prüfen Sie die aktuelle AWS-Dokumentation für servicespezifische Details.
• PostgreSQL wird als ein Beispiel für datenbankerzwungene Isolation verwendet; andere Datenbanken bieten unterschiedliche Mechanismen.
• Zeitrahmen sind typische Spannen. Printcart wird anhand seiner veröffentlichten Produktinformationen beschrieben; hier werden keine Performance-Metriken beansprucht.

Nächster Schritt

Teilen Sie uns Ihr Tenant-Profil, Ihre Datensensitivität und Ihr Preismodell mit, und wir vereinbaren ein Solution-Review, um das Isolations- und Abrechnungsdesign für Ihr erstes Release auszuwählen. Sie können auch den zugehörigen Service ansehen oder weitere Netbase-Insights durchstöbern.

Verwandte Leistungen und Lösungen