Mandantenfähige Architektur bei SaaS: Drei Ansätze und Auswahlkriterien
Wie werden in einem SaaS-Produkt die Daten jedes Kunden von denen der anderen getrennt? Die Ansätze gemeinsames Schema, eigenes Schema und eigene Datenbank im Vergleich nach Isolation, Kosten und Betrieb.
Alp3 Min. Lesezeit
Bei SaaS-Produkten bedient eine einzige Anwendung eine Vielzahl von Kunden. Jeder Kunde wird als „Mandant“ (Tenant) bezeichnet, und seine Daten darf nur er selbst sehen. Wie die Daten der Mandanten getrennt werden, ist eine Architekturentscheidung, die Kosten, Sicherheit und Betriebsaufwand des Produkts über Jahre beeinflusst.
Drei grundlegende Ansätze
1. Gemeinsame Datenbank, gemeinsames Schema
Die Daten aller Mandanten liegen in denselben Tabellen; jede Zeile enthält ein Feld, das angibt, zu welchem Mandanten sie gehört. Jede Abfrage wird nach diesem Feld gefiltert. Dieser Ansatz ist am einfachsten einzurichten und zu betreiben und nutzt die Ressourcen am effizientesten.
Das Risiko besteht darin, dass eine einzige Abfrage, bei der die Filterung vergessen wurde, die Daten eines anderen Mandanten anzeigen kann. Dieses Risiko wird verringert, indem die Filterung nicht dem Anwendungscode überlassen, sondern auf Datenbankebene erzwungen wird; dafür wird zum Beispiel die Funktion für Sicherheit auf Zeilenebene (Row-Level Security) von PostgreSQL eingesetzt.
2. Gemeinsame Datenbank, eigenes Schema pro Mandant
Die Mandanten teilen sich denselben Datenbankserver, doch die Tabellen jedes Mandanten liegen in einem eigenen Schema. Die Isolation ist stärker, und es wird einfacher, die Daten eines einzelnen Mandanten aus dem Backup wiederherzustellen. Dafür wird es mit steigender Mandantenzahl schwieriger, Schemaänderungen auf alle Schemas anzuwenden.
3. Eigene Datenbank pro Mandant
Jeder Mandant hat seine eigene Datenbank. Die Isolation ist am höchsten; die intensive Nutzung eines Mandanten beeinträchtigt die anderen nicht, und Anforderungen wie die Speicherung der Daten in einer bestimmten Region lassen sich erfüllen. Der Preis dafür sind höhere Infrastrukturkosten und der Betriebsaufwand, den die Verwaltung einer Vielzahl von Datenbanken mit sich bringt.
Vergleich
| Kriterium | Gemeinsames Schema | Eigenes Schema | Eigene Datenbank |
|---|---|---|---|
| Datenisolation | Logisch | Stärker | Am stärksten |
| Kosten pro Mandant | Am niedrigsten | Mittel | Am höchsten |
| Schemaänderung | In einem Schritt | Für jedes Schema | Für jede Datenbank |
| Mandantenspezifisches Backup und Wiederherstellung | Schwierig | Einfach | Am einfachsten |
| Viele kleine Mandanten | Sehr gut geeignet | Eingeschränkt | Nicht geeignet |
| Wenige große Unternehmensmandanten | Kann ausreichen | Geeignet | Sehr gut geeignet |
Was bestimmt die Auswahl?
- Kundenprofil: Werden Sie Tausende kleiner Unternehmen bedienen oder wenige große Organisationen?
- Vertragliche und regulatorische Anforderungen: Machen Kunden zur Bedingung, dass ihre Daten physisch getrennt gespeichert werden?
- Grad der Individualisierung: Werden Mandanten nur Einstellungen ändern, oder werden sie eigene Felder und Workflows verlangen?
- Teamkapazität: Verfügen Sie über die Betriebskapazität, eine Vielzahl von Datenbanken zu überwachen und zu aktualisieren?
Hybrides Modell
Die Ansätze lassen sich auch gemeinsam einsetzen. Ein verbreitetes Muster ist, Kunden in den Standardpaketen in einem gemeinsamen Schema zu führen und Unternehmenskunden eine eigene Datenbank anzubieten. Damit das möglich ist, muss die Mandanteninformation von Anfang an in jeder Schicht der Anwendung mitgeführt werden.
Was über die Datenbank hinaus zu bedenken ist
- Identität und Berechtigungen: Es muss eindeutig feststehen, zu welchem Mandanten jede Sitzung gehört; können Nutzer mehreren Mandanten angehören, muss der Wechsel sicher umgesetzt sein.
- Ressourcenteilung: Die intensive Nutzung eines einzelnen Mandanten darf die anderen nicht verlangsamen. Dafür werden Anfragelimits und mandantenbezogene Kontingente für Hintergrundjobs eingesetzt.
- Dateien und Cache: Die Isolation muss nicht nur in der Datenbank, sondern auch im Dateispeicher, im Cache und im Suchindex gewährleistet sein.
- Monitoring: Fehler- und Performance-Protokolle müssen die Mandanteninformation enthalten; andernfalls bleibt die Frage „Welcher Kunde war betroffen?“ unbeantwortet.
Für die meisten SaaS-Produkte ist das gemeinsame Schema der richtige Einstieg; wichtig ist, es so aufzubauen, dass ein späterer Wechsel zu einer eigenen Datenbank nicht verbaut wird.
Um die Architektur Ihres Produkts gemeinsam zu planen, können Sie sich unsere Leistung SaaS-Produktentwicklung ansehen.