Freigeben über

Architekturansätze für Compute in mehrinstanzenfähigen Lösungen

  • Artikel

Die meisten cloudbasierten Lösungen bestehen aus Computeressourcen irgendeiner Art, z. B. Web- und Anwendungsebenen, Batchprozessoren, geplante Aufträge und sogar spezialisierte Ressourcen wie GPUs und High Performance Compute (HPC). Mehrinstanzenfähige Lösungen profitieren häufig von gemeinsam genutzten Computeressourcen, da eine höhere Dichte von Mandanten für die Infrastruktur die Betriebskosten und die Verwaltung reduziert. Berücksichtigen Sie die Anforderungen an die Isolation und die Auswirkungen der freigegebenen Infrastruktur.

Dieser Artikel enthält Anleitungen zu den Überlegungen und Anforderungen, die Lösungsarchitekten bei der Planung einer mehrmandantenfähigen Computeebene unbedingt berücksichtigen müssen. Dies umfasst einige gängige Muster für die Anwendung von Mehrinstanzenfähigkeit auf Computedienste sowie einige Antimuster, die vermieden werden sollten.

Wesentliche Aspekte und Anforderungen

Mehrinstanzenfähigkeit und das ausgewählte Isolationsmodell wirken sich auf die Skalierung, Leistung, Zustandsverwaltung und Sicherheit Ihrer Computeressourcen aus. In diesem Abschnitt werden einige der wichtigsten Entscheidungen erläutert, die Sie treffen müssen, wenn Sie eine mehrinstanzenfähige Computelösung planen.

Skalieren

Systeme müssen bei sich änderndem Bedarf angemessen ausgeführt werden. Wenn sich die Anzahl der Mandanten und die Menge des Datenverkehrs erhöhen, müssen Sie möglicherweise die Kapazität Ihrer Ressourcen erhöhen, um mit der wachsenden Anzahl von Mandanten Schritt zu halten und eine akzeptable Leistungsrate aufrechtzuerhalten. Wenn die Anzahl der aktiven Benutzer oder die Menge des Datenverkehrs abnimmt, sollten Sie ebenso die Computekapazität automatisch reduzieren, um die Kosten zu senken, Sie sollten die Kapazität jedoch mit minimalen Auswirkungen auf die Benutzer reduzieren.

Wenn Sie dedizierte Ressourcen für jeden Mandanten bereitstellen, haben Sie die Flexibilität, die Ressourcen der einzelnen Mandanten unabhängig voneinander zu skalieren. In einer Lösung, bei der Computeressourcen von mehreren Mandanten gemeinsam genutzt werden, können alle diese Mandanten die neue Skalierung nutzen, wenn Sie diese Ressourcen skalieren. Sie werden jedoch auch alle beeinträchtigt, wenn die Skalierung nicht ausreicht, um ihre Gesamtlast zu bewältigen. Weitere Informationen finden Sie unter Noisy Neighbor-Problem.

Wenn Sie Cloudlösungen erstellen, können Sie auswählen, ob Sie horizontal oder vertikal skalieren. In einer mehrinstanzenfähigen Lösung mit einer wachsenden Anzahl von Mandanten bietet Ihnen die horizontale Skalierung in der Regel mehr Flexibilität und eine höhere Gesamtskalierungsobergrenze.

Leistungsprobleme bleiben häufig unerkannt, bis eine Anwendung ausgelastet ist. Sie können einen vollständig verwalteten Dienst verwenden, beispielsweise Azure Load Testing, um zu erfahren, wie sich Ihre Anwendung unter Belastung verhält.

Skalierungstrigger

