Muster mit Bereitstellungsstempeln

Das Muster mit Bereitstellungsstempeln umfasst das Bereitstellen, Verwalten und Überwachen einer heterogenen Gruppe von Ressourcen, um mehrere Workloads oder Mandanten zu hosten und zu betreiben. Die einzelnen Kopien werden als Stempel oder mitunter auch als Diensteinheit, Skalierungseinheit oder Zelle bezeichnet. In einer mehrinstanzenfähigen Umgebung kann jeder Stempel bzw. jede Skalierungseinheit von einer vordefinierten Anzahl von Mandanten genutzt werden. Mehrere Stempel können bereitgestellt werden, um die Lösung nahezu linear zu skalieren und eine wachsende Anzahl von Mandanten zu bedienen. Diese Vorgehensweise kann die Skalierbarkeit Ihrer Lösung verbessern und ermöglicht es Ihnen, Instanzen in mehreren Regionen bereitzustellen sowie Ihre Kundendaten zu trennen.

Kontext und Problem

Beim Hosten einer Anwendung in der Cloud ist es wichtig, die Leistung und Zuverlässigkeit Ihrer Anwendung zu berücksichtigen. Wenn Sie eine einzelne Instanz Ihrer Lösung hosten, gelten für Sie möglicherweise die folgenden Einschränkungen:

• Skalierungslimits. Bei der Bereitstellung einer einzelnen Instanz Ihrer Anwendung können der Skalierung natürliche Grenzen gesetzt sein. Es ist beispielsweise möglich, dass von Ihnen verwendete Dienste die Anzahl von eingehenden Verbindungen, Hostnamen, TCP-Sockets oder anderen Ressourcen beschränken.
• Nicht lineare Skalierung oder Kosten. Einige Komponenten Ihrer Lösung werden möglicherweise nicht linear mit der Anzahl von Anforderungen oder der Datenmenge skaliert. Stattdessen kann es beim Erreichen eines Schwellenwerts zu einer plötzlichen Abnahme der Leistung oder Zunahme der Kosten kommen. Beispielsweise können Sie bei der Verwendung einer Datenbank feststellen, dass die Grenzkosten für das Hinzufügen zusätzlicher Kapazität (zentrales Hochskalieren) unerschwinglich werden und eine horizontale Skalierung die kostengünstigere Strategie ist.
• Trennung von Kunden. Möglicherweise müssen Sie die Daten bestimmter Kunden von denen anderer Kunden isolieren. Ebenso ist es möglich, dass manche Ihrer Kunden mehr Systemressourcen benötigen als andere und Sie daher erwägen, sie in verschiedenen Infrastrukturgruppen zusammenzufassen.
• Unterstützung von Instanzen mit einem einzelnen und mehreren Mandanten. Möglicherweise haben Sie einige große Kunden, die eigene unabhängige Instanzen Ihrer Lösung benötigen. Vielleicht haben Sie außerdem einen Pool kleinerer Kunden, die eine mehrinstanzenfähige Bereitstellung gemeinsam nutzen können.
• Komplexe Bereitstellungsanforderungen. Möglicherweise müssen Sie kontrolliert Updates für Ihren Dienst bereitstellen und zu unterschiedlichen Zeitpunkten eine Bereitstellung verschiedener Teilmengen für Ihren Kundenstamm vornehmen.
• Häufigkeit der Aktualisierung. Für einige Ihrer Kunden können häufige Updates Ihres Systems akzeptabel sein, während andere die damit einhergehenden Risiken scheuen und seltene Aktualisierungen des zur Verarbeitung ihrer Anforderungen eingesetzten Systems wünschen. In einem solchen Fall kann es sinnvoll sein, die Bereitstellungen für diese Kunden in isolierten Umgebungen vorzunehmen.
• Geografische oder geopolitische Einschränkungen. Um geringe Wartezeiten sicherzustellen oder die Anforderungen an die Datenhoheit zu erfüllen, stellen Sie einige Ihrer Kunden möglicherweise in bestimmten Regionen bereit.

Diese Einschränkungen gelten häufig für unabhängige Softwareanbieter (ISVs), die Software-as-a-Service (SaaS) erstellen, welche häufig mehrinstanzenfähig konzipiert sind. Die gleichen Einschränkungen können jedoch auch für andere Szenarien gelten.

Lösung

Zur Vermeidung dieser Probleme empfiehlt es sich gegebenenfalls, Ressourcen in Skalierungseinheiten zu gruppieren und mehrere Kopien Ihrer Stempel bereitzustellen. Von jeder Skalierungseinheit wird jeweils eine Teilmenge Ihrer Mandanten gehostet und bedient. Stempel arbeiten unabhängig voneinander und können unabhängig voneinander bereitgestellt und aktualisiert werden. Eine einzelne geografische Region kann einen einzelnen Stempel oder mehrere Stempel enthalten, um eine horizontale Skalierung innerhalb der Region zu ermöglichen. Stempel enthalten eine Teilmenge Ihrer Kunden.

Bereitstellungsstempel können unabhängig davon angewendet werden, ob Ihre Lösung IaaS-Komponenten (Infrastructure-as-a-Service) oder PaaS-Komponenten (Platform-as-a-Service) oder eine Kombination von beidem verwendet. In der Regel ist die Skalierung von IaaS-Workloads aufwändiger. Das Muster kann daher bei IaaS-intensiven Workloads nützlich sein, um das Aufskalieren zu ermöglichen.

Stempel können zum Implementieren von Bereitstellungsringen verwendet werden. Kunden, die Dienstupdates in unterschiedlichen Abständen wünschen, können in verschiedenen Stempeln gruppiert werden, für die Sie Updates jeweils in einem eigenen Rhythmus bereitstellen.

Da Stempel unabhängig voneinander ausgeführt werden, werden Daten implizit horizontal partitioniert. Zudem kann innerhalb einzelner Stempel durch weitere horizontale Partitionierung für Skalierbarkeit und Elastizität gesorgt werden.

Das Muster mit Bereitstellungsstempeln wird von vielen Azure-Diensten intern verwendet, z. B. App Service, Azure Stack und Azure Storage.

Bereitstellungsstempel sind mit geografischen Knoten („Geodes“) verwandt, aber nicht identisch. Bei einer Architektur mit Bereitstellungsstempeln werden mehrere unabhängige Instanzen Ihres Systems bereitgestellt und enthalten eine Teilmenge Ihrer Kunden und Benutzer. Bei geografischen Knoten (Englisch: „Geodes“) können alle Instanzen Anforderungen aller Benutzer bereitstellen, aber das Entwerfen und Entwickeln dieser Art von Architektur ist häufig komplexer. Sie können auch erwägen, die beiden Muster in einer Lösung zu mischen. Der weiter unten in diesem Artikel beschriebene Ansatz für das Datenverkehrsrouting ist ein Beispiel für ein solches Hybridszenario.

Bereitstellung

Aufgrund der Komplexität, die die Bereitstellung identischer Kopien derselben Komponenten mit sich bringt, sind gute DevOps-Methoden für eine erfolgreiche Implementierung dieses Musters entscheidend. Beschreiben Sie Ihre Infrastruktur ggf. als Code – beispielsweise mit Bicep, JSON-ARM-Vorlagen (Azure Resource Manager), Terraform und Skripts. Mit diesem Ansatz können Sie eine vorhersagbare und wiederholbare Bereitstellung jedes Stempels gewährleisten. Außerdem wird dadurch die Wahrscheinlichkeit von menschlichen Fehlern verringert, etwa von versehentlichen Konfigurationskonflikten zwischen Stempeln.

Sie können Updates automatisch für alle Stempel gleichzeitig bereitstellen. In diesem Fall können Sie die Bereitstellung Ihrer Infrastruktur und Anwendungen mit Technologien wie Bicep- oder Resource Manager-Vorlagen koordinieren. Alternativ können Sie Updates zuerst nur für einige Stempel und dann nach und nach für andere bereitstellen. Erwägen Sie die Verwendung eines Releaseverwaltungstools wie Azure Pipelines oder GitHub Actions, um Bereitstellungen für jeden Stempel zu orchestrieren. Weitere Informationen finden Sie unter

• Integration von Bicep in Azure Pipelines
• Integrieren von ARM-Vorlagen in Azure Pipelines

Prüfen Sie die Topologie der Azure-Abonnements und -Ressourcengruppen für Ihre Bereitstellungen sorgfältig:

• Ein Abonnement enthält in der Regel alle Ressourcen für eine einzelne Lösung. Im Allgemeinen sollten Sie daher die Verwendung eines einzelnen Abonnements für alle Stempel in Erwägung ziehen. Bei einigen Azure-Diensten gelten aber abonnementweite Kontingente. Wenn Sie mit diesem Muster eine hohe Skalierbarkeit erzielen möchten, müssen Sie Stempel daher ggf. in verschiedenen Abonnements bereitstellen.
• Ressourcengruppen werden in der Regel verwendet, um Komponenten mit dem gleichen Lebenszyklus bereitzustellen. Wenn Sie vorhaben, Updates für alle Ihre Stempel gleichzeitig bereitzustellen, können Sie eine einzige Ressourcengruppe für alle Komponenten sämtlicher Stempel verwenden und mithilfe der Namenskonventionen und Tags für Ressourcen angeben, welche Komponenten zu den einzelnen Stempeln gehören. Falls Sie Updates für die einzelnen Stempel unabhängig voneinander bereitstellen möchten, können Sie dagegen die Bereitstellung jedes Stempels in einer eigenen Ressourcengruppe erwägen.

Kapazitätsplanung

Ermitteln Sie mithilfe von Auslastungs- und Leistungstests die ungefähre maximale Auslastung eines Stempels. Auslastungsmetriken können auf der Anzahl von Kunden/Mandanten basieren, die ein einzelner Stempel unterstützt, oder auf Metriken der Dienste, die die Komponenten im Stempel ausgeben. Stellen Sie sicher, dass Sie über eine ausreichende Instrumentierung verfügen, um das Erreichen der Kapazität eines Stempels festzustellen, und neue Stempel je nach Bedarf schnell bereitstellen können.

Routing von Datenverkehr

Das Muster mit Bereitstellungsstempeln funktioniert gut, wenn jeder Stempel separat behandelt wird. Angenommen, Contoso stellt die gleiche API-Anwendung in mehreren Stempeln bereit. In diesem Fall könnte Datenverkehr mithilfe von DNS an die entsprechenden Stempel weitergeleitet werden:

• unit1.aus.myapi.contoso.com leitet Datenverkehr an den Stempel unit1 in einer Region in Australien weiter.
• unit2.aus.myapi.contoso.com leitet Datenverkehr an den Stempel unit2 in einer Region in Australien weiter.
• unit1.eu.myapi.contoso.com leitet Datenverkehr an den Stempel unit1 in einer Region in Europa weiter.

Clients sind dann dafür verantwortlich, eine Verbindung mit dem richtigen Stempel herzustellen.

Wenn ein einzelner Eingangspunkt für den gesamten Datenverkehr erforderlich ist, kann ein Datenverkehrsroutingdienst verwendet werden, um den Stempel für eine bestimmte Anforderung, einen Kunden oder einen Mandanten aufzulösen. Der Datenverkehrsroutingdienst leitet den Client entweder an die relevante URL für den Stempel weiter (z. B. mithilfe eines HTTP 302-Antwortstatuscodes), oder er fungiert als Reverseproxy und leitet den Datenverkehr ohne Wissen des Clients an den jeweiligen Stempel weiter.

Der Entwurf eines zentralisierten Datenverkehrsroutingdiensts kann insbesondere bei einer regionsübergreifend ausgeführten Lösung schwierig sein. Erwägen Sie, den Datenverkehrsroutingdienst in mehreren Regionen bereitzustellen (d. h. möglicherweise in jeder Region, in der Stempel bereitgestellt werden) und anschließend sicherzustellen, dass der Datenspeicher (Zuordnung von Mandanten zu Stempeln) synchronisiert wird. Die Komponente für Datenverkehrsrouting kann auch selbst eine Instanz des Musters mit geografischen Knoten sein.

Als Datenverkehrsroutingdienst kann beispielsweise Azure API Management bereitgestellt werden. Der Dienst kann den entsprechenden Stempel für eine Anforderung ermitteln, indem er in einer Azure Cosmos DB-Sammlung, in der die Zuordnung zwischen Mandanten und Stempeln gespeichert ist, nach Daten sucht. API Management kann dann die Back-End-URL dynamisch auf den API-Dienst des jeweiligen Stempels festlegen.

Um die geografische Verteilung von Anforderungen zu ermöglichen und für Georedundanz des Datenverkehrsroutingdiensts zu sorgen, kann API Management in mehreren Regionen bereitgestellt oder Datenverkehr mit Azure Front Door an die nächstgelegene Instanz weitergeleitet werden. Front Door kann mit einem Back-End-Pool konfiguriert werden, damit Anforderungen an die nächste verfügbare API Management-Instanz weitergeleitet werden können. Wenn Ihre Anwendung nicht über HTTP/S verfügbar gemacht wird, können Sie einen regionsübergreifende Azure Load Balancer-Instanz verwenden, um eingehende Aufrufe an regionale Azure Load Balancer-Instanzen zu verteilen. Mit dem globalen Verteilungsfeature von Azure Cosmos DB können die Zuordnungsinformationen in jeder Region aktualisiert werden.

Wenn Ihre Lösung einen Datenverkehrsroutingdienst umfasst, prüfen Sie, ob er als Gateway fungiert und somit die Gatewayabladung für die anderen Dienste wie die Tokenüberprüfung, Drosselung und Autorisierung ausführen kann.

Beispielarchitektur für das Datenverkehrsrouting

Betrachten Sie die folgende Beispielarchitektur für das Datenverkehrsrouting, die Azure Front Door, Azure API Management und Azure Cosmos DB für globales Datenverkehrsrouting und dann eine Reihe regionsspezifischer Stempel verwendet:

Angenommen, ein Benutzer befindet sich normalerweise in New York. Seine Daten werden im Stempel 3 in der Region „USA, Osten“ gespeichert.

Wenn der Benutzer nach Kalifornien reist und dann auf das System zugreift, wird seine Verbindung wahrscheinlich über die Region „USA, Westen 2“ geleitet, da diese seinem geografischen Standort am nächsten ist, wenn er die Anforderung stellt. Die Anforderung muss jedoch letztendlich von Stempel 3 verarbeitet werden, da seine Daten dort gespeichert sind. Das Datenverkehrsroutingsystem stellt sicher, dass die Anforderung an den richtigen Stempel weitergeleitet wird.

Probleme und Überlegungen

Bei der Entscheidung, wie dieses Muster implementiert werden soll, sind die folgenden Punkte zu beachten:

