Mehrinstanzenfähigkeit und Azure Cosmos DB

Auf dieser Seite werden einige der Funktionen von Azure Cosmos DB beschrieben, die nützlich sind, wenn Sie mit mehrmandantenfähigen Systemen arbeiten. Darüber hinaus finden Sie Links zu Anleitungen und Beispielen für die Verwendung von Azure Cosmos DB in einer mehrinstanzenfähigen Lösung.

Anforderungen an die Mehrinstanzenfähigkeit

Wenn Sie eine Mehrinstanzenlösung planen, gibt es zwei wichtige Anforderungen, die Sie möglicherweise berücksichtigen müssen:

• Sicherstellen einer starken Isolation zwischen Mandanten und Erfüllen strenger Sicherheitsanforderungen für diejenigen, die sie benötigen.
• Aufrechterhaltung von niedrigen Kosten pro Mandant. Als Anbieter möchten Sie sicherstellen, dass die Kosten für den Betrieb der Anwendung bei einer Skalierung tragbar bleiben.

Diese beiden Bedürfnisse können oft in Konflikt zueinander stehen, sodass Kompromisse eingegangen werden müssen und eines dem anderen vorgezogen werden muss. Es gibt einige Richtlinien, die Sie befolgen können, um die Kompromisse besser zu verstehen, die mit den beiden oben beschriebenen Anforderungen zusammenhängen. Dieses Dokument hilft Ihnen, sich in diesen Überlegungen zurechtzufinden, damit Sie bei der Gestaltung Ihrer mandantenfähigen Lösung fundierte Entscheidungen treffen können.

Isolationsmodelle

Sie müssen die Isolationsebene zwischen Ihren Mandanten festlegen. Azure Cosmos DB unterstützt eine Reihe von Isolationsmodellen, aber für die meisten Lösungen empfehlen wir, eine der folgenden Strategien zu verwenden:

• Partitionsschlüssel pro Mandant, der häufig für vollständig mandantenfähige Lösungen verwendet wird, wie sie in Business-to-Consumer-Software-as-a-Service (B2C SaaS) genutzt werden.
• Datenbankkonto pro Mandant, was häufig in Business-to-Business (B2B) SaaS verwendet wird

Um das am besten geeignete Isolationsmodell auszuwählen, berücksichtigen Sie Ihr Geschäftsmodell und die Anforderungen der Mandanten. Eine starke Leistungsisolation ist beispielsweise für einige B2C-Modelle, bei denen Unternehmen direkt an einen einzelnen Kunden verkaufen, der das Produkt oder die Dienstleistung verwendet, keine Priorität. B2B-Modelle können jedoch eine starke Sicherheits- und Leistungsisolation priorisieren und erfordern möglicherweise, dass Mandanten ein eigenes Datenbankkonto bereitgestellt haben.

Sie können auch mehrere Modelle kombinieren, um den unterschiedlichen Kundenanforderungen gerecht zu werden. Angenommen, Sie erstellen eine B2B SaaS-Lösung, die Sie an Unternehmenskunden verkaufen und als eine kostenlose Testversion für potenzielle Neukunden bereitstellen. Sie können ein separates Datenbankkonto für kostenpflichtige Unternehmensmandanten bereitstellen, die starke Sicherheits- und Isolationsgarantien benötigen, während Sie ein Datenbankkonto freigeben und Partitionsschlüssel zum Isolieren von Testkunden verwenden.

Empfohlene Isolationsmodelle

Partitionsschlüssel pro Mandant

Durch das Isolieren unserer Mandanten nach Partitionsschlüssel wird der Durchsatz über Mandanten hinweg freigegeben und innerhalb desselben Containers gruppiert.

Vorteile:

• Kosteneffizienz: Alle Mandanten werden in einem Container platziert, der von der Mandanten-ID partitioniert wird. Da es nur eine abrechnende Ressource gibt, in der RU/s für mehrere Mandanten bereitgestellt und gemeinsam genutzt werden, ist dieser Ansatz in der Regel kostengünstiger und einfacher zu verwalten als separate Konten pro Mandant.
• Vereinfachte Verwaltung: Es müssen weniger Azure Cosmos DB-Konten verwaltet werden.

