Mandantenmuster für mehrinstanzenfähige SaaS-Datenbanken

Gilt für:Azure SQL-Datenbank

In diesem Artikel werden die verschiedenen Mandantenmodelle beschrieben, die für eine mehrinstanzenfähige SaaS-Anwendung verfügbar sind.

Wenn Sie eine mehrinstanzenfähige SaaS-Anwendung entwerfen, wählen Sie nach sorgfältiger Überlegung das Mandantenmodell aus, das den Anforderungen Ihrer Anwendung am besten gerecht wird. Ein Mandantenmodell legt fest, wie die Daten eines jeden Mandanten dem Speicher zugeordnet werden. Die Wahl des Mandantenmodells wirkt sich auf den Entwurf und die Verwaltung der Anwendung aus. Ein späterer Wechsel zu einem anderen Modell kann sich mitunter als kostspielig erweisen.

A. SaaS-Konzepte und -Terminologie

Im Software-as-a-Service-Modell (SaaS) verkauft Ihr Unternehmen keine Lizenzen für Ihre Software. Stattdessen zahlt jeder Kunde eine Leihgebühr an Ihr Unternehmen, sodass jeder Kunde ein Mandant Ihres Unternehmens wird.

Als Gegenleistung für die Leihgebühr erhält jeder Mandant Zugriff auf Ihre SaaS-Anwendungskomponenten, und seine Daten werden im SaaS-System gespeichert.

Der Begriff Mandantenmodell bezieht sich auf die Art und Weise, in der die gespeicherten Daten des Mandanten organisiert sind:

• Einzelinstanzenfähigkeit: Jede Datenbank speichert Daten eines einzelnen Mandanten.
• Mehrinstanzenfähigkeit: Jede Datenbank speichert Daten mehrerer Mandanten (mit Mechanismen zum Datenschutz).
• Hybride Mandantenmodelle sind ebenfalls verfügbar.

B. Vorgehensweise zum Auswählen des geeigneten Mandantenmodells

Das Mandantenmodell wirkt sich in der Regel nicht auf die Funktionsweise einer Anwendung aus, hat jedoch sehr wahrscheinlich Auswirkungen auf andere Aspekte der gesamten Lösung. Für die Bewertung der einzelnen Modelle werden folgende Kriterien herangezogen:

• Skalierbarkeit:

  • Anzahl der Mandanten
  • Speicher pro Mandant
  • Aggregierter Speicher
  • Workload

• Mandantenisolation: Datenisolation und Leistung (Auswirkungen der Workload eines Mandanten auf andere Workloads)

• Kosten pro Mandant: Datenbankkosten

• Komplexität der Entwicklung:

  • Änderungen am Schema
  • Änderungen an Abfragen (für das Muster erforderlich)

• Komplexität des Betriebs:

  • Überwachen und Verwalten der Leistung
  • Verwalten des Schemas
  • Wiederherstellen eines Mandanten
  • Notfallwiederherstellung

• Anpassbarkeit: Einfache Durchführung von speziell für Mandanten oder Mandantenklassen geltenden Schemaanpassungen

Die Informationen zu Mandanten beziehen sich hauptsächlich auf die Datenschicht. Im Folgenden sollten wir jedoch einen kurzen Blick auf die Anwendungsschicht werfen. Die Anwendungsschicht ist als monolithische Einheit zu betrachten. Wenn Sie die Anwendung in viele kleine Komponenten unterteilen, kann dies die Wahl Ihres Mandantenmodells ändern. Einige Komponenten können je nach Mandant sowie verwendeter Speichertechnologie oder Plattform unterschiedlich behandelt werden.

C. Eigenständige Einzelinstanz-App mit einer Einzelinstanzdatenbank

Isolation der Anwendungsebene