• Bereitstellungsprozess. Wenn Sie mehrere Stempel bereitstellen, ist die Verwendung automatisierter und vollständig wiederholbarer Bereitstellungsprozesse äußerst empfehlenswert. Verwenden Sie ggf. Bicep, JSON-ARM-Vorlagen oder Terraform-Module, um Ihre Stempel deklarativ zu definieren und die Definitionen konsistent zu halten.
• Stempelübergreifende Vorgänge. Wenn Ihre Lösung unabhängig über mehrere Stempel hinweg bereitgestellt wird, kann die Beantwortung von Fragen wie der nach der Anzahl von Kunden für alle Stempel schwierig sein. Möglicherweise müssen Abfragen für jeden Stempel ausgeführt und die Ergebnisse aggregiert werden. Alternativ können Sie festlegen, dass die Daten aller Stempel zur konsolidierten Berichterstellung in einem zentralisierten Data Warehouse veröffentlicht werden.
• Festlegen von Richtlinien für die horizontale Skalierung. Stempel verfügen über eine begrenzte Kapazität, die auf einer Proxymetrik wie der Anzahl bereitstellbarer Mandanten für den Stempel beruhen kann. Es ist wichtig, die verfügbare und genutzte Kapazität für jeden Stempel zu überwachen und zusätzliche Stempel proaktiv bereitzustellen, damit neue Mandanten an diese weitergeleitet werden können.
• Mindestanzahl von Stempeln. Wenn Sie das Muster mit Bereitstellungsstempeln verwenden, empfiehlt es sich, mindestens zwei Stempel Ihrer Lösung bereitzustellen. Wenn Sie nur einen einzelnen Stempel bereitstellen, können Sie leicht versehentlich Annahmen in Ihrem Code oder Ihrer Konfiguration hartcodieren, die beim Aufskalieren nicht angewendet wird.
• Kosten: Das Muster mit Bereitstellungsstempeln erfordert die Bereitstellung mehrerer Kopien Ihrer Infrastrukturkomponente. Die Betriebskosten Ihrer Lösung werden daher wahrscheinlich deutlich zunehmen.
• Verschieben zwischen Stempeln. Jeder Stempel wird unabhängig bereitgestellt und ausgeführt, daher kann das Verschieben von Mandanten zwischen Stempeln schwierig sein. Um die Informationen zu einem bestimmten Kunden in einen anderen Stempel zu übertragen und die Informationen des Mandanten dann aus dem ursprünglichen Stempel zu entfernen, wäre eine benutzerdefinierte Logik für Ihre Anwendung erforderlich. Dieser Prozess erfordert für die Kommunikation zwischen Stempeln möglicherweise eine Backplane, die die Komplexität der gesamten Lösung zusätzlich erhöhen würde.
• Datenverkehrsrouting. Wie weiter oben in diesem Artikel beschrieben, kann eine zusätzliche Komponente zum Auflösen von Mandanten in Stempel erforderlich sein, um Datenverkehr für eine bestimmte Anforderung an den richtigen Stempel weiterzuleiten. Diese Komponente muss wiederum möglicherweise hoch verfügbar sein.
• Gemeinsam genutzte Komponenten. Vielleicht verfügen Sie über einige Komponenten, die stempelübergreifend gemeinsam genutzt werden können. Wenn Sie beispielsweise eine freigegebene Single-Page-App für alle Mandanten haben, kann es sinnvoll sein, diese in einer Region bereitzustellen und mit Azure CDN global zu replizieren.

Verwendung dieses Musters

Dieses Muster ist hilfreich, wenn Folgendes gilt:

• Der Skalierbarkeit sind keine natürlichen Grenzen gesetzt. Wenn einige Komponenten beispielsweise nicht über eine bestimmte Anzahl von Kunden oder Anforderungen hinaus skaliert werden können oder sollten, erwägen Sie die horizontale Skalierung mithilfe von Stempeln.
• Bestimmte Mandanten müssen von anderen getrennt werden. Wenn Sie Kunden haben, die aus Sicherheitsgründen nicht zusammen mit anderen Kunden in einem mehrinstanzenfähigen Stempel bereitgestellt werden können, können Sie diese auf einem eigenen isolierten Stempel bereitstellen.
• Sie müssen für einige Mandanten gleichzeitig verschiedene Versionen Ihrer Lösung verwenden.
• Sie haben Anwendungen in mehreren Regionen, bei denen die Daten und der Datenverkehr jedes Mandanten in eine bestimmte Region weitergeleitet werden müssen.
• Sie möchten Resilienz bei Ausfällen sicherstellen. Da Stempel unabhängig voneinander sind, sollten in anderen Stempeln bereitgestellte Mandanten nicht von einem Ausfall eines einzelnen Stempels betroffen sein. Durch diese Isolation lassen sich die Auswirkungen eines Vorfalls oder Ausfalls eindämmen.

Dieses Muster ist für folgende Fälle nicht geeignet:

• Einfache Lösungen, die keine hohe Skalierbarkeit erfordern.
• Systeme, die innerhalb einer einzelnen Instanz einfach horizontal oder zentral hochskaliert werden können, z. B. durch Vergrößern der Anwendungsschicht oder Erhöhen der reservierten Kapazität für Datenbanken und die Speicherebene.
• Lösungen, bei denen Daten auf allen bereitgestellten Instanzen repliziert werden sollen. Erwägen Sie, das Muster mit geografischen Knoten für dieses Szenario zu verwenden.
• Lösungen, bei denen nur einige Komponenten skaliert werden müssen. Überlegen Sie beispielsweise, ob Ihre Lösung durch horizontales Partitionieren des Datenspeichers skaliert werden kann, anstatt eine neue Kopie aller Lösungskomponenten bereitzustellen.
• Lösungen mit ausschließlich statischen Inhalten, z. B. eine Front-End-JavaScript-Anwendung. Erwägen Sie, solche Inhalte in einem Speicherkonto zu speichern und Azure CDN zu verwenden.

Workloadentwurf

Ein Architekt sollte evaluieren, wie das Deployment Stamps-Muster im Design seines Workloads verwendet werden kann, um die Ziele und Prinzipien zu erreichen, die in den Azure Well-Architected Framework-Säulen behandelt werden. Zum Beispiel:

Berücksichtigen Sie wie bei jeder Designentscheidung alle Kompromisse im Hinblick auf die Ziele der anderen Säulen, die mit diesem Muster eingeführt werden könnten.

Unterstützende Technologien

• Infrastructure-as-Code, beispielsweise Bicep, Resource Manager-Vorlagen, die Azure-Befehlszeilenschnittstelle (Azure CLI), Terraform, PowerShell und Bash.
• Azure Front Door kann Datenverkehr an einen bestimmten Stempel oder einen Datenverkehrsroutingdienst weiterleiten.

Beispiel

Im folgenden Beispiel werden mehrere Stempel einer einfachen PaaS-Lösung mit einer App Service-Instanz und einer SQL-Datenbank in jedem Stempel bereitgestellt. Stempel können in jeder Region konfiguriert werden, die die in der Vorlage bereitgestellten Dienste unterstützt. Zu Veranschaulichungszwecken stellt diese Vorlage jedoch zwei Stempel in der Region „USA, Westen 2“ und einen weiteren Stempel in der Region „Europa, Westen“ bereit. Die App Service-Instanz erhält innerhalb eines Stempels einen eigenen öffentlichen DNS-Hostnamen und kann Verbindungen unabhängig von allen anderen Stempeln empfangen.

Klicken Sie auf den Link unten, um die Lösung bereitzustellen.

Beispiellösung für das Datenverkehrsrouting

Im folgenden Beispiel wird eine Implementierung einer Datenverkehrsroutinglösung bereitgestellt, die mit einer Reihe von Bereitstellungsstempeln für eine hypothetische API-Anwendung verwendet werden kann. Um die geografische Verteilung eingehender Anforderungen zu ermöglichen, wird Front Door zusammen mit mehreren Instanzen von API Management im Verbrauchstarif bereitgestellt. Jede API Management-Instanz liest die Mandanten-ID in der Anforderungs-URL und sucht dann in einem geografisch verteilten Azure Cosmos DB-Datenspeicher nach dem relevanten Stempel für die Anforderung. Die Anforderung wird dann an den entsprechenden Back-End-Stempel weitergeleitet.

Klicken Sie auf den Link unten, um die Lösung bereitzustellen.

Beitragende

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

Hauptautor:

• John Downs | Principal Program Manager

Andere Mitwirkende:

• Daniel Larsen | Principal Customer Engineer, FastTrack for Azure
• Angel Lopez | Senior Software Engineer, Azure Patterns and Practices
• Paolo Salvatori | Principal Customer Engineer, FastTrack for Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

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

Zugehörige Ressourcen

• Horizontales Partitionieren ist ein weiterer einfacherer Ansatz zum Aufskalieren Ihrer Datenschicht. Stempel partitionieren ihre Daten implizit horizontal, das horizontale Partitionieren erfordert jedoch keinen Bereitstellungsstempel. Weitere Informationen finden Sie unter Sharding Pattern.
• Wenn ein Datenverkehrsroutingdienst bereitgestellt wird, können die Muster Gatewayrouting und Gatewayabladung zusammen verwendet werden, um diese Komponente optimal zu nutzen.