Empfehlungen zum Entwerfen einer zuverlässigen Skalierungsstrategie

  • Artikel

Gilt für die folgende Prüfliste für die Zuverlässigkeit von Azure Well-Architected Framework:

RE:06 Implementieren Sie eine zeitnahe und zuverlässige Skalierungsstrategie auf Anwendungs-, Daten- und Infrastrukturebene.

Verwandte Anleitung:Datenpartitionierung

In diesem Leitfaden werden die Empfehlungen zum Entwerfen einer zuverlässigen Skalierungsstrategie beschrieben.

Definitionen

Begriff Definition
Vertikale Skalierung Ein Skalierungsansatz, der vorhandenen Ressourcen Computekapazität hinzufügt.
Horizontale Skalierung Ein Skalierungsansatz, der Instanzen eines bestimmten Ressourcentyps hinzufügt.
Automatische Skalierung Ein Skalierungsansatz, der Ressourcen automatisch hinzufügt oder entfernt, wenn eine Reihe von Bedingungen erfüllt ist.

Hinweis

Skalierungsvorgänge können statisch (regelmäßig geplante tägliche Skalierung zur Aufnahme normaler Auslastungsmuster), automatisch (ein automatisierter Prozess als Reaktion auf erfüllte Bedingungen) oder manuell (ein Operator führt einen einmaligen Skalierungsvorgang als Reaktion auf eine unerwartete Laständerung durch). Sowohl vertikale als auch horizontale Skalierung kann mit einer dieser Methoden durchgeführt werden. Die automatische vertikale Skalierung erfordert jedoch zusätzliche benutzerdefinierte Automatisierungsentwicklung und kann abhängig von den zu skalierenden Ressourcen zu Ausfallzeiten führen.

Wichtige Entwurfsstrategien

Um eine zuverlässige Skalierungsstrategie für Ihre Workloads zu entwerfen, konzentrieren Sie sich auf die Identifizierung von Auslastungsmustern für die Benutzer- und Systemflows für jede Workload, die zu einem Skalierungsvorgang führt. Hier finden Sie Beispiele für die unterschiedlichen Auslastungsmuster:

  • Statisch: Jede Nacht um 23 Uhr EST liegt die Anzahl der aktiven Benutzer unter 100, und die CPU-Auslastung der App-Server sinkt auf allen Knoten um 90 %.

  • Dynamisch, regelmäßig und vorhersagbar: Jeden Montagmorgen melden sich 1.000 Mitarbeiter aus mehreren Regionen beim ERP-System an.

  • Dynamisch, unregelmäßig und vorhersagbar: Eine Produkteinführung findet am ersten Tag des Monats statt, und es gibt historische Daten aus früheren Starts, wie der Datenverkehr in diesen Situationen zunimmt.

  • Dynamisch, unregelmäßig und unvorhersehbar: Ein groß angelegtes Ereignis verursacht einen Anstieg der Nachfrage nach einem Produkt. Beispielsweise können Unternehmen, die Luftentfeuchter herstellen und verkaufen, nach einem Hurrikan oder einem anderen Überschwemmungsereignis einen plötzlichen Verkehrsanstieg erleben, wenn Menschen in den betroffenen Gebieten Räume in ihrem Haus trocknen müssen.

Nachdem Sie diese Arten von Lademustern identifiziert haben, können Sie Folgendes ausführen:

  • Identifizieren Sie, wie sich die mit den einzelnen Mustern verknüpfte Laständerung auf Ihre Infrastruktur auswirkt.

  • Erstellen Sie eine Automatisierung, um die Skalierung zuverlässig zu adressieren.