Unabhängig davon, welchen Ansatz Sie für die Skalierung verwenden, müssen Sie in der Regel die Trigger planen, die die Skalierung Ihrer Komponenten bewirken. Wenn Sie über gemeinsam genutzte Komponenten verfügen, berücksichtigen Sie die Workloadmuster jedes Mandanten, der die Ressourcen verwendet, um sicherzustellen, dass die Bereitstellungskapazität die erforderliche Gesamtkapazität erfüllen kann, und um die Wahrscheinlichkeit zu minimieren, dass bei einem Mandanten das Noisy Neighbor-Problem auftritt. Möglicherweise können Sie Ihre Skalierungskapazität auch unter Berücksichtigung der Anzahl der Mandanten planen. Wenn Sie z. B. die Ressourcen messen, die Sie für die Versorgung von 100 Mandanten verwenden, können Sie bei der Integration weiterer Mandanten eine Skalierung so planen, dass sich Ihre Ressourcen für alle weiteren 100 Mandanten verdoppeln.

State

Computeressourcen können zustandslos oder zustandsbehaftet sein. Zustandslose Komponenten verwalten keine Daten zwischen Anforderungen. Aus Sicht der Skalierbarkeit lassen sich zustandslose Komponenten häufig einfach aufskalieren, da Sie schnell neue Worker, Instanzen oder Knoten hinzufügen können und sie sofort mit der Verarbeitung von Anforderungen beginnen können. Wenn Ihre Architektur dies zulässt, können Sie auch Instanzen, die einem Mandanten zugewiesen sind, einen neuen Verwendungszweck zuweisen und einem anderen Mandanten zuordnen.

Zustandsbehaftete Ressourcen können basierend auf dem Zustandstyp, den sie beibehalten, weiter unterteilt werden. Persistenter Zustand bedeutet, dass Daten dauerhaft gespeichert werden müssen. In Cloudlösungen sollten Sie vermeiden, einen persistenten Zustand auf Ihrer Computeebene zu speichern. Verwenden Sie stattdessen Speicherdienste wie Datenbanken oder Speicherkonten. Vorübergehender Zustand bedeutet, dass Daten vorübergehend gespeichert werden; er umfasst schreibgeschützte speicherinterne Caches und die Speicherung temporärer Dateien auf lokalen Datenträgern.

Der vorübergehende Zustand ist oft nützlich, um die Leistung Ihrer Anwendungsebene zu verbessern, indem die Anzahl der Anforderungen an Back-End-Speicherdienste reduziert wird. Wenn Sie beispielsweise einen speicherinternen Cache verwenden, können Sie möglicherweise Leseanforderungen verarbeiten, ohne eine Verbindung mit einer Datenbank herzustellen und ohne eine intensive Abfrage auszuführen, die Sie kürzlich ausgeführt haben, als Sie eine andere Anforderung verarbeitet haben.

Bei Anwendungen mit Latenzempfindlichkeit können die Kosten für die Cachehydration signifikant werden. Eine mehrinstanzenfähige Lösung kann dieses Problem verschärfen, wenn jeder Mandant unterschiedliche Daten zwischenspeichern muss. Um dieses Problem zu beheben, verwenden einige Lösungen Sitzungsaffinität, um sicherzustellen, dass alle Anforderungen für einen bestimmten Benutzer oder Mandanten von demselben Compute-Workerknoten verarbeitet werden. Die Sitzungsaffinität kann zwar die Fähigkeit der Anwendungsebene verbessern, ihren Cache effektiv zu verwenden, sie erschwert jedoch auch die Skalierung und das Ausgleichen der Datenverkehrslast zwischen Workern. Dieser Kompromiss muss sorgfältig bedacht werden. Für viele Anwendungen ist keine Sitzungsaffinität erforderlich.

Es ist auch möglich, Daten in externen Caches wie Azure Cache for Redis zu speichern. Externe Caches sind für den Datenabruf mit geringer Latenz optimiert, während der Zustand von den Computeressourcen isoliert bleibt, sodass sie separat skaliert und verwaltet werden können. In vielen Lösungen ermöglichen Ihnen externe Caches die Verbesserung der Anwendungsleistung, während die Computeebene zustandslos bleibt.

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 entwerfen, haben Sie häufig viele Möglichkeiten, die Isolationsstufe zwischen Mandanten zu berücksichtigen, einschließlich der Bereitstellung freigegebener Computeressourcen, die von allen Mandanten verwendet werden sollen, dedizierter Computeressourcen für jeden Mandanten oder etwas zwischen diesen Extremen. Jede Option bringt Kompromisse mit sich. Um entscheiden zu können, welche Option am besten zu Ihrer Lösung passt, bedenken Sie Ihre Isolationsanforderungen.