Kompromisse:

• Ressourcenkonflikte: Die gemeinsame Nutzung des Durchsatzes (RU/s) durch mehrere Mandanten im selben Container kann bei hoher Auslastung zu Konflikten führen, was wiederum zum Noisy Neighbor-Problem führen kann, wenn Ihre Mandanten über hohe oder überlappende Workloads verfügen. Dieses Isolationsmodell eignet sich für Workloads, die garantierte RU/s auf einem einzelnen Mandanten benötigen und freigeben können.
• Eingeschränkte Isolation: Dieser Ansatz bietet eine logische Isolation, nicht physische Isolation. Er erfüllt möglicherweise keine strengen Isolationsanforderungen, sei es aus Performance- oder Sicherheitsgründen.
• Weniger Flexibilität: Das Anpassen von Features auf Kontoebene wie Georeplikation, Zeitpunktwiederherstellung und kundenseitig verwaltete Schlüssel (CMK) pro Mandant sind nicht verfügbar, wenn sie nach Partitionsschlüssel (oder Datenbank/Container) isolieren.

Relevante Features von Azure Cosmos DB:

• Durchsatzsteuerung: Darüber hinaus gibt es Features, mit denen das Noisy Neighbor-Problem bei der Modellierung von Mandanten über Partitionen gesteuert werden kann, z. B. Durchsatzumverteilung, Burstkapazität und Durchsatzsteuerung im Java SDK.

• Hierarchische Partitionsschlüssel: Mit Azure Cosmos DB kann jede logische Partition auf bis zu 20 GB anwachsen. Wenn Sie über einen einzelnen Mandanten verfügen, der mehr als 20 GB an Daten speichern muss, sollten Sie erwägen, die Daten auf mehrere logische Partitionen zu verteilen. Anstatt beispielsweise über einen einzelnen Partitionsschlüssel von Contoso zu verfügen, können Sie die Partitionsschlüssel durch Erstellen mehrerer Partitionsschlüssel für einen Mandanten wie als Salt verwenden, z. B. Contoso1, Contoso2 usw.

  Wenn Sie die Daten für einen Mandanten abfragen, können Sie die WHERE IN-Klausel verwenden, um alle Partitionsschlüssel abzugleichen. Hierarchische Partitionsschlüssel können ebenfalls verwendet werden, um große Mandanten (vorausgesetzt, Sie haben eine hohe Kardinalität der Mandanten) mit einem Speicher von mehr als 20 GB zu unterstützen, ohne synthetische Partitionsschlüssel oder mehrere Partitionsschlüsselwerte pro Mandant verwenden zu müssen.

  Angenommen, Sie haben eine Workload, die Mandanten nach Partitionsschlüssel isoliert. Ein Mandant, Contoso, ist viel größer und schreibintensiver als andere, und er wächst weiterhin. Um das Risiko zu vermeiden, dass für diesen Mandanten keine weiteren Daten erfasst werden können, können Sie hierarchische Partitionsschlüssel verwenden. Geben Sie TenantID als Schlüssel der ersten Ebene an, und fügen Sie dann eine zweite Ebene wie UserId hinzu. Wenn Sie davon ausgehen, dass die Kombination aus TenantID und UserID logische Partitionen erzeugt, die den Grenzwert von 20 GB überschreiten, können Sie weiter unten auf eine andere Ebene partitionieren, z. B SessionID. Abfragen, die entweder TenantID oder sowohl TenantID als auch UserID angeben, werden effektiv nur an die Teilmenge der physischen Partitionen weitergeleitet, die die relevanten Daten enthalten, wodurch eine vollständige Auffächerungsabfrage vermieden wird. Wenn der Container über 1.000 physische Partitionen hat, ein bestimmter TenantId-Wert jedoch nur auf 5 physischen Partitionen vorhanden ist, wird die Abfrage an die kleinere Anzahl relevanter physischer Partitionen weitergeleitet.

  Wenn Ihre erste Ebene nicht über eine ausreichend hohe Kardinalität verfügt und Sie den Grenzwert von 20 GB für logische Partitionen für Ihren Partitionsschlüssel erreichen, sollten Sie die Verwendung eines synthetischen Partitionsschlüssels anstelle eines hierarchischen Partitionsschlüssels in Betracht ziehen.