In den vorherigen Beispielen können Ihre Skalierungsstrategien wie folgt sein:

  • Statisch: Sie verfügen über eine geplante Skalierung Ihrer Computeknoten auf die Mindestanzahl (2) zwischen 23:00 Uhr und 6:00 Uhr EST.

  • Dynamisch, regelmäßig und vorhersagbar: Sie haben eine geplante Skalierung Ihrer Computeknoten auf die normale tägliche Kapazität, bevor die erste Region mit der Arbeit beginnt.

  • Dynamisch, unregelmäßig und vorhersagbar: Sie definieren ein einmaliges geplantes Hochskalieren Ihrer Compute- und Datenbankinstanzen am Morgen einer Produkteinführung, und Sie werden nach einer Woche wieder herunterskaliert.

  • Dynamisch, unregelmäßig und unvorhersehbar: Sie haben Schwellenwerte für die automatische Skalierung definiert, um ungeplante Datenverkehrsspitzen zu berücksichtigen.

Achten Sie beim Entwerfen Ihrer Skalierungsautomatisierung darauf, die folgenden Probleme zu berücksichtigen:

  • Dass alle Komponenten Ihrer Workload Kandidaten für die Skalierung der Implementierung sein sollten. In den meisten Fällen skalieren globale Dienste wie Microsoft Entra ID automatisch und transparent für Sie und Ihre Kunden. Stellen Sie sicher, dass Sie die Skalierungsfunktionen Ihrer Netzwerkeingangs- und Ausgangscontroller und Ihre Lastenausgleichslösung kennen.

  • Diese Komponenten, die nicht skaliert werden können. Ein Beispiel wären große relationale Datenbanken, für die Sharding nicht aktiviert ist und die ohne erhebliche Auswirkungen nicht umgestaltet werden können. Dokumentieren Sie die von Ihrem Cloudanbieter veröffentlichten Ressourcengrenzwerte, und überwachen Sie diese Ressourcen genau. Beziehen Sie diese spezifischen Ressourcen in Ihre zukünftige Planung für die Migration zu skalierbaren Diensten ein.

  • Die Zeit, die zum Ausführen des Skalierungsvorgangs benötigt wird, damit Sie den Vorgang ordnungsgemäß planen, bevor die zusätzliche Last Ihre Infrastruktur erreicht. Wenn die Skalierung einer Komponente wie API Management beispielsweise 45 Minuten dauert, kann das Anpassen des Skalierungsschwellenwerts auf 65 % anstelle von 90 % ihnen helfen, früher zu skalieren und sich auf den erwarteten Lastanstieg vorzubereiten.

  • Die Beziehung der Komponenten des Flusses in Bezug auf die Reihenfolge der Skalierungsvorgänge. Stellen Sie sicher, dass Sie eine nachgeschaltete Komponente nicht versehentlich überladen, indem Sie zuerst eine Upstream Komponente skalieren.

  • Alle zustandsbehafteten Anwendungselemente, die möglicherweise durch einen Skalierungsvorgang und eine sitzungsaffine Affinität (oder Sitzungsbindung) unterbrochen werden, die implementiert wird. Klebrigkeit kann Ihre Skalierungsfähigkeit einschränken und single points of Failure einführen.

  • Potenzielle Engpässe. Das Horizontalskalieren behebt nicht jedes Leistungsproblem. Wenn ihre Back-End-Datenbank beispielsweise den Engpass darstellt, hilft es nicht, weitere Webserver hinzuzufügen. Identifizieren und beheben Sie zuerst die Engpässe im System, bevor Sie einfach weitere Instanzen hinzufügen. Zustandsbehaftete Teile des Systems sind die wahrscheinlichste Ursache von Engpässen.

Das Befolgen des Entwurfsmusters für Bereitstellungsstempel hilft Ihnen bei der gesamten Infrastrukturverwaltung. Es ist ebenfalls vorteilhaft, ihren Skalierungsentwurf auf Stempeln als Skalierungseinheiten zu stützen. Außerdem können Sie Ihre Skalierungsvorgänge über mehrere Workloads und Teilmengen von Workloads hinweg genau steuern. Anstatt die Skalierungszeitpläne und die automatische Skalierung von Schwellenwerten für viele verschiedene Ressourcen zu verwalten, können Sie einen begrenzten Satz von Skalierungsdefinitionen auf einen Bereitstellungsstempel anwenden und dann nach Bedarf Stempel Spiegel.

Kompromiss: Das Hochskalieren wirkt sich auf die Kosten aus. Optimieren Sie also Ihre Strategie so schnell wie möglich herunterskalieren, um die Kosten unter Kontrolle zu halten. Stellen Sie sicher, dass die Automatisierung, die Sie zum Hochskalieren verwenden, auch Trigger zum Herunterskalieren enthält.

Azure-Erleichterung

Ein Feature zur automatischen Skalierung ist in vielen Azure-Diensten verfügbar. Sie können problemlos Bedingungen konfigurieren, um Instanzen automatisch horizontal zu skalieren. Einige Dienste verfügen über eingeschränkte oder keine integrierte Funktionalität, die automatisch skaliert werden kann. Achten Sie daher darauf, diese Fälle zu dokumentieren und Prozesse für die Skalierung in zu definieren.

Viele Azure-Dienste bieten APIs, mit denen Sie benutzerdefinierte automatische Skalierungsvorgänge mit Azure Automation entwerfen können, z. B. die Codebeispiele unter Automatische Skalierung Ihres Azure IoT Hub. Sie können Tools wie KEDA für die ereignisgesteuerte automatische Skalierung verwenden, die in Azure Kubernetes Service und Azure Container Apps verfügbar ist.

Die automatische Skalierung von Azure Monitor bietet einen allgemeinen Satz automatischer Skalierungsfunktionen für Azure Virtual Machine Scale Sets, Azure App Service, Azure Spring Apps und mehr. Die Skalierung kann nach einem Zeitplan oder basierend auf einer Laufzeitmetrik durchgeführt werden, z. B. CPU- oder Arbeitsspeicherauslastung. Bewährte Methoden finden Sie im Azure Monitor-Leitfaden .

Kompromisse

Überlegungen zur automatischen Skalierung

Die automatische Skalierung ist keine sofortige Lösung. Durch das einfache Hinzufügen von Ressourcen zu einem System oder durch das Ausführen mehrerer Instanzen eines Prozesses kann nicht sichergestellt werden, dass sich die Leistung des Systems verbessert. Beim Entwerfen einer Strategie für die automatische Skalierung sollten Sie folgende Punkte berücksichtigen:

Das System muss so entworfen werden, dass es horizontal skalierbar ist. Vermeiden Sie Annahmen über instance Affinität. Entwerfen Sie keine Lösungen, die erfordern, dass der Code immer in einem bestimmten instance eines Prozesses ausgeführt wird. Gehen Sie beim horizontalen Skalieren eines Clouddiensts oder einer Website nicht davon aus, dass eine Reihe von Anforderungen von derselben Quelle immer an dieselbe instance weitergeleitet wird. Aus demselben Grund sollten Sie statusfreie Dienste entwerfen, um zu vermeiden, dass eine Reihe von Anforderungen von einer Anwendung immer an dieselbe Instanz eines Diensts weitergeleitet werden müssen. Beim Entwerfen eines Diensts, der Nachrichten aus einer Warteschlange liest und verarbeitet, sollten Sie nicht voraussetzen, dass eine bestimmte Instanz des Diensts eine bestimmte Nachricht verarbeitet. Durch die automatische Skalierung können weitere Instanzen eines Diensts gestartet werden, wenn die Warteschlangenlänge zunimmt. Im Artikel zum Muster „Konkurrierende Consumer“ wird beschrieben, wie Sie bei diesem Szenario vorgehen.

Wenn die Lösung einen lang andauernden Task implementiert, entwerfen Sie diesen Task so, dass er das horizontale Hoch- und Herunterskalieren unterstützt. Ohne die gebotene Sorgfalt könnte eine solche Aufgabe verhindern, dass eine instance eines Prozesses beim Hochskalieren des Systems sauber heruntergefahren wird. Oder es könnten Daten verloren gehen, wenn der Prozess gewaltsam beendet wird. Im Idealfall sollten Sie einen lang andauernden Task umgestalten und die Verarbeitung in kleinere, einzelne Segmente aufteilen. Das Muster Rohre und Filter bietet ein Beispiel dafür, wie Sie diese Lösung erreichen können.