Möglicherweise geht es um die logische Isolation von Mandanten und um die Trennung der Verwaltungszuständigkeiten oder -richtlinien, die auf jeden Mandanten angewendet werden. Alternativ müssen Sie möglicherweise unterschiedliche Ressourcenkonfigurationen für bestimmte Mandanten bereitstellen, z. B. die Bereitstellung einer bestimmten SKU eines virtuellen Computers, die sich für die Workload eines Mandanten eignet.

Unabhängig davon, welches Isolationsmodell Sie auswählen, stellen Sie sicher, dass Ihre Mandantendaten auch dann angemessen isoliert bleiben, wenn Komponenten nicht verfügbar sind oder nicht funktionieren. Ziehen Sie die Verwendung vonAzure Chaos Studio als Teil Ihres regulären automatisierten Testprozesses in Betracht, um absichtlich Fehler einzuführen, die reale Ausfälle simulieren, und vergewissern Sie sich, dass es in Ihrer Lösung keine Datenlecks zwischen Mandanten gibt und die Lösung auch unter Druck ordnungsgemäß funktioniert.

Zu berücksichtigende Ansätze und Muster

Autoscale

Azure-Computedienste bieten verschiedene Funktionen zum Skalieren Ihrer Workloads. Viele Computedienste unterstützen die automatische Skalierung, bei der Sie den Zeitpunkt der Skalierung sowie Ihre Mindestebene und maximale Ebene der Skalierung beachten müssen. Welche bestimmten Optionen für die Skalierung verfügbar sind, hängt von den von Ihnen verwendeten Computediensten ab. Sehen Sie sich die folgenden Beispieldienste an:

Muster mit Bereitstellungsstempeln

Weitere Informationen zur Verwendung des Musters mit Bereitstellungsstempeln zur Unterstützung einer mehrinstanzenfähigen Lösung finden Sie unter Übersicht.

Muster „Computeressourcenkonsolidierung“

Das Muster „Computeressourcenkonsolidierung“ hilft Ihnen, eine höhere Dichte von Mandanten für die Computeinfrastruktur zu erreichen, indem Sie die zugrunde liegenden Computeressourcen freigeben. Durch die Freigabe von Computeressourcen können Sie häufig die direkten Kosten dieser Ressourcen reduzieren. Darüber hinaus sind Ihre Verwaltungskosten oft niedriger, da weniger Komponenten verwaltet werden müssen.

Die Computeressourcenkonsolidierung erhöht jedoch die Wahrscheinlichkeit des Noisy Neighbor-Problems. Die Workload eines Mandanten kann einen unverhältnismäßig großen Teil der verfügbaren Computekapazität verbrauchen. Sie können dieses Risiko häufig minimieren, indem Sie sicherstellen, dass Sie Ihre Lösung angemessen skalieren, und indem Sie Kontrollen wie Kontingente und API-Grenzwerte anwenden, um Mandanten zu vermeiden, die mehr als ihren angemessenen Anteil an der Kapazität verbrauchen.

Dieses Muster wird je nach verwendetem Computedienst auf unterschiedliche Weise erreicht. Sehen Sie sich die folgenden Beispieldienste an:

  • Azure App Service und Azure Functions: Stellen Sie freigegebene App Service-Pläne bereit, die die Hostserverinfrastruktur darstellen.
  • Azure Container Apps: Stellen Sie freigegebene Umgebungen bereit.
  • Azure Kubernetes Service (AKS): Stellen Sie freigegebene Pods mit einer mehrinstanzenfähigen Anwendung bereit.
  • Virtual Machines: Stellen Sie eine einzelne Gruppe von virtuellen Computern bereit, die von allen Mandanten verwendet werden soll.

