Freigeben über

Architekturansätze für die Berechnung in Multitenant-Lösungen

Die meisten cloudbasierten Lösungen bestehen aus Computeressourcen. Diese Ressourcen können Web- und Anwendungsebenen, Batchprozessoren, geplante Aufträge oder spezialisierte Ressourcen wie GPUs und Hochleistungsberechnung umfassen. Multitenant-Lösungen profitieren häufig von gemeinsam genutzten Computeressourcen, da eine höhere Mandantendichte für jede Infrastruktur die Betriebskosten senkt und die Verwaltung vereinfacht. Sie sollten die Isolationsanforderungen und die Auswirkungen der gemeinsamen Infrastruktur berücksichtigen.

Dieser Artikel enthält Anleitungen zu wichtigen Überlegungen und Anforderungen für Lösungsarchitekten, die sie berücksichtigen sollten, wenn sie eine mehrinstanzenfähige Computeebene planen. Dieser Leitfaden enthält allgemeine Muster für das Anwenden von Mehrinstanzenfähigkeit auf Computedienste und Antipattern, um zu vermeiden.

Wichtige Überlegungen und Anforderungen

Sowohl Multitenancy als auch das ausgewählte Isolationsmodell wirken sich auf die Skalierung, Leistung, Zustandsverwaltung und Sicherheit Ihrer Rechenressourcen aus. In den folgenden Abschnitten werden wichtige Entscheidungen überprüft, die Sie treffen müssen, wenn Sie eine Multitenant-Computelösung planen.

Skalieren

Systeme müssen bei einer Änderung der Nachfrage angemessen funktionieren. Da sich die Anzahl der Mandanten und der Datenverkehr erhöhen, müssen Sie möglicherweise die Ressourcen skalieren, um dem wachsenden Bedarf gerecht zu werden und eine akzeptable Leistung zu erzielen. Entsprechend sollten Sie, wenn die Anzahl der aktiven Benutzer oder die Anzahl des Datenverkehrs verringert wird, die Rechenkapazität automatisch reduzieren, um die Kosten zu senken. Sie sollten jedoch alle Unterbrechungen für Benutzer minimieren, wenn Sie die Kapazität anpassen.

Wenn Sie dedizierte Ressourcen für jeden Mandanten bereitstellen, haben Sie die Flexibilität, die Ressourcen jedes Mandanten unabhängig voneinander zu skalieren. In einer Lösung, in der Computeressourcen von mehreren Mandanten gemeinsam genutzt werden, ermöglicht die Skalierung dieser Ressourcen allen Mandanten, von der erhöhten Kapazität zu profitieren. Grundsätzlich leiden aber alle Mandanten, wenn die Skalierung nicht ausreicht, deren Gesamtlast zu bewältigen. Weitere Informationen finden Sie unter Noisy Neighbor Antipattern.

Wenn Sie Cloudlösungen erstellen, können Sie auswählen, ob horizontal oder vertikal skaliert werden soll. Bei einer Multi-Tenant-Lösung mit einer wachsenden Anzahl von Mandanten bietet die horizontale Skalierung häufig mehr Flexibilität und eine höhere maximale Skalierung.

Leistungsprobleme bleiben häufig unerkannt, bis eine Anwendung geladen ist. Sie können einen vollständig verwalteten Dienst wie Azure Load Testing verwenden, um zu erfahren, wie Ihre Anwendung unter Stress funktioniert.

Skalierungstrigger

Unabhängig von dem Ansatz, den Sie zum Skalieren verwenden, müssen Sie in der Regel die Trigger planen, die dazu führen, dass Ihre Komponenten skaliert werden. Berücksichtigen Sie bei gemeinsam genutzten Komponenten die Workloadmuster jedes Mandanten, um sicherzustellen, dass Ihre bereitgestellte Kapazität den gesamt erforderlichen Bedarf erfüllt. Dieser Ansatz trägt dazu bei, Ressourcenkonflikten zu verhindern und die Wahrscheinlichkeit zu verringern, dass Mandanten das laute Nachbarproblem haben. Möglicherweise können Sie ihre Skalierungskapazität auch planen, indem Sie die Anzahl der Mandanten berücksichtigen. Wenn Sie beispielsweise die Ressourcen messen, die Sie für den Dienst von 100 Mandanten verwenden, können Sie beim Onboarding weiterer Mandanten eine Skalierung planen, sodass Ihre Ressourcen für alle zusätzlichen 100 Mandanten verdoppelt werden.