Datenbankkonto pro Mandant

Durch das Isolieren unserer Mandanten nach Datenbankkonto verfügt jeder Mandant über einen eigenen Durchsatz auf Datenbankebene oder Containerebene.

Vorteile:

• Hohe Isolation: Mit diesem Ansatz werden Konflikte oder Störungen aufgrund dedizierter Azure Cosmos DB-Konten und -Container mit bereitgestellten RU/s pro eindeutigem Mandanten vermieden.
• Benutzerdefinierte SLAs: Da jeder Mandant über ein eigenes Konto verfügt, können Sie spezifische maßgeschneiderte Ressourcen, kundenorientierte SLAs und Garantien bereitstellen, da das Datenbankkonto jedes Mandanten unabhängig für den Durchsatz optimiert werden kann.
• Verbesserte Sicherheit: Physische Datenisolation gewährleistet eine robuste Sicherheit, da kundenseitig verwaltete Schlüssel auf Kontoebene pro Mandant aktivieren können. Die Daten jedes Mandanten sind durch ein Konto isoliert, anstatt sich im selben Container zu befinden.
• Weniger Flexibilität: Mandanten können Features auf Kontoebene wie Georeplikation, Point-in-Time Restore (PITR) und kundenseitig verwaltete Schlüssel (CMK) je nach Bedarf aktivieren.

Kompromisse:

• Erhöhte Verwaltung: Dieser Ansatz ist komplexer, da Sie mehrere Azure Cosmos DB-Konten verwalten.
• Höhere Kosten: Mehr Konten bedeuten die Bereitstellung eines Bereitstellungsdurchsatzes (RU/s) für jede Ressource (Datenbanken und/oder Container) innerhalb des Kontos für jeden Mandanten. Jedes Mal, wenn eine Ressource RU/s bereit stellt, erhöhen sich die Kosten für Azure Cosmos DB.
• Abfragebeschränkungen: Da sich alle Mandanten in verschiedenen Konten befinden, werden beim Abfragen mehrerer Mandanten mehrere Aufrufe innerhalb der Logik der Anwendung für jeden Mandanten benötigt.

Relevante Features von Azure Cosmos DB:

• Sicherheitsfeatures: Dieses Modell bietet erhöhte Datenzugriffssicherheits-Isolation mithilfe von Azure RBAC. Darüber hinaus ermöglicht dieses Modell eine Isolation der Datenbankverschlüsselung auf Mandantenebene über kundenseitig verwaltete Schlüssel.
• Benutzerdefinierte Konfiguration: Sie können die Position des Datenbankkontos den Anforderungen des Mandanten entsprechend konfigurieren. Sie können auch die Konfiguration von Azure Cosmos DB-Features wie Georeplikation und kundenseitig verwaltete Verschlüsselungsschlüssel an die Anforderungen des jeweiligen Mandanten anpassen.

Wenn Sie ein dediziertes Azure Cosmos DB-Konto pro Mandant verwenden, berücksichtigen Sie die Höchstanzahl von Azure Cosmos DB-Konten pro Azure-Abonnement.

Vollständige Liste der Isolationsmodelle

Container pro Mandant

Sie können für jeden Mandanten dedizierte Container bereitstellen. Dedizierte Container funktionieren gut, wenn die Daten, die Sie für Ihren Mandanten speichern, in einem einzelnen Container zusammengefasst werden können. Dieses Modell ermöglicht eine höhere Leistungsisolation als das oben genannte Modell mit mandantenspezifischen Partitionsschlüsseln und bietet auch eine erhöhte Isolation der Datenzugriffssicherheit über Azure RBAC.