Alternativ können Sie einen Prüfpunktmechanismus implementieren, der in regelmäßigen Abständen Zustandsinformationen zur Aufgabe aufzeichnet. Anschließend können Sie diesen Zustand im dauerhaften Speicher speichern, auf den jeder instance des Prozesses zugreifen kann, auf den die Aufgabe ausgeführt wird. Auf diese Weise kann beim Herunterfahren des Prozesses die Arbeit, die er ausgeführt hat, vom letzten Prüfpunkt aus von einem anderen instance fortgesetzt werden. Manche Bibliotheken, wie z. B. NServiceBus und MassTransit, stellen diese Funktionalität bereit. Sie behalten den Zustand transparent bei, in dem die Intervalle auf die Verarbeitung von Nachrichten aus Warteschlangen in Azure Service Bus ausgerichtet sind.

Wenn Hintergrundaufgaben auf separaten Computeinstanzen ausgeführt werden, z. B. in Workerrollen einer von Clouddiensten gehosteten Anwendung, müssen Sie möglicherweise verschiedene Teile der Anwendung mithilfe unterschiedlicher Skalierungsrichtlinien skalieren. Beispielsweise müssen Sie möglicherweise zusätzliche Computeinstanzen der Benutzeroberfläche (Ui) bereitstellen, ohne die Anzahl von Compute-Hintergrundinstanzen zu erhöhen oder umgekehrt. Wenn Sie verschiedene Dienstebenen anbieten, z. B. Standard- und Premium-Dienstpakete, müssen Sie möglicherweise die Computeressourcen für Premium-Dienstpakete aggressiver hochskalieren als für Basisdienstpakete, um Vereinbarungen zum Servicelevel (SLAs) zu erfüllen.

Sie können beispielsweise die Länge der Warteschlange berücksichtigen, über die die Benutzeroberfläche und Compute-Instanzen im Hintergrund kommunizieren. Verwenden Sie sie als Kriterium für Ihre Strategie zur automatischen Skalierung. Dieses Problem ist ein möglicher Indikator für ein Ungleichgewicht oder einen Unterschied zwischen der aktuellen Auslastung und der Verarbeitungskapazität der Hintergrundaufgabe. Ein etwas komplexeres, aber besseres Attribut, auf dem Skalierungsentscheidungen basieren, ist die Verwendung der Zeit zwischen dem Senden einer Nachricht und dem Abschluss der Verarbeitung. Dieses Intervall wird als kritische Zeit bezeichnet. Wenn dieser kritische Zeitwert unter einem aussagekräftigen Geschäftsschwellenwert liegt, ist eine Skalierung nicht erforderlich, auch wenn die Warteschlangenlänge lang ist.

Beispielsweise könnten 50.000 Nachrichten in einer Warteschlange vorhanden sein. Die kritische Zeit der ältesten Nachricht beträgt jedoch 500 ms, und der Endpunkt befasst sich mit der Integration mit einem Webdienst eines Drittanbieters zum Senden von E-Mails. Geschäftsbeteiligte würden dies wahrscheinlich als einen Zeitraum betrachten, der es nicht rechtfertigen würde, zusätzliches Geld für die Skalierung auszugeben.

Auf der anderen Seite kann es 500 Nachrichten in einer Warteschlange mit der gleichen kritischen Zeit von 500 ms geben, aber der Endpunkt ist Teil des kritischen Pfads in einem Echtzeit-Onlinespiel, in dem Geschäftsbeteiligte eine Antwortzeit von 100 ms oder weniger definiert haben. In diesem Fall würde eine horizontale Skalierung sinnvoll sein.

Um die kritische Zeit bei Entscheidungen zur automatischen Skalierung zu nutzen, ist es hilfreich, dass eine Bibliothek die relevanten Informationen automatisch den Headern von Nachrichten hinzufügt, während sie gesendet und verarbeitet werden. Eine Bibliothek, die diese Funktionalität bereitstellt, ist NServiceBus.

Wenn Sie Ihre Strategie zur automatischen Skalierung auf Leistungsindikatoren basieren, die Geschäftsprozesse messen, z. B. die Anzahl der bestellungen pro Stunde oder die durchschnittliche Laufzeit einer komplexen Transaktion, stellen Sie sicher, dass Sie die Beziehung zwischen den Ergebnissen dieser Arten von Indikatoren und den tatsächlichen Anforderungen an die Computekapazität vollständig verstehen. Es kann erforderlich sein, mehr als eine Komponente oder Computeeinheit als Reaktion auf Änderungen an Geschäftsprozessindikatoren zu skalieren.

Um zu verhindern, dass ein System versucht, übermäßig hochskaliert zu werden, und um die Kosten zu vermeiden, die mit der Ausführung von vielen Tausenden von Instanzen verbunden sind, sollten Sie die maximale Anzahl von Instanzen begrenzen, die automatisch hinzugefügt werden. Mit den meisten Mechanismen zur automatischen Skalierung können Sie die minimale und maximale Anzahl von Instanzen für eine Regel angeben. Darüber hinaus sollten Sie erwägen, die Funktionalität, die das System bereitstellt, ordnungsgemäß zu beeinträchtigen, wenn die maximale Anzahl von Instanzen bereitgestellt wurde und das System weiterhin überlastet ist.

Beachten Sie, dass die automatische Skalierung möglicherweise nicht der am besten geeignete Mechanismus ist, um einen plötzlichen Burst in einer Workload zu behandeln. Das Bereitstellen und Starten neuer Instanzen eines Diensts oder das Hinzufügen von Ressourcen zu einem System dauert einige Zeit. Die Spitzennachfrage kann bis zur Verfügbarkeit dieser zusätzlichen Ressourcen vergehen. In diesem Szenario ist es möglicherweise besser, den Dienst zu drosseln. Weitere Informationen finden Sie unter Muster „Drosselung“.

Wenn Sie hingegen die Kapazität benötigen, um alle Anforderungen zu verarbeiten, wenn das Volumen schnell schwankt und die Kosten kein wichtiger Faktor sind, sollten Sie eine aggressive automatische Skalierungsstrategie in Erwägung ziehen, die mehr Instanzen schneller startet. Sie können auch eine geplante Richtlinie verwenden, die eine ausreichende Anzahl von Instanzen für die maximale Auslastung startet, bevor diese Auslastung erwartet wird.

Der Mechanismus für die automatische Skalierung sollte den Prozess der automatischen Skalierung überwachen und die Details jedes automatischen Skalierungsereignisses protokollieren (was es ausgelöst hat, welche Ressourcen hinzugefügt oder entfernt wurden und wann). Wenn Sie einen benutzerdefinierten Mechanismus für die automatische Skalierung erstellen, stellen Sie sicher, dass diese Funktion enthalten ist. Überprüfen Sie die Informationen, um die Effektivität der Strategie für die automatische Skalierung zu ermitteln, und optimieren Sie die Strategie gegebenenfalls. Sie können die Strategie sowohl kurzfristig (wenn die Nutzungsmuster offensichtlicher werden) als auch langfristig optimieren (bei Geschäftserweiterung oder sich ändernden Anforderungen der Anwendung). Wenn eine Anwendung die für die automatische Skalierung definierte Obergrenze erreicht, kann der Mechanismus auch einen Operator benachrichtigen, der bei Bedarf weitere Ressourcen manuell starten kann. Unter diesen Umständen ist der Operator möglicherweise auch dafür verantwortlich, diese Ressourcen manuell zu entfernen, nachdem die Workload gelockert wurde.

Beispiel

Weitere Informationen finden Sie im Leitfaden zur Skalierung der AKS-Referenzarchitektur.

Prüfliste für zuverlässigkeit

Weitere Informationen finden Sie im vollständigen Satz von Empfehlungen.

Prüfliste für zuverlässigkeit