Staat

Computeressourcen können zustandslos sein oder zustandsbehaftet sein. Zustandslose Komponenten verwalten keine Daten zwischen Anforderungen. Aus Skalierbarkeitsperspektive sind zustandslose Komponenten häufig einfach zu skalieren, da Sie schnell neue Mitarbeiter, Instanzen oder Knoten hinzufügen können. Zustandslose Komponenten können auch sofort mit der Verarbeitung von Anforderungen beginnen. Wenn Ihre Architektur die Umwidmung von Instanzen unterstützt, können Sie Instanzen auch von einem Mandanten an einen anderen neu zuweisen.

Zustandsbehaftete Ressourcen können basierend auf dem Zustand, den sie beibehalten, weiter unterteilt werden. Der permanente Zustand ist Daten, die dauerhaft gespeichert werden müssen. Vermeiden Sie in Cloudlösungen das Speichern eines beständigen Zustands in Ihrer Computeebene. Verwenden Sie stattdessen Speicherdienste wie Datenbanken oder Speicherkonten. Ein vorübergehender Zustand beschreibt Daten, die temporär gespeichert werden. Sie enthält schreibgeschützte In-Memory-Caches und den Speicher temporärer Dateien auf lokalen Datenträgern.

Der vorübergehende Zustand ist häufig hilfreich, um die Leistung Ihrer Anwendungsebene zu verbessern, indem die Anzahl der Anforderungen an Back-End-Speicherdienste reduziert wird. Wenn Sie z. B. einen In-Memory-Cache verwenden, können Sie möglicherweise Leseanforderungen bereitstellen, ohne eine Verbindung mit einer Datenbank herzustellen und ohne eine intensive Abfrage auszuführen, die Sie kürzlich ausgeführt haben, wenn Sie eine andere Anforderung bereitgestellt haben.

Bei Anwendungen mit Latenzempfindlichkeit können die Kosten für die Cachehydration signifikant werden. Eine Lösung mit mehreren Mandanten kann dieses Problem verschlechtern, wenn für jeden Mandanten unterschiedliche Daten zwischengespeichert werden müssen. Um dieses Problem zu beheben, wenden einige Lösungen die Sitzungsaffinität an. Dieser Ansatz stellt sicher, dass derselbe Compute Workerknoten alle Anforderungen für einen bestimmten Benutzer oder Mandanten verarbeitet. Die Sitzungsaffinität kann die Fähigkeit der Anwendungsebene verbessern, den Cache effektiv zu verwenden. Die Sitzungsaffinität kompliziert jedoch auch die Skalierung und den Lastenausgleich des Datenverkehrs über Worker hinweg. Berücksichtigen Sie diesen Kompromiss sorgfältig. Für viele Anwendungen ist keine Sitzungsaffinität erforderlich.

Es ist auch möglich, Daten in externen Caches zu speichern, z. B. azure Managed Redis. Externe Caches sind für den Abruf von Daten mit geringer Latenz optimiert und isolieren den Zustand aus den Computeressourcen, sodass sie separat skaliert und verwaltet werden können. In vielen Lösungen können Sie mit externen Caches die Anwendungsleistung verbessern, während Sie die Computeebene zustandslos halten.

Wichtig

Vermeiden Sie Datenlecks zwischen Mandanten, wenn Sie speicherinterne Caches oder andere Komponenten verwenden, die den Zustand beibehalten. Ziehen Sie beispielsweise in Betracht, allen Cacheschlüsseln einen Mandantenbezeichner voranzustellen, um sicherzustellen, dass die Daten für jeden Mandanten getrennt sind.

Isolierung

Wenn Sie eine mehrinstanzenfähige Computeebene entwickeln, gibt es mehrere Optionen für die Mandantenisolation. Sie können gemeinsam genutzte Computeressourcen für alle Mandanten, dedizierte Computeressourcen für einzelne Mandanten oder einen halbisolierten Ansatz bereitstellen, der zwischen diesen Extremen liegt. Jede Option hat Vor- und Nachteile. Um zu entscheiden, welche Option am besten zu Ihrer Lösung passt, sollten Sie ihre Anforderungen an die Isolierung berücksichtigen.

Möglicherweise beschäftigen Sie sich mit der logischen Isolierung von Mandanten und wie Sie die Verwaltungsaufgaben oder Richtlinien trennen, die auf jeden Mandanten angewendet werden. Alternativ müssen Sie möglicherweise unterschiedliche Ressourcenkonfigurationen für bestimmte Mandanten bereitstellen, z. B. das Bereitstellen einer bestimmten VM-SKU für die Arbeitsauslastung eines Mandanten.

Stellen Sie je nach ausgewähltem Isolationsmodell sicher, dass Mandantendaten ordnungsgemäß isoliert bleiben, auch wenn Komponentenfehler oder Ausfalle auftreten. Erwägen Sie die Verwendung von Azure Chaos Studio in Ihrem regulären automatisierten Testprozess, um Fehler einzuführen, die reale Ausfälle simulieren. Mit diesem Test wird sichergestellt, dass Ihre Lösung eine ordnungsgemäße Mandantenisolation aufrecht erhält und weiterhin unter Druck funktioniert.

Zu berücksichtigende Ansätze und Muster

Automatische Skalierung

Azure Compute Services bieten verschiedene Funktionen, die Workloads skalieren. Viele Computedienste unterstützen das automatische Skalieren, wobei Sie bestimmen müssen, wann skaliert werden soll, und die Mindest- und Höchstgrenzen für die Skalierung festlegen müssen. Die spezifischen Skalierungsoptionen hängen von den von Ihnen verwendeten Computediensten ab. Sehen Sie sich die folgenden Beispieldienste oder -komponenten an:

Muster mit Bereitstellungsstempeln

Weitere Informationen dazu, wie Sie das Bereitstellungsstempelmuster verwenden können, um eine Mehrinstanzenlösung zu unterstützen, finden Sie unter Architekturansätze für eine Mehrinstanzenlösung.

Muster „Computeressourcenkonsolidierung“

Das Konzept der Konsolidierung von Rechenressourcen hilft Ihnen, eine höhere Dichte von Mandanten auf der Recheninfrastruktur zu erreichen, indem Sie die zugrunde liegenden Computerressourcen teilen. Durch die Freigabe von Computeressourcen können Sie die direkten Kosten dieser Ressourcen reduzieren. Außerdem sind Ihre Verwaltungskosten häufig niedriger, da weniger Komponenten zur Verwaltung vorhanden sind.

Die Berechnungsressourcenkonsolidierung erhöht jedoch die Wahrscheinlichkeit des lauten Nachbarproblems. Die Arbeitsauslastung eines Mieters kann eine unverhältnismäßige Menge der verfügbaren Rechenkapazität beanspruchen. Sie können dieses Risiko häufig mindern, indem Sie sicherstellen, dass Sie Ihre Lösung entsprechend skalieren und Steuerelemente wie Kontingente und API-Grenzwerte anwenden, um Mandanten zu vermeiden, die mehr als ihren fairen Anteil an der Kapazität verbrauchen.

Dieses Muster wird je nach dem von Ihnen verwendeten Computedienst auf unterschiedliche Weise erreicht. Sehen Sie sich die folgenden Beispieldienste oder -komponenten an:

  • App-Dienst und Azure-Funktionen: Stellen Sie freigegebene App Service-Pläne bereit, die die Hostingserverinfrastruktur darstellen.

  • Container-Apps: Stellen Sie freigegebene Umgebungen bereit.

  • AKS: Stellen Sie freigegebene Pods mit einer mehrinstanzenfähigen Anwendung bereit.

  • VMs: Stellen Sie einen einzelnen Satz von VMs bereit, den alle Mandanten verwenden können.

Dedizierte Computeressourcen für jeden Mandanten

Sie können auch dedizierte Computeressourcen für jeden Mandanten bereitstellen. Dedizierte Ressourcen mindern das Risiko des lauten Nachbarproblems , indem sichergestellt wird, dass die Computeressourcen für jeden Mandanten von den anderen isoliert sind. Außerdem können Sie eine unterschiedliche Konfiguration für die Ressourcen der einzelnen Mandanten basierend auf ihren Anforderungen bereitstellen. Dedizierte Ressourcen verursachen jedoch in der Regel höhere Kosten, da Sie über eine geringere Mandantendichte pro Ressource verfügen.

Je nach den von Ihnen verwendeten Azure-Computediensten müssen Sie möglicherweise verschiedene dedizierte Ressourcen bereitstellen:

  • App-Dienst und Azure-Funktionen: Stellen Sie separate App Service-Pläne für jeden Mandanten bereit.

  • Container-Apps: Stellen Sie separate Umgebungen für jeden Mandanten bereit.

  • AKS: Stellen Sie dedizierte Cluster für jeden Mandanten bereit.

  • Vms: Stellen Sie dedizierte VMs für jeden Mandanten bereit.

Die Isolation auf physischer Hostebene kann auch durch ausführen von Mandanten-VMs auf dedizierten Azure-Hosts bereitgestellt werden, die einen gesamten physischen Server für einen einzelnen Kunden reservieren. Dieser Ansatz ist jedoch in der Regel teurer als die Verwendung gemeinsam genutzter Hosts.

Semi-isolierte Computeressourcen

Semiisolationsmethoden erfordern, dass Sie Aspekte der Lösung in einer isolierten Konfiguration bereitstellen, während Sie die anderen Komponenten freigeben.

Wenn Sie App Service und Azure Functions verwenden, können Sie unterschiedliche Anwendungen für jeden Mandanten bereitstellen und die Anwendungen auf freigegebenen App Service-Plänen hosten. Dieser Ansatz reduziert die Kosten Ihrer Computeebene, da App Service-Pläne die Abrechnungseinheit darstellen. Außerdem können Sie für jede Anwendung unterschiedliche Konfigurationen und Richtlinien anwenden. Dieser Ansatz führt jedoch zu dem Risiko des lauten Nachbarproblems.

Sie können Container-Apps verwenden, um mehrere Anwendungen in einer freigegebenen Umgebung bereitzustellen, und dann Dapr und andere Tools verwenden, um jede Anwendung separat zu konfigurieren.

AKS und Kubernetes bieten breitere Möglichkeiten für mehrinstanzenfähige Mandanten:

  • Mandantenspezifische Namespaces, die eine logische Isolierung mandantenspezifischer Ressourcen bereitstellen können, die in geteilten Clustern und Knotenpools bereitgestellt werden.

  • Mandantenspezifische Knoten oder Knotenpools auf einem gemeinsamen Cluster

  • Mandantenspezifische Pods, die unter Umständen denselben Knotenpool nutzen

Mit AKS können Sie zudem Governance auf Podebene anwenden, um das Noisy Neighbor-Problem zu entschärfen. Weitere Informationen finden Sie unter Bewährte Methoden für Anwendungsentwickler zum Verwalten von Ressourcen in AKS.

Außerdem ist es wichtig, dass sie gemeinsam genutzte Komponenten in einem Kubernetes-Cluster kennen und wie sich die Mehrinstanzenfähigkeit auf diese Komponenten auswirken kann. Beispielsweise ist der Kubernetes-API-Server ein gemeinsam genutzter Dienst, der im gesamten Cluster verwendet wird. Auch wenn Sie mandantenspezifische Knotenpools bereitstellen, um die Anwendungsarbeitslasten der Mandanten zu isolieren, könnte der API-Server von einer großen Anzahl von Anforderungen über die Mandanten hinweg beeinträchtigt werden.

Zu vermeidende Antimuster

Vermeiden Sie die folgenden Antipattern.

Noisy Neighbor-Antimuster

Wenn Sie Komponenten bereitstellen, die von Mandanten gemeinsam genutzt werden, ist das Problem der störenden Nachbarn ein potenzielles Risiko. Stellen Sie sicher, dass Sie Ressourcengovernance und -überwachung einschließen, um das Risiko zu verringern, dass die Computeworkload eines Mandanten durch Aktivitäten anderer Mandanten beeinträchtigt wird.

Mandantenübergreifende Datenlecks

Computeebenen können mandantenübergreifenden Datenlecks ausgesetzt sein, wenn sie nicht ordnungsgemäß behandelt werden. Dieses Risiko ist in der Regel nicht erforderlich, wenn Sie einen Mehrinstanzendienst in Azure verwenden, da Microsoft Schutz auf Plattformebene bereitstellt. Wenn Sie jedoch eine eigene mehrinstanzenfähige Anwendung entwickeln, überlegen Sie, ob freigegebene Ressourcen wie lokale Datenträgercaches, RAM und externe Caches Daten enthalten, die ein anderer Mandant versehentlich anzeigen oder ändern kann.

Antimuster für ausgelastete Front-Ends

Um das Busy-Front-End-Antipattern zu vermeiden, stellen Sie sicher, dass Ihre Front-End-Ebene nicht die meiste Arbeit erledigt, die andere Komponenten oder Ebenen Ihrer Architektur bewältigen können. Dieses Antimuster ist besonders wichtig, wenn Sie freigegebene Front-Ends für eine mehrinstanzenfähige Lösung erstellen, da ein ausgelastetes Front-End die Erfahrung für alle Mandanten beeinträchtigt.

Verwenden Sie stattdessen die asynchrone Verarbeitung mithilfe von Warteschlangen oder anderen Messagingdiensten. Mit diesem Ansatz können Sie auch QOS-Steuerelemente (Quality of Service) für verschiedene Mandanten basierend auf ihren Anforderungen anwenden. Beispielsweise können alle Mandanten eine gemeinsame Front-End-Ebene teilen, aber Mandanten, die für eine höhere Dienstebene bezahlen , verfügen möglicherweise über einen höheren Satz dedizierter Ressourcen, um die Arbeit aus ihren Warteschlangennachrichten zu verarbeiten.

Inelastische oder unzureichende Skalierung

Mehrinstanzenfähige Lösungen unterliegen häufig Skalierungsmustern mit Spitzen. Freigegebene Komponenten sind besonders anfällig für dieses Problem, da der Umfang für "Burst" höher ist und der Effekt größer ist, wenn Sie mehr Mandanten haben, die unterschiedliche Verwendungsmuster aufweisen.

Stellen Sie sicher, dass Sie die Flexibilität und skalierung der Cloud nutzen. Überlegen Sie, ob Sie horizontale oder vertikale Skalierung verwenden sollten, und verwenden Sie die automatische Skalierung, um Spitzen beim Laden automatisch zu behandeln. Testen Sie Ihre Lösung, um zu verstehen, wie sie unter verschiedenen Ladeebenen funktioniert. Stellen Sie sicher, dass Sie die in der Produktion erwarteten Lastvolumen und ihr erwartetes Wachstum einschließen. Sie können einen vollständig verwalteten Dienst wie Load Testing verwenden, um zu erfahren, wie Ihre Anwendung unter Stress funktioniert.

Antimuster „Kein Caching“

Die "Keine Zwischenspeicherung"-Antipattern tritt auf, wenn die Leistung Ihrer Lösung darunter leidet, dass die Anwendungsschicht wiederholt Informationen anfordert oder neu berechnet, die über Anforderungen hinweg wiederverwendet werden können. Wenn Sie Daten haben, die entweder zwischen Mandanten oder zwischen Benutzern innerhalb eines einzelnen Mandanten freigegeben werden können, lohnt es sich wahrscheinlich, sie zwischenzuspeichern, um die Last auf Ihrer Backend- oder Datenbankebene zu reduzieren.

Unnötige Zustandsbehaftung

Das Antimuster „Kein Caching“ impliziert, dass Sie auch vermeiden sollten, unnötige Zustände auf Ihrer Computeebene zu speichern. Geben Sie explizit an, wo Sie den Zustand beibehalten und warum. Zustandsbehaftete Front-End- oder Anwendungsebenen können Ihre Skalierungsmöglichkeiten verringern. Zustandsbehaftete Computeebenen erfordern in der Regel auch Sitzungsaffinität, was Ihre Möglichkeiten zum effektiven Lastenausgleich des Datenverkehrs zwischen Workern oder Knoten verringern kann.

Berücksichtigen Sie die Kompromisse für jeden Zustand, den Sie auf Ihrer Computeebene beibehalten, und beachten Sie, ob sich dies auf Ihre Skalierungs- oder Erweiterungsmöglichkeiten auswirkt, wenn sich die Workloadmuster Ihrer Mandanten ändern. Sie können den Zustand auch in einem externen Cache speichern, z. B. azure Managed Redis.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

  • Dixit Arora | Senior Customer Engineer, FastTrack für Azure
  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Mitwirkende:

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Lesen Sie die dienstspezifische Anleitung für Ihre Computedienste:

  • Last updated on