In diesem Modell wird die gesamte Anwendung mehrmals installiert, nämlich einmal pro Mandant. Da jede Instanz der App eine eigenständige Instanz darstellt, interagiert sie nie mit einer anderen eigenständigen Instanz. Jede App-Instanz umfasst nur einen Mandanten und erfordert daher nur eine Datenbank. Die gesamte Datenbank ist somit ausschließlich für den jeweiligen Mandanten bestimmt.

Jede App-Instanz wird in einer separaten Azure-Ressourcengruppe installiert. Die Ressourcengruppe kann einem Abonnement zugeordnet sein, das dem Softwarehersteller oder Mandanten gehört. In beiden Fällen kann der Hersteller die Software für den Mandanten verwalten. Jede Anwendungsinstanz ist so konfiguriert, dass sie eine Verbindung mit der entsprechenden Datenbank herstellt.

Jede Mandantendatenbank wird als Einzeldatenbank bereitgestellt. Dieses Modell ermöglicht die umfangreichste Datenbankisolation. Für die Isolation müssen jeder Datenbank jedoch genügend Ressourcen zugewiesen werden, damit Spitzenlasten verarbeitet werden können. Hier ist entscheidend, dass Pools für elastische Datenbanken nicht für Datenbanken verwendet werden können, die in verschiedenen Ressourcengruppen oder für verschiedene Abonnements bereitgestellt werden. Aufgrund dieser Beschränkung zählt dieses Modell einer eigenständigen Einzelinstanz-App hinsichtlich der gesamten Datenbankkosten zur teuersten Lösung.

Herstellerseitige Verwaltung

Der Hersteller kann auf alle Datenbanken in sämtlichen eigenständigen App-Instanzen zugreifen, auch wenn die App-Instanzen in unterschiedlichen Mandantenabonnements installiert sind. Der Zugriff erfolgt über SQL-Verbindungen. Mit einem solchen instanzübergreifenden Zugriff kann der Hersteller die Schemaverwaltung und die datenbankübergreifende Abfrage für Berichterstellungs- oder Analysezwecke zentralisieren. Falls diese Art der zentralen Verwaltung erforderlich ist, muss ein Katalog für die Zuordnung zwischen Mandanten-IDs und Datenbank-URIs bereitgestellt werden. Azure SQL-Datenbank stellt eine gemeinsam verwendete Shardingbibliothek für die Bereitstellung eines Katalogs bereit. Die Shardingbibliothek wird offiziell als Clientbibliothek für elastische Datenbanken bezeichnet.

D. Mehrinstanzenfähige App mit einer Datenbank pro Mandant

Beim nächsten Muster kommt eine mehrinstanzenfähige Anwendung mit vielen Einzelinstanzdatenbanken zum Einsatz. Für jeden neuen Mandanten wird eine neue Datenbank bereitgestellt. Die Logikschicht wird vertikal zentral hochskaliert, indem weitere Ressourcen pro Knoten hinzugefügt werden. Alternativ wird die App durch Hinzufügen weiterer Knoten horizontal erweitert. Die Skalierung basiert auf der Workload und hängt von der Anzahl oder dem Umfang der einzelnen Datenbanken ab.

Durchführen von Anpassungen für einen Mandanten

Wie beim Muster einer eigenständigen App ermöglicht auch die Verwendung von Einzelinstanzdatenbanken eine umfassende Mandantenisolation. In jeder App, deren Modell ausschließlich Einzelinstanzdatenbanken angibt, kann das Schema für eine bestimmte Datenbank an den jeweiligen Mandanten angepasst und entsprechend optimiert werden. Diese Anpassung wirkt sich nicht auf andere Mandanten in der App aus. Eventuell benötigt ein Mandant Daten, die über die standardmäßigen Datenfelder, die alle Mandanten benötigen, hinausgehen. Des Weiteren kann es sein, dass für das zusätzliche Datenfeld ein Index erforderlich ist.

Bei einer Datenbank pro Mandant lässt sich das Schema für einen oder mehrere einzelne Mandanten problemlos realisieren. Der Hersteller der Anwendung muss Verfahren entwerfen, um sorgfältig Schemaanpassungen im großen Maßstab zu verwalten.