Dedizierte Computeressourcen pro Mandant

Sie können auch dedizierte Computeressourcen für jeden Mandanten bereitstellen. Dedizierte Ressourcen mindern das Risiko des Noisy Neighbor-Problems, indem sie sicherstellen, dass die Computeressourcen für jeden Mandanten von den anderen isoliert sind. Außerdem können Sie eine eigene Konfiguration für die Ressourcen jedes Mandanten entsprechend ihren Anforderungen bereitstellen. Dedizierte Ressourcen sind in der Regel aber mit höheren Kosten verbunden, da Sie eine geringere Dichte von Mandanten für Ressourcen haben.

Abhängig von den von Ihnen verwendeten Azure-Computediensten müssen Sie wie folgt unterschiedliche dedizierte Ressourcen bereitstellen:

  • Azure App Service und Azure Functions: Stellen Sie separate App Service-Pläne für die einzelnen Mandanten bereit.
  • Azure Container Apps: Stellen Sie separate Umgebungen für die einzelnen Mandanten bereit.
  • Azure Kubernetes Service (AKS): Stellen Sie dedizierte Cluster für die einzelnen Mandanten bereit.
  • Virtual Machines: Stellen Sie dedizierte virtuelle Computer für die einzelnen Mandanten bereit.

Teilweise isolierte Computeressourcen

Bei Ansätzen mit teilweiser Isolation müssen Sie Aspekte der Lösung in einer isolierten Konfiguration bereitstellen, während Sie die anderen Komponenten freigeben.

Wenn Sie mit App Service und Azure Functions arbeiten, können Sie unterschiedliche Anwendungen für die einzelnen Mandanten bereitstellen und die Anwendungen auf freigegebenen App Service-Plänen hosten. Bei diesem Ansatz werden die Kosten für Ihre Computeebene gesenkt, da App Service-Pläne die Abrechnungseinheit darstellen. Außerdem können Sie unterschiedliche Konfigurationen und Richtlinien auf die einzelnen Anwendungen anwenden. Dieser Ansatz bringt jedoch das Risiko des Noisy Neighbor-Problems mit sich.

Mit Azure Container Apps können Sie mehrere Anwendungen in einer freigegebenen Umgebung bereitstellen und dann Dapr und andere Tools verwenden, um die einzelnen Anwendungen separat zu konfigurieren.

Azure Kubernetes Service (AKS), und weiter gefasst Kubernetes, bieten eine Vielzahl von Optionen für die Mehrinstanzenfähigkeit, einschließlich Folgendem:

  • Mandantenspezifische Namespaces zur logischen Isolation mandantenspezifischer Ressourcen, die in freigegebenen Clustern und Knotenpools bereitgestellt werden.
  • Mandantenspezifische Knoten oder Knotenpools in einem freigegebenen Cluster.
  • Mandantenspezifische Pods, die möglicherweise denselben Knotenpool verwenden.

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 Anwendungsentwicklermethoden zum Verwalten von Ressourcen in Azure Kubernetes Service (AKS).

Es ist auch wichtig, dass Sie die freigegebenen Komponenten in einem Kubernetes-Cluster kennen und wissen, wie diese Komponenten von der Mehrinstanzenfähigkeit betroffen sein könnten. Beispielsweise ist der Kubernetes-API-Server ein freigegebener Dienst, der im gesamten Cluster verwendet wird. Selbst wenn Sie mandantenspezifische Knotenpools bereitstellen, um die Anwendungsworkloads der Mandanten zu isolieren, kann es auf dem API-Server zu Konflikten aufgrund einer großen Anzahl von Anforderungen zwischen den Mandanten kommen.

Zu vermeide Antimuster

Noisy Neighbor-Antimuster