Wenn Sie einen Container für jeden Mandanten verwenden, können Sie erwägen, den Durchsatz mit anderen Mandanten zu teilen, indem Sie Durchsatz auf Datenbankebene bereitstellen. Berücksichtigen Sie die Einschränkungen und Grenzwerte für die Mindestanzahl von Anforderungseinheiten für Ihre Datenbank und die Höchstanzahl von Containern in der Datenbank. Überlegen Sie außerdem, ob Ihre Mandanten ein garantiertes Leistungsniveau benötigen und ob sie für das Noisy Neighbor-Problem anfällig sind. Bei einer gemeinsamen Nutzung des Durchsatzes auf Datenbankebene sollte Workload oder Speicherung für alle Container relativ einheitlich sein. Andernfalls kann es zu einem Noisy Neighbor-Problem kommen, wenn es einen oder mehrere große Mandanten gibt. Erwägen Sie ggf. eine Gruppierung dieser Mandanten in verschiedenen Datenbanken, die auf Workloadmustern basieren.

Alternativ können Sie dedizierten Durchsatz für jeden Container bereitstellen. Dieser Ansatz funktioniert gut für größere Mandanten und für Mandanten, für die das Risiko des Noisy Neighbor-Problems besteht. Der Baselinedurchsatz für jeden Mandanten ist jedoch höher. Berücksichtigen Sie daher die Mindestanforderungen und Kostenauswirkungen dieses Modells.

Wenn für Ihr Mandantendatenmodell mehrere Entitäten erforderlich sind, können sich die Entitäten gemeinsam im selben Container befinden, solange alle Entitäten denselben Partitionsschlüssel gemeinsam nutzen können. Wenn das Mandantendatenmodell jedoch komplexer ist und Entitäten erforderlich sind, die nicht denselben Partitionsschlüssel gemeinsam nutzen können, sollten Sie die unten erwähnten Modelle mit mandantenspezifischen Datenbanken oder Datenbankkonten in Betracht ziehen. Weitere Informationen finden Sie in unserem Artikel zum Modellieren und Partitionieren von Daten in Azure Cosmos DB anhand eines realen Beispiels.

Die Lebenszyklusverwaltung ist im Allgemeinen einfacher, wenn Container Mandanten dediziert zugeordnet werden. Sie können Mandanten problemlos zwischen Modellen mit gemeinsam genutztem und dediziertem Durchsatz verschieben, und wenn Sie die Bereitstellung eines Mandanten aufheben, können Sie den Container schnell löschen.

Datenbank pro Mandant

Sie können Datenbanken für jeden Mandanten im selben Datenbankkonto bereitstellen. Wie das obige Modell mit mandantenspezifischen Containern ermöglicht dieses Modell eine höhere Leistungsisolation als das Modell mit mandantenspezifischen Partitionsschlüsseln und bietet auch eine erhöhte Isolation der Datenzugriffssicherheit über Azure RBAC.

Wie das folgende Modell mit mandantenspezifischen Konten ermöglicht dieser Ansatz die höchste Leistungsisolation, aber die niedrigste Mandantendichte. Diese Option ist jedoch am besten geeignet, wenn jeder Mandant ein komplexeres Datenmodell benötigt, als im Modell mit mandatenspezifischen Containern machbar ist. Sie sollten diesen Ansatz auch befolgen, wenn neue Mandanten schnell und/oder ohne Mehraufwand für die Erstellung von Mandantenkonten im Voraus erstellt werden müssen. Es kann auch der Fall sein, dass abhängig vom jeweils verwendeten Softwareentwicklungsframework mandantenspezifische Datenbanken die einzige Möglichkeit zur Leistungsisolation sind, die im Framework verfügbar ist. Die Isolation auf Entitätsebene (Containerebene) und die Kollokation von Entitäten werden in solchen Frameworks in der Regel nicht nativ unterstützt.

Features von Azure Cosmos DB, die Mehrinstanzenfähigkeit unterstützen

Partitionierung

Wenn Sie Partitionen mit Ihren Azure Cosmos DB-Containern verwenden, können Sie Container erstellen, die von mehreren Mandanten gemeinsam genutzt werden. In der Regel verwenden Sie den Mandantenbezeichner als Partitionsschlüssel, aber Sie können auch mehrere Partitionsschlüssel für einen einzelnen Mandanten verwenden. Eine gut geplante Partitionierungsstrategie implementiert das Shardingmuster auf effektive Weise. Bei großen Containern verteilt Azure Cosmos DB Ihre Mandanten auf mehrere physische Knoten, um ein hohes Maß an Skalierung zu erreichen.

Sie sollten die Verwendung hierarchischer Partitionsschlüssel überprüfen, um die Leistung Ihrer mehrmandantenfähigen Lösung zu verbessern. Mit hierarchischen Partitionsschlüsseln können Sie einen Partitionsschlüssel erstellen, der mehrere Werte enthält. Sie können z. B. einen hierarchischen Partitionsschlüssel verwenden, der den Mandantenbezeichner enthält, z. B. eine GUID mit hoher Kardinalität, um nahezu ungebundene Skalierung zu ermöglichen. Sie können auch einen hierarchischen Partitionsschlüssel angeben, der eine Eigenschaft enthält, die häufig in Abfragen verwendet wird. Dieser Ansatz hilft Ihnen, partitionsübergreifende Abfragen zu vermeiden. Durch die Verwendung hierarchischer Partitionierungsschlüssel können Sie über die logische Partitionsgrenze von 20 GB pro Partitionierungsschlüsselwert hinaus skalieren und teure Auffächerungsabfragen begrenzen.

Weitere Informationen:

• Partitionierung und horizontale Skalierung in Azure Cosmos DB
• Hierarchische Partitionsschlüssel

Verwalten von Anforderungseinheiten

Das Preismodell von Azure Cosmos DB basiert auf der Anzahl der Anforderungseinheiten (Request Unit, RU) pro Sekunde, die Sie bereitstellen oder nutzen. Eine Anforderungseinheit ist eine logische Abstraktion der Kosten für einen Datenbankvorgang oder eine Abfrage. In der Regel stellen Sie eine definierte Anzahl von Anforderungseinheiten pro Sekunde für Ihre Workload zur Verfügung, die als Durchsatz bezeichnet wird. Azure Cosmos DB bietet mehrere Optionen für die Art der Bereitstellung des Durchsatzes. In einer mehrinstanzenfähigen Umgebung wirkt sich die von Ihnen getroffene Auswahl auf die Leistung und den Preis Ihrer Azure Cosmos DB-Ressourcen aus.

Für Mandanten, die eine garantierte Leistung und Sicherheitsisolation erfordern, empfehlen wir, Mandanten nach Datenbankkonto zu isolieren und Anforderungseinheiten an den Mandanten zu zuordnen. Für Mandanten mit weniger strengen Anforderungen empfehlen wir, Mandanten nach Partitionsschlüssel zu isolieren, was die Freigabeanforderungseinheiten zwischen Ihren Mandanten ermöglicht und Sie bei der Optimierung für eine niedrige Kosten pro Mandant unterstützt.

Ein alternatives Mandantenmodell für Azure Cosmos DB umfasst die Bereitstellung separater Container für jeden Mandanten innerhalb einer freigegebenen Datenbank. Mit Azure Cosmos DB können Sie Anforderungseinheiten für eine Datenbank bereitstellen, und alle Container verwenden die Anforderungseinheiten gemeinsam. Wenn sich Ihre Mandantenworkloads in der Regel nicht überschneiden, kann dies ein nützlicher Ansatz zur Verringerung Ihrer Betriebskosten sein. Dieser Ansatz ist jedoch anfällig für das Noisy Neighbor-Problem, weil der Container eines einzelnen Mandanten möglicherweise eine unverhältnismäßig große Menge der gemeinsam genutzten, bereitgestellten Anforderungseinheiten verbraucht. Um dieses Problem zu beheben, müssen Sie zuerst die störenden Mandanten identifizieren. Anschließend können Sie ggf. den bereitgestellten Durchsatz für einen bestimmten Container festlegen. Die anderen Container in der Datenbank teilen weiterhin ihren Durchsatz, aber der störende Mandant verbraucht seinen eigenen dedizierten Durchsatz.

Azure Cosmos DB bietet außerdem eine serverlose Ebene, die für Workloads mit zeitweiligem oder unvorhersehbarem Datenverkehr geeignet ist. Alternativ können Sie mit der automatischen Skalierung Richtlinien konfigurieren, um die Skalierung des bereitgestellten Durchsatzes anzugeben. Darüber hinaus können Sie die Vorteile der Azure Cosmos DB Burst-Kapazität nutzen und so die Auslastung Ihrer bereitgestellten Durchsatzkapazität maximieren, die ansonsten auf einen Grenzwert begrenzt gewesen wäre. In einer mehrinstanzenfähigen Lösung können Sie alle diese Ansätze kombinieren, um verschiedene Mandantentypen zu unterstützen.

Um die Kosten zu überwachen und zu verwalten, die den einzelnen Mandanten zugeordnet sind, umfasst jeder Vorgang, der die Azure Cosmos DB-API verwendet, die verbrauchten Anforderungseinheiten. Sie können diese Informationen verwenden, um die tatsächlich von den einzelnen Mandanten verbrauchten Anforderungseinheiten zu aggregieren und zu vergleichen. Anschließend können Sie Mandanten mit unterschiedlichen Leistungsmerkmalen identifizieren.

Weitere Informationen:

• Bereitgestellter Durchsatz
• Automatische Skalierung
• Serverlos
• Messen der RU-Gebühr für eine Anforderung
• Kontingente im Azure Cosmos DB-Dienst
• Burstkapazität

Vom Kunden verwaltete Schlüssel

Einige Mandanten erfordern möglicherweise die Verwendung ihrer eigenen Verschlüsselungsschlüssel. Azure Cosmos DB bietet ein Feature für kundenseitig verwaltete Schlüssel. Dieses Feature wird auf der Ebene eines Azure Cosmos DB-Kontos angewendet, sodass Mandanten, die ihre eigenen Verschlüsselungsschlüssel benötigen, mithilfe dedizierter Azure Cosmos DB-Konten bereitgestellt werden müssen.

Weitere Informationen:

• Konfigurieren von kundenseitig verwalteten Schlüsseln für Ihr Azure Cosmos DB-Konto mit Azure Key Vault

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Tara Bhatia | Program Manager, Azure Cosmos DB
• Paul Burpo | Principal Customer Engineer, FastTrack for Azure
• John Downs | Principal Software Engineer

Andere Mitwirkende:

• Mark Brown | Principal PM Manager, Azure Cosmos DB
• Deborah Chen | Principal Program Manager
• Theo van Kraay | Senior Program Manager, Azure Cosmos DB
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
• Thomas Weiss | Principal Program Manager
• Vic Perdana | Cloud Solution Architect, Azure ISV

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Überprüfen Sie dieSpeicher- und Datenansätze für Mehrinstanzenfähigkeit.

Weitere Informationen zu Mehrinstanzenfähigkeit und Azure Cosmos DB:

• Entwerfen und Erstellen von mehrinstanzenbasierten SaaS-Apps im Maßstab mit Azure Cosmos DB: Eine Sitzung auf Build 2024, die Sie durch das Entwerfen von Mehrinstanzenfähigkeiten in Azure Cosmos DB führt und bewährte Methoden aus einem echten ISV lernt.
• Azure Cosmos DB und mehrinstanzenfähige Systeme: In diesem Blogbeitrag wird die Erstellung eines mehrinstanzenfähigen Systems mit Azure Cosmos DB erläutert.
• Mehrinstanzenfähige Anwendungen mit Azure Cosmos DB (Video)
• Video: Building a multitenant SaaS with Azure Cosmos DB and Azure (Erstellen einer mehrinstanzenfähigen SaaS-Lösung mit Azure Cosmos DB und Azure): Eine Fallstudie aus der Praxis, die zeigt, wie Whally, ein Startup für mehrinstanzenfähiges SaaS, eine moderne Plattform von Grund auf in Azure Cosmos DB und Azure erstellt hat. Whally erläutert die Entwurfs- und Implementierungsentscheidungen, die in Bezug auf Partitionierung, Datenmodellierung, sichere Mehrinstanzenfähigkeit, Leistung, Echtzeitstreaming aus dem Änderungsfeed zu SignalR und mehr getroffen wurden. Alle diese Lösungen verwenden ASP.NET Core für Azure App Services.

Zugehörige Ressourcen

Weitere Informationen finden Sie in unseren anderen Cosmos DB-Architekturszenarien:

• Serverlose Apps mit Azure Cosmos DB
• Transaktionsausgangsmuster mit Azure Cosmos DB
• Visuelle Suche im Einzelhandel mit Azure Cosmos DB
• Gaming mit Azure Cosmos DB