Pools für elastische Datenbanken

Wenn Datenbanken in derselben Ressourcengruppe bereitgestellt werden, können sie in Pools für elastische Datenbanken gruppiert werden. Die Pools bieten eine kosteneffiziente Methode, um Ressourcen auf eine Vielzahl von Datenbanken aufzuteilen. Eine solche Pooloption ist günstiger, als die einzelnen Datenbanken so groß anzulegen, dass auftretende Verbrauchsspitzen verarbeitet werden können. Auch wenn Pooldatenbanken gemeinsam auf Ressourcen zugreifen, können sie dennoch einen hohen Grad an Leistungsisolation erzielen.

Azure SQL-Datenbank stellt die Tools zur Verfügung, die erforderlich sind, um die Freigabe zu konfigurieren, zu überwachen und zu verwalten. Sowohl Leistungsmetriken auf Pool- als auch auf Datenbankebene werden über das Azure-Portal und über Azure Monitor-Protokolle zur Verfügung gestellt. Die Metriken können umfassenden Einblick in die aggregierte und mandantenspezifische Leistung bieten. Einzelne Datenbanken können zwischen Pools verschoben werden, um einem bestimmten Mandanten reservierte Ressourcen zur Verfügung zu stellen. Durch diese Tools können Sie auf kosteneffiziente Weise eine hohe Leistung sicherstellen.

Skalierung des Betriebs für das Modell mit einer Datenbank pro Mandant

Azure SQL-Datenbank verfügt über viele Verwaltungsfeatures, die für die Verwaltung einer großen Anzahl von Datenbanken ausgelegt sind (z. B. weit über 100.000 Datenbanken). Aufgrund dieser Eigenschaften erweist sich das Muster mit einer Datenbank pro Mandant als sinnvolle Option.

Nehmen wir beispielsweise an, dass ein System ausschließlich auf einer Datenbank mit 1000 Mandanten basiert. Die Datenbank kann 20 Indizes enthalten. Wenn das System nun auf 1000 Einzelinstanzdatenbanken umgestellt wird, steigt die Zahl der Indizes folglich auf 20.000. Standardmäßig sind die automatischen Indizierungsfunktionen in Azure SQL-Datenbank im Rahmen der automatischen Optimierung aktiviert. Bei der automatischen Indizierung werden alle 20.000 Indizes sowie die entsprechenden laufenden Optimierungen im Hinblick auf Erstellungs- und Reduzierungsvorgänge für Sie verwaltet. Diese automatisierten Aktionen finden in einer einzelnen Datenbank statt und werden nicht durch ähnliche Aktionen in anderen Datenbanken koordiniert oder eingeschränkt. Die automatische Indizierung behandelt Indizes in einer ausgelasteten Datenbank anders als in einer weniger stark ausgelasteten Datenbank. Diese Art der Indexverwaltungsanpassung wäre bei manueller Ausführung einer derart umfangreichen Verwaltungsaufgabe im Hinblick auf eine Datenbank pro Mandant nicht praktikabel.

Zu anderen Verwaltungsfunktionen, die sich gute skalieren lassen, zählen Folgende:

• Integrierte Sicherungen
• Hochverfügbarkeit.
• Datenträgerverschlüsselung
• Leistungstelemetriedaten

Automation

Für die Verwaltungsvorgänge können Skripts erstellt werden, und sie können über ein DevOps-Modell zur Verfügung gestellt werden. Die Vorgänge können sogar automatisiert und in der Anwendung sichtbar gemacht werden.

Beispielsweise könnten Sie die Wiederherstellung eines einzelnen Mandanten zu einem früheren Zeitpunkt automatisieren. Bei der Wiederherstellung muss lediglich eine Einzelinstanzdatenbank wiederhergestellt werden, in der der Mandant gespeichert wird. Diese Wiederherstellung hat keine Auswirkungen auf andere Mandanten, was wiederum zeigt, dass Verwaltungsvorgänge in den einzelnen Mandanten auf hochgradig granularer Ebene stattfinden.