Immer, wenn Sie Komponenten bereitstellen, die von Mandanten gemeinsam genutzt werden, stellt das Noisy Neighbor-Problem ein potenzielles Risiko dar. Stellen Sie sicher, dass Sie Ressourcengovernance und -überwachung einschließen, um das Risiko zu verringern, dass die Computeworkload eines Mandanten von der Aktivität anderer Mandanten betroffen ist.

Mandantenübergreifende Datenlecks

Computeebenen können mandantenübergreifenden Datenlecks ausgesetzt sein, wenn sie nicht ordnungsgemäß behandelt werden. Dies ist im Allgemeinen kein Thema, das Sie berücksichtigen müssen, wenn Sie einen mehrinstanzenfähigen Dienst in Azure verwenden, da Microsoft Schutz auf Plattformebene bietet. Wenn Sie jedoch Ihre eigene mehrinstanzenfähige Anwendung entwickeln, sollten Sie beachten, ob freigegebene Ressourcen (z. B. lokale Datenträgercaches, RAM und externe Caches) möglicherweise Daten enthalten, die ein anderer Mandant versehentlich anzeigen oder ändern kann.

Antimuster für ausgelastete Front-Ends

Zur Vermeidung des Antimusters für ausgelastete Front-Ends sollten Sie vermeiden, dass Ihre Front-End-Ebene viel Arbeit verrichtet, die von anderen Komponenten oder Ebenen Ihrer Architektur verrichtet werden könnte. 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.

Erwägen Sie stattdessen die Verwendung der asynchronen Verarbeitung, indem Sie Warteschlangen oder andere Messagingdienste verwenden. Bei diesem Ansatz können Sie auch Quality of Service-Steuerelemente (QoS, Dienstqualität) für verschiedene Mandanten entsprechend ihren Anforderungen anwenden. Beispielsweise nutzen alle Mandanten möglicherweise eine gemeinsame Front-End-Ebene gemeinsam, Mandanten, die für eine höhere Dienstebene bezahlen, verfügen jedoch möglicherweise über einen höheren Satz dedizierter Ressourcen, um die Arbeit aus ihren Warteschlangennachrichten zu verarbeiten.

Unflexible 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 Burstbereich höher ist und die Auswirkungen größer sind, wenn Sie über mehr Mandanten mit unterschiedlichen Nutzungsmustern verfügen.

Stellen Sie sicher, dass Sie die Anpassungsfähigkeit und Skalierung der Cloud gut nutzen. Überlegen Sie, ob Sie horizontale oder vertikale Skalierung verwenden sollten, und verwenden Sie die automatische Skalierung, um Lastspitzen automatisch zu bewältigen. Testen Sie Ihre Lösung, um zu verstehen, wie sie sich bei verschiedenen Lastniveaus verhält. Stellen Sie sicher, dass Sie die in der Produktion erwarteten Lastvolumen und Ihr erwartetes Wachstum miteinbeziehen. Sie können einen vollständig verwalteten Dienst verwenden, beispielsweise Azure Load Testing, um zu erfahren, wie sich Ihre Anwendung unter Belastung verhält.

Antimuster „Kein Caching“

Das Antimuster „Kein Caching“ bedeutet, dass die Leistung Ihrer Lösung beeinträchtigt wird, da die Anwendungsebene wiederholt Informationen anfordert oder neu berechnet, die zwischen Anforderungen wiederverwendet werden könnten. Wenn Sie über Daten verfügen, die freigegeben werden können, entweder zwischen Mandanten oder zwischen Benutzern innerhalb eines einzelnen Mandanten, lohnt es sich wahrscheinlich, sie zwischenzuspeichern, um die Last auf Ihrer Back-End-/Datenbankebene zu reduzieren.

Unnötige Zustandsbehaftung

Das Antimuster „Kein Caching“ hat zur Folge, 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 Cache for Redis.

Beitragende

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

Hauptautoren:

  • Dixit Arora | Senior Customer Engineer, FastTrack for Azure
  • John Downs | Principal Software Engineer

Andere Mitwirkende:

Nächste Schritte

Lesen Sie die dienstspezifische Anleitung für Ihre Computedienste: