Freigeben über

Empfehlungen für das Entwerfen einer zuverlässigen Skalierungsstrategie

  • Artikel

Gilt für diese Empfehlung für die Zuverlässigkeitsprüfliste des Azure Well-Architected Framework:

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

Verwandtes Handbuch: Datenpartitionierung

In diesem Leitfaden werden die Empfehlungen für das Entwerfen einer zuverlässigen Skalierungsstrategie beschrieben.

Definitionen

Begriff Definition
Vertikale Skalierung Ein Skalierungsansatz, der vorhandenen Ressourcen Rechenkapazitä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, um normale Lademuster zu berücksichtigen), 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 aus). Sowohl die vertikale als auch die horizontale Skalierung können über jede dieser Methoden ausgeführt werden. Die automatische vertikale Skalierung erfordert jedoch eine zusätzliche benutzerdefinierte Automatisierungsentwicklung und kann abhängig von den skalierten Ressourcen zu Ausfallzeiten führen.

Wichtige Entwurfsstrategien

Entwerfen nach Lademustern

Um eine zuverlässige Skalierungsstrategie für Ihre Workloads zu entwerfen, konzentrieren Sie sich auf die Identifizierung von Lademustern für die Benutzer- und Systemflüsse für jede Workload, die zu einem Skalierungsvorgang führt. Hier sind Beispiele für die verschiedenen Lademuster:

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

  • Dynamisch, normal und vorhersagbar: Jeden Montagmorgen melden sich 1000 Mitarbeiter in mehreren Regionen beim ERP-System an.

  • Dynamisch, unregelmäßig und vorhersehbar: Ein Produktstart erfolgt am ersten Tag des Monats und es gibt historische Daten aus früheren Starts darüber, wie der Datenverkehr in diesen Situationen steigt.

  • Dynamisch, unregelmäßig und unvorhersehbar: Ein großes Ereignis verursacht eine Spitzennachfrage nach einem Produkt. Beispielsweise können Unternehmen, die Entfeuchter produzieren und verkaufen, einen plötzlichen Verkehrsanstieg nach einem Hurrikan oder einem anderen Überschwemmungsereignis erleben, wenn Menschen in betroffenen Gebieten Räume in ihrem Zuhause trocknen müssen.

Nachdem Sie diese Arten von Lademustern identifiziert haben, können Sie:

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

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

Für die vorherigen Beispiele können Ihre Skalierungsstrategien folgendes sein:

  • Statisch: Sie haben eine geplante Skalierung Ihrer Computeknoten auf die Mindestanzahl (2) zwischen 11:00 und 6:00 Uhr EST.

  • Dynamisch, normal 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 eine einmalige geplante Skalierung Ihrer Compute- und Datenbankinstanzen am Morgen eines Produktstarts, und Sie skalieren nach einer Woche zurück.

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

Automatisieren von Skalierungsstrategien

Achten Sie beim Entwerfen der Skalierungsautomatisierung darauf, diese Probleme zu berücksichtigen:

  • Alle Komponenten Ihrer Workload sollten kandidaten für die Skalierungsimplementierung sein. In den meisten Fällen skalieren globale Dienste wie Microsoft Entra ID automatisch und transparent für Sie und Ihre Kunden. Achten Sie darauf, die Skalierungsfunktionen Ihrer Netzwerkausgangs- und Ausgangscontroller und Ihre Lastenausgleichslösung zu verstehen.

  • Diese Komponenten, die nicht skaliert werden können. Ein Beispiel wäre große relationale Datenbanken, die keine Sharding aktiviert haben und ohne erhebliche Auswirkungen nicht umgestaltet werden können. Dokumentieren Sie die von Ihrem Cloudanbieter veröffentlichten Ressourcenlimits, und überwachen Sie diese Ressourcen genau. Fügen 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, sodass Sie den Vorgang ordnungsgemäß planen, bevor die zusätzliche Last auf Ihre Infrastruktur trifft. Wenn beispielsweise eine Komponente wie api Management 45 Minuten zum Skalieren benötigt, kann das Anpassen des Skalierungsschwellenwerts auf 65 % anstelle von 90 % Ihnen helfen, früher zu skalieren und sich auf die erwartete Erhöhung der Last vorzubereiten.

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

  • Alle zustandsbehafteten Anwendungselemente, die durch einen Skalierungsvorgang und jede implementierte Sitzungsaffinität (oder Sitzungsverknüppelung) unterbrochen werden können. Klebigkeit kann Ihre Skalierungsfähigkeit einschränken und einzelne Fehlerpunkte einführen.

  • Potenzielle Engpässe. Durch das Skalieren wird nicht jedes Leistungsproblem behoben. Wenn Ihre Back-End-Datenbank beispielsweise der Engpass ist, hilft es nicht, weitere Webserver hinzuzufügen. Identifizieren und beheben Sie zuerst die Engpässe im System, bevor Sie nur weitere Instanzen hinzufügen. Zustandsbehaftete Teile des Systems sind die wahrscheinlichste Ursache von Engpässen.

Wenn Sie das Entwurfsmuster für bereitstellungsstempel verwenden, hilft Sie bei der allgemeinen Infrastrukturverwaltung. Die Grundlage Ihres Skalierungsdesigns auf Stempeln als Skalierungseinheiten ist ebenfalls von Vorteil. Außerdem können Sie Ihre Skalierungsvorgänge eng über mehrere Workloads und Teilmengen von Workloads hinweg steuern. Anstatt die Skalierungszeitpläne und die automatischen Skalierungsschwellenwerte vieler unterschiedlicher Ressourcen zu verwalten, können Sie einen begrenzten Satz von Skalierungsdefinitionen auf einen Bereitstellungsstempel anwenden und diese dann bei Bedarf spiegeln.

Kompromiss: Die Skalierung nach oben hat Kostenauswirkungen. Optimieren Sie ihre Strategie also so schnell wie möglich, um Kosten unter Kontrolle zu halten. Stellen Sie sicher, dass die Automatisierung, die Sie zum Skalieren nach oben verwenden, auch Trigger zum Herunterskalieren hat.

Azure-Erleichterung

Eine automatische Skalierungsfunktion ist in vielen Azure-Diensten verfügbar. Dadurch können Sie bedingungen ganz einfach konfigurieren, um Instanzen automatisch horizontal zu skalieren. Einige Dienste verfügen über eingeschränkte oder keine integrierte Funktionalität, die automatisch skaliert werden kann. Dokumentieren Sie daher diese Fälle, und definieren Sie Prozesse für die Skalierung.

Viele Azure-Dienste bieten APIs, mit denen Sie benutzerdefinierte automatische Skalierungsvorgänge mithilfe von Azure Automation entwerfen können, z. B. die Codebeispiele bei Autoscale 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.

Azure Monitor autoscale bietet eine allgemeine Reihe von automatischen Skalierungsfunktionen für Azure Virtual Machine Scale Sets, Azure-App Service, Azure Spring Apps und vieles mehr. Die Skalierung kann für einen Zeitplan oder basierend auf einer Laufzeitmetrik ausgeführt werden, z. B. CPU- oder Arbeitsspeicherauslastung. Im Azure Monitor-Handbuch finden Sie bewährte Methoden.

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 zur Instanzaffinität. Entwerfen Sie keine Lösungen, die erfordern, dass der Code immer in einer bestimmten Instanz eines Prozesses ausgeführt wird. Gehen Sie beim horizontalen Skalieren eines Clouddiensts oder einer Website nicht davon aus, dass eine Reihe von Anforderungen aus derselben Quelle immer an dieselbe Instanz weitergeleitet werden. 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. Die automatische Skalierung könnte mehr Instanzen eines Diensts starten, da die Warteschlangenlänge wächst. 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 sorgfalt könnte eine solche Aufgabe verhindern, dass eine Instanz eines Prozesses sauber heruntergefahren wird, wenn das System skaliert wird. Oder es können Daten verloren gehen, wenn der Prozess forcibly 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, mit dem Statusinformationen zum Vorgang in regelmäßigen Abständen aufgezeichnet werden. Sie können diesen Zustand dann im dauerhaften Speicher speichern, auf den von jeder Instanz des Prozesses zugegriffen werden kann, der die Aufgabe ausführt. Wenn der Prozess heruntergefahren wird, kann die ausgeführte Arbeit vom letzten Prüfpunkt von einer anderen Instanz fortgesetzt werden. Manche Bibliotheken, wie z. B. NServiceBus und MassTransit, stellen diese Funktionalität bereit. Sie speichern transparent den Zustand, in dem die Intervalle an der Verarbeitung von Nachrichten aus Warteschlangen in Azure Service Bus ausgerichtet sind.

Wenn Hintergrundaufgaben auf separaten Computeinstanzen ausgeführt werden, z. B. in Arbeitsrollen einer von Clouddiensten gehosteten Anwendung, müssen Sie möglicherweise verschiedene Teile der Anwendung mithilfe unterschiedlicher Skalierungsrichtlinien skalieren. Sie müssen z. B. zusätzliche Benutzeroberflächenberechnungsinstanzen bereitstellen, ohne die Anzahl der Computeinstanzen im Hintergrund zu erhöhen oder umgekehrt. Wenn Sie verschiedene Serviceebenen anbieten, z. B. Standard- und Premium-Servicepakete, müssen Sie möglicherweise die Computeressourcen für Premium-Servicepakete aggressiver skalieren als für grundlegende Servicepakete, um Vereinbarungen auf Serviceebene (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 eine Differenz zwischen der aktuellen Last und der Verarbeitungskapazität der Hintergrundaufgabe. Ein etwas komplexeres, aber besseres Attribut, auf dem Die Skalierungsentscheidungen basieren, besteht darin, die Zeit zwischen dem Zeitpunkt des Sendens einer Nachricht und dem Abschluss der Verarbeitung zu verwenden. Dieses Intervall wird als kritische Zeit bezeichnet. Wenn dieser kritische Zeitwert unter einem aussagekräftigen Geschäftsschwellenwert liegt, ist die Skalierung unnötig, auch wenn die Warteschlangenlänge lang ist.

So könnten beispielsweise 50.000 Nachrichten in einer Warteschlange vorhanden sein. Die kritische Zeit der ältesten Nachricht beträgt jedoch 500 ms, und der Endpunkt beschäftigt sich mit der Integration mit einem Webdienst eines Drittanbieters zum Senden von E-Mails. Die Geschäftsbeteiligten würden wahrscheinlich berücksichtigen, dass es sich um einen Zeitraum, der die Ausgaben für die Skalierung nicht rechtfertigen würde.

Andererseits könnte es 500 Nachrichten in einer Warteschlange mit derselben 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 kritische Zeit bei entscheidungen zur automatischen Skalierung zu verwenden, ist es hilfreich, dass eine Bibliothek automatisch die relevanten Informationen zu den Kopfzeilen von Nachrichten hinzufügt, während sie gesendet und verarbeitet werden. Eine Bibliothek, die diese Funktionalität bereitstellt, ist NServiceBus.

Wenn Sie Ihre automatische Skalierungsstrategie 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 Leistungsindikatoren und den tatsächlichen Anforderungen an die Berechnungskapazität vollständig verstehen. Es kann erforderlich sein, mehr als eine Komponente oder Computeeinheit als Reaktion auf Änderungen an Geschäftsprozesszählern zu skalieren.

Um zu verhindern, dass ein System übermäßig skaliert werden soll, 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 einschränken, die automatisch hinzugefügt werden. Bei 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 die Funktionalität, die das System bereitstellt, ordnungsgemäß beeinträchtigen, wenn die maximale Anzahl von Instanzen bereitgestellt wurde und das System weiterhin überladen ist.

Denken Sie daran, dass die automatische Skalierung möglicherweise nicht der am besten geeignete Mechanismus ist, um einen plötzlichen Platz in einer Workload zu behandeln. Es dauert Zeit, um neue Instanzen eines Diensts bereitzustellen und zu starten oder Ressourcen zu einem System hinzuzufügen, und die Spitzennachfrage kann bis zum Zeitpunkt der Verfügbarkeit dieser zusätzlichen Ressourcen übergeben werden. 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, alle Anforderungen zu verarbeiten, wenn das Volumen schnell schwankt und die Kosten kein wichtiger Faktor sind, sollten Sie eine aggressive Autokalierungsstrategie verwenden, 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 Automatische Skalierungsmechanismus sollte den automatischen Skalierungsprozess überwachen und die Details der einzelnen automatischen Ereignisse protokollieren (was ausgelöst wurde, 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 manuell weitere Ressourcen starten kann. Unter diesen Umständen kann der Betreiber auch dafür verantwortlich sein, diese Ressourcen manuell zu entfernen, nachdem die Arbeitsauslastung erleichtert wurde.

Beispiel

Weitere Informationen finden Sie in den AKS-Referenzarchitekturskalierungsanleitungen.

Zuverlässigkeitsprüfliste

Lesen Sie den vollständigen Satz von Empfehlungen.

Zuverlässigkeitsprüfliste