E. Mehrinstanzenfähige App mit mehrinstanzenfähigen Datenbanken

Ein weiteres verfügbares Muster besteht darin, viele Mandanten in einer mehrinstanzenfähigen Datenbank zu speichern. Die Anwendungsinstanz kann beliebig viele mehrinstanzenfähige Datenbanken umfassen. Das Schema einer mehrinstanzenfähigen Datenbank muss eine oder mehrere Spalten für die Mandanten-ID enthalten, damit die Daten eines beliebigen Mandanten selektiv abgerufen werden können. Zudem sind für das Schema eventuell einige Tabellen oder Spalten erforderlich, die nur von einer Teilmenge von Mandanten verwendet werden. Statische Codes und Referenzdaten werden jedoch nur einmal gespeichert und von allen Mandanten gemeinsam genutzt.

Eingeschränkte Mandantenisolation

Daten: Eine mehrinstanzenfähige Datenbank schränkt zwangsläufig die Mandantenisolation ein. Die Daten mehrerer Mandanten werden zusammen in einer Datenbank gespeichert. Achten Sie bei der Entwicklung darauf, dass bei Abfragen niemals Daten von mehr als einem Mandanten offengelegt werden. SQL-Datenbank unterstützt die Sicherheit auf Zeilenebene, wodurch erzwungen werden kann, dass die von einer Abfrage zurückgegebenen Daten auf einen einzelnen Mandanten beschränkt werden.

Verarbeitung: Eine mehrinstanzenfähige Datenbank teilt Compute- und Speicherressourcen auf alle seine Mandanten auf. Um einen ordnungsgemäßen Betrieb sicherzustellen, kann die gesamte Datenbank überwacht werden. Allerdings weist das Azure-System keine integrierte Option auf, um die Nutzung dieser Ressourcen durch einen einzelnen Mandanten zu überwachen oder zu verwalten. Daher besteht bei einer mehrinstanzenfähigen Datenbank ein höheres Risiko eines sogenannten „Noisy Neighbor“-Effekts, bei dem die Workload eines übermäßig aktiven Mandanten die Leistung anderer Mandanten in derselben Datenbank beeinträchtigt. Durch zusätzliche Überwachung auf Anwendungsebene kann die Leistung auf Mandantenebene überwacht werden.

Geringere Kosten

Im Allgemeinen weisen mehrinstanzenfähige Datenbanken die niedrigsten Kosten pro Mandant auf. Die Ressourcenkosten für eine Einzeldatenbank sind niedriger als die für einen gleichwertig großen Pool für elastische Datenbanken. Darüber hinaus können Millionen von Mandanten in Szenarien, in denen Mandanten nur einen begrenzten Speicher benötigen, eventuell in einer einzigen Datenbank gespeichert werden. Es gibt keine Pools für elastische Datenbanken, die Millionen von Datenbanken enthalten können. Eine Lösung mit 1000 Pools – wobei ein Pool 1000 Datenbanken enthält – kann jedoch eine Größenordnung in Millionenhöhe erreichen und damit eine umständliche Verwaltung nach sich ziehen.

Im Folgenden werden zwei Varianten eines mehrinstanzenfähigen Datenbankmodells erläutert, wobei das mehrinstanzenfähige Modell mit Sharding das flexibelste Modell mit der höchsten Skalierbarkeit darstellt.

F. Mehrinstanzenfähige App mit einer Einzelinstanzdatenbank

Das einfachste Muster einer mehrinstanzenfähigen Datenbank verwendet eine einzelne Datenbank, um Daten für alle Mandanten zu hosten. Bei einer steigenden Anzahl von Mandanten muss die Datenbank mit weiteren Speicher- und Computeressourcen zentral hochskaliert werden. Eine solche Hochskalierung könnte Abhilfe leisten, wobei es jedoch immer eine finale Begrenzung für die Skalierung gibt. Allerdings wird die Datenbankverwaltung lange vor Erreichen dieser Begrenzung zunehmend umständlicher.

Bei mehrinstanzenfähigen Datenbanken ist die Implementierung von Verwaltungsvorgängen, die sich auf einzelne Mandanten konzentrieren, komplexer. Mit steigender Größenordnung könnte dies dazu führen, dass diese Vorgänge unzumutbar langsam werden. Ein Beispiel ist die Point-in-Time-Wiederherstellung von Daten für nur einen Mandanten.

G. Mehrinstanzenfähige App mit mehrinstanzenfähigen Datenbanken mit Sharding

Die meisten SaaS-Anwendungen greifen auf die Daten von jeweils nur einem Mandanten zu. Bei diesem Zugriffsmuster können Mandantendaten auf mehrere Datenbanken oder Shards aufgeteilt werden, wobei alle Daten eines beliebigen Mandanten in einem Shard enthalten sind. In Kombination mit einem Muster einer mehrinstanzenfähigen Datenbank ermöglicht ein Modell in Shards eine nahezu unbegrenzte Skalierbarkeit.

Verwalten von Shards

Sharding erhöht die Komplexität sowohl im Hinblick auf den Entwurf als auch auf den Betrieb. Für die Verwaltung der Zuordnung zwischen Mandanten und Datenbanken ist ein Katalog erforderlich. Darüber hinaus sind Verwaltungsverfahren erforderlich, um die Anzahl der Shards und Mandanten zu verwalten. Beispielsweise müssen Verfahren entworfen werden, um Shards hinzuzufügen und zu entfernen und Mandantendaten zwischen Shards zu verschieben. Eine Möglichkeit zur Skalierung besteht darin, einen neuen Shard hinzuzufügen und ihn mit neuen Mandanten zu befüllen. In anderen Fällen kann ein dicht befüllter Shard in zwei weniger dicht befüllte Shards aufgeteilt werden. Nachdem mehrere Mandanten verschoben oder außer Kraft gesetzt wurden, können Sie wenig befüllte Shards zusammenführen. Die Zusammenführung würde zu einer kosteneffizienteren Ressourcenverwendung führen. Mandanten können auch zwischen den Shards verschoben werden, um für ausgeglichene Workloads zu sorgen.

Die SQL-Datenbank bietet ein Tool zum Aufteilen bzw. Zusammenführen, das in Verbindung mit der Shardingbibliothek und der Katalogdatenbank verwendet werden kann. Die bereitgestellte App kann Shards aufteilen bzw. zusammenführen und Mandantendaten zwischen Shards verschieben. Die App verwaltet während dieser Vorgänge auch den Katalog, wobei die betroffenen Mandanten vor der Verschiebung als offline gekennzeichnet werden. Nach der Verschiebung aktualisiert die App den Katalog wieder mit der neuen Zuordnung und markiert den Mandanten wieder als online.

Einfachere Verwaltung kleinerer Datenbanken

Durch die Verteilung der Mandanten auf mehrere Datenbanken führt der Einsatz der mehrinstanzenfähigen Lösung mit Shards zu kleineren Datenbanken, die sich einfacher verwalten lassen. Wenn Sie beispielsweise einen bestimmten Mandanten zu einem früheren Zeitpunkt wiederherstellen möchten, müssen Sie nun nicht mehr eine größere Datenbank mit allen Mandanten wiederherstellen, sondern nur noch eine einzelne kleinere Datenbank aus einer Sicherung. Die Datenbankgröße und die Anzahl der Mandanten pro Datenbank können so gewählt werden, das ein ausgewogenes Verhältnis zwischen Workload und Verwaltungsaufwand besteht.

Mandanten-ID im Schema

