Viele Mandanten – ein System: Multi-Tenant-Architektur in Software-Projekten
Anwendungen für viele Kunden benötigen eine Multi-Tenant-Architektur, bei der je nach Anforderung verschiedene Modelle infrage kommen.
(Bild: erstellt mit Midjourney durch iX)
- Kai Weingärtner
Der Trend zu Software-as-a-Service (SaaS) stellt Anbieter von Softwareanwendungen vor neue Herausforderungen. Wie kann man eine Anwendung kosteneffizient fĂĽr eine wachsende Anzahl von Kunden betreiben und gleichzeitig deren AnsprĂĽche an Performance, Sicherheit und Anpassbarkeit erfĂĽllen?
Eine klug gewählte Multi-Tenant-Architektur schafft die nötigen Strukturen. Die Tenants (zu Deutsch: Mandanten) teilen sich eine Anwendung mit anderen Tenants, wobei alle voneinander isoliert sind, sodass sich die Anwendung für den einzelnen Mandanten wie eine dedizierte verhält. Ein Tenant umfasst meist eine Gruppe von Nutzern, kann aber auch ein einzelner Nutzer sein. Im B2B-Kontext ist er häufig ein Unternehmen, während es im B2C-Umfeld auch eine einzelne Anwenderin oder ein einzelner Anwender sein kann.
Ein typischer Treiber für die Einführung von Multi-Tenancy ist der Weg von installierter Software hin zu einem Software-as-a-Service-Geschäftsmodell. Im Gegensatz zu pro Kunde installierter Software oder Managed-Service-Angeboten wird eine Multi-Tenant-Anwendung als ein einzelnes Produkt entwickelt und betrieben.
Der Mehrwert liegt im reduzierten Wartungs- und Betriebsaufwand, wenn eine Version für viele Kunden arbeitet. Zudem verteilen sich die Kosten für die Infrastruktur auf die Kunden. Die Herausforderung liegt jedoch darin, die Komplexität des Multi-Tenant-Betriebes nicht auf die Service-Entwicklung durchschlagen zu lassen und gleichzeitig den Anforderungen in Bezug auf Daten- und Performance-Isolation sowie Infrastruktur- und Betriebseffizienz gerecht zu werden.
Vorüberlegungen – Anforderungen und Kundenwünsche
Es gibt einige Fragen, die Architektinnen und Architekten früh klären sollten, da sie das Design deutlich beeinflussen. Wichtig ist, welche Kunden die Anwendung ansprechen soll und welche Anforderungen diese stellen. In bestimmten Branchen gibt es darüber hinaus regulatorische Vorgaben. Wenn Kunden eine dedizierte Infrastruktur wünschen oder konkrete Performance-Erwartungen haben, müssen die Architekten genau prüfen, welche Ressourcen sie trennen oder teilen können.
Außerdem spielen die Anzahl der Mandanten und die Datenmengen eine große Rolle. Können sich die Tenants ein gemeinsames Datenschema performant teilen? Stoßen die Provider-Ressourcen an ein Limit, wenn jeder Tenant eine separate Datenbankinstanz erhält? Reicht der manuell gestützte Onboarding-Prozess aus oder muss er vollautomatisch geschehen?
Auch das geplante Abrechnungsmodell kann die Architektur beeinflussen, insbesondere was die Ăśberwachung angeht. Eine Monatspauschale mit Request-Kontingent erfordert andere Metriken als eine Berechnung nach Nutzerzahl.
Zuletzt sollten Planerinnen und Planer auch den Bedarf an Customizing grob abstecken: Wenn der Kunde ein individuelles Styling erwartet, ist das ein Teil der Tenant-Konfiguration. Wie flexibel muss die Anwendung bei der Integration von Drittsystemen sein, zum Beispiel einem kundeneigenen Identity Provider? Ein klares Zielbild hilft hier, die richtigen Weichen zu stellen.
Silos, Pools und alles dazwischen
Multi-Tenancy muss nicht bedeuten, dass sich die Mandanten alle Anwendungsressourcen und die komplette Infrastruktur teilen, sondern heiĂźt nur, dass die Gesamtanwendung als ein einzelnes Produkt dasteht. Daher sind folgende Modelle im Einsatz: das Silo-Modell, das Pool-Modell und Mischformen aus beiden, wie das Bridge-Modell (siehe Abbildung 1).
Das Silo-Modell weist jedem Tenant eine dedizierte Infrastruktur zu, zum Beispiel eine Datenbankinstanz oder eine eigene VM fĂĽr die Anwendungslogik. Auch wenn die Infrastruktur hier nicht besonders kosteneffizient ist, hat dieser Ansatz einige VorzĂĽge: Infrastrukturkosten lassen sich jedem Mandanten einfach zuordnen und die Datenisolation ist automatisch gegeben. Lokale Entwicklerinnen und Entwickler behandeln die Anwendung wie eine Single-Tenant-Anwendung. Dadurch ergibt sich ein einfacherer Migrationspfad fĂĽr bestehende, als klassische Single-Tenant-Produkte gestartete Anwendungen.
Ein Nachteil neben den Kosten ist, dass Admins beim Onboarding von Tenants Infrastruktur provisionieren mĂĽssen. Das heiĂźt, die Bereitstellung muss automatisiert sein, um Wildwuchs zu vermeiden. Das Deployment von Updates nimmt hier ebenfalls mehr Zeit in Anspruch, erlaubt aber sukzessive Rolling-Updates und Canary-Releases.
Beim Pool-Modell teilen sich alle oder mehrere Mandanten eine Infrastruktur. Die Tenant-Isolation erfolgt hier im Code, während die gemeinsame Nutzung der Infrastruktur die Kosten minimiert und Deployments beschleunigt. Jedoch muss man sich mit dem Noisy-Neighbor-Problem auseinandersetzen, bei dem ein Mandant so viele Ressourcen nutzt, dass er andere beeinträchtigt. Bei Kunden, die eine zugesicherte Performance erwarten, sollte daher eine Performance-Isolation zum Einsatz kommen. Außerdem ist zu prüfen, ob die Ressourcen beispielsweise einer Datenbankinstanz an ihre Skalierungslimits stoßen.
Oft ist auch eine Kombination von Silo- und Pool-Modellen sinnvoll, zum Beispiel im Service-Layer ein Pool und im Database-Layer ein Silo, was eine hohe Datenisolation mit Kostenersparnis verbindet. Dieses Modell wird auch Bridge-Modell genannt. In einer Microservices-Architektur können sich auch einzelne Services im Modell unterscheiden, wenn etwa ein Silo-Modell nur bei Services mit hohen Isolationsanforderungen (etwa Zahlungsdaten) notwendig ist.
Die Wahl des Modells grĂĽndet sich auf vielen Faktoren und hat weitreichende Implikationen bei der Umsetzung. Sofern keiner der genannten Faktoren dagegen spricht, ist das Pool-Modell aufgrund der Effizienz die erste Wahl.
Die Control Plane und ihre Aufgaben
Der erste Blick beim Design einer Multi-Tenant-Architektur fällt oft auf Aspekte wie die Datenisolation oder die Skalierung der Services. Hinzu kommen aber eine Reihe von Aufgaben rund um Lebenszyklus und Betrieb der Mandanten, was die Admins unabhängig von der Fachlichkeit einheitlich und zentral steuern müssen.
Diese Aufgaben sollte eine Control Plane abbilden, die parallel zur Anwendung (in diesem Kontext auch Data oder Application Plane genannt) arbeitet (siehe Tod Golding: Building Multi-Tenant Saas Architectures; 2024). Je stärker die Zahl der Tenants wächst, umso wichtiger wird die Control Plane, um die zentrale Steuerung der Mandanten zu gewährleisten (siehe Abbildung 2).
Eine weitere Funktion der Control Plane ist das Onboarding von Tenants. Dieses generiert Metadaten wie einen Tenant Identifier, die es erlauben, Anfragen richtig zu routen. Bei einer Silo-Datenbank kämen weitere hinzu, wie die Verbindungsparameter zur Datenbank. Anschließend erfolgt eine Provisionierung der spezifischen Infrastruktur und der Konfiguration. Bei einer Automatisierung baut diese im Silo-Modell eine neue Datenbank auf und legt einen neuen User-Pool für User-Identities, also einzelne Nutzer innerhalb eines Tenants, an. Ein früher, einheitlich automatisierter Onboarding-Prozess ist sinnvoll, da sonst mittelfristig der Wartungsaufwand steigt und dem Mehrwert von Multi-Tenancy zuwiderläuft.
User-Identities sind insofern relevant fĂĽr die Control Plane, als dass diese darĂĽber die Tenant-Beziehung herstellt und somit Tenant-Metadaten der Application Plane zur VerfĂĽgung stellen kann.
Eine Billing-Komponente der Control Plane verwaltet die Abrechnungspläne der Kunden und bezieht bei Bedarf Nutzungsstatistiken der Mandanten von der Metrik-Komponente. Metriken und Log-Aggregation sind zudem für mandantenspezifische Nutzungs- und Fehleranalysen wichtig. Dazu liefern die Services der Application Plane immer eine Tenant-Id zur Identifikation in Logs und Metriken mit.
(Bild: iX)
Dieser Artikel ist auch im iX/Developer-Sonderheft zu finden, das sich an Softwarearchitektinnen und Softwarearchitekten richtet. Neben den klassischen Architekturinhalten zu Methoden und Pattern gibt es Artikel zu Soziotechnischen Systemen, Qualitätssicherung oder zu Architektur und Gesellschaft. Domain Driven Design ist ebenso ein Thema wie Team Topologies und Sicherheit.
Als Autoren konnten wir bekannte Experten gewinnen, die ihr Wissen in vielen spannenden Artikeln – wie dem hier vorliegenden – sowohl für Architektureinsteiger als auch Spezialisten weitergeben.