Abhängig von der verwendeten Shardingmethode können in Bezug auf das Datenbankschema zusätzliche Einschränkungen vorgenommen werden. Die SQL-Datenbankanwendung zum Aufteilen bzw. Zusammenführen erfordert, dass das Schema den Shardingschlüssel – üblicherweise die Mandanten-ID – enthält. Die Mandanten-ID ist das führende Element des Primärschlüssels aller Shardingtabellen. Mit der Mandanten-ID kann die Anwendung zum Aufteilen bzw. Zusammenführen, die einem bestimmten Mandanten zugeordneten Daten schnell lokalisieren und verschieben.

Pool für elastische Datenbanken für Shards

Mehrinstanzenfähige Datenbanken mit Shards können in Pools für elastische Datenbanken platziert werden. Die Verwaltung von vielen Einzelinstanzdatenbanken in einem Pool ist in der Regel genauso kosteneffizient wie die Verwaltung vieler Mandanten in mehreren mehrinstanzenfähigen Datenbanken. Mehrinstanzenfähige Datenbanken erweisen sich vor allem dann als nützlich, wenn eine große Anzahl von relativ inaktiven Mandanten vorliegt.

H. Hybrides mehrinstanzenfähiges Datenbankmodell mit Sharding

Im hybriden Modell enthalten alle Datenbanken im Schema die Mandanten-ID. Alle Datenbanken können mehr als einen Mandanten speichern und in Shards aufgeteilt werden. Hinsichtlich des Schemas handelt es sich also bei allen Datenbanken um mehrinstanzenfähige Datenbanken. In der Praxis enthalten einige dieser Datenbanken jedoch nur einen Mandanten. Nichtsdestotrotz hat die Anzahl der in einer Datenbank gespeicherten Mandanten keinen Einfluss auf das Datenbankschema.

Wechseln von Mandanten

Sie können einen bestimmten Mandanten jederzeit in eine eigene mehrinstanzenfähige Datenbank verschieben. Sie können dies jederzeit rückgängig machen und den Mandanten wieder zu einer Datenbank mit mehreren Mandanten wechseln. Sie können einem Mandanten bei der Bereitstellung einer neuen Datenbank auch eine neue Einzelinstanzdatenbank zuordnen.

Das hybride Modell erweist sich vor allem dann als hilfreich, wenn große Unterschiede zwischen den Ressourcenanforderungen der identifizierbarer Mandantengruppen herrschen. Nehmen wir zum Beispiel an, dass Mandanten mit einer kostenlosen Testversion nicht dieselbe hohe Leistungsebene garantiert wird wie Mandanten mit einem Abonnement. Die Richtlinie könnte vorschreiben, dass Mandanten im kostenlosen Testzeitraum in einer mehrinstanzenfähigen Datenbank, die von allen Mandanten mit der kostenlosen Testversion gemeinsam genutzt wird, gespeichert werden sollen. Wenn ein Mandant mit der kostenlosen Testversion ein Abonnement für die Dienstebene „Basic“ erwirbt, kann der Mandant in eine andere mehrinstanzenfähige Datenbank verschoben werden, die möglicherweise weniger Mandanten aufweist. Ein Abonnent, der für die Dienstebene „Premium“ bezahlt, kann in seine eigene neue Datenbank mit nur einem Mandanten verschoben werden.

Pools

In diesem hybriden Modell können Einzelinstanzdatenbanken für Mandanten mit Abonnement in Ressourcenpools platziert werden, um die Datenbankkosten pro Mandant zu senken. Dies wird über das Modell mit einer Datenbank pro Mandant erreicht.

I. Vergleich von Mandantenmodellen

In der folgenden Tabelle werden die Unterschiede zwischen den wichtigsten Mandantenmodellen erläutert:

Nächste Schritte

• Bereitstellen und Untersuchen einer mehrinstanzenfähigen Wingtip-Anwendung mit dem SaaS-Modell mit einer Datenbank pro Mandant – Azure SQL-Datenbank

• Willkommen bei der Beispielmandanten-SaaS-App Wingtip Tickets für Azure SQL-Datenbank