Dimensionierung und automatische Skalierung

Die passende Dimensionierung bezeichnet den Prozess, die Azure-VMs oder Service-SKUs an den tatsächlichen Ressourcenbedarf Ihrer Workload anzupassen – ohne Überdimensionierung (Geldverschwendung) und ohne Unterdimensionierung (Gefahr einer verschlechterten Leistung). Die meisten Organisationen dimensionieren anfangs aus Vorsicht um 30–50 % zu groß, wenn sie von lokalen Systemen migrieren. Eine regelmäßige Analyse zur passenden Dimensionierung, typischerweise einmal im Monat, kann einen erheblichen Teil dieser Mehrausgaben zurückgewinnen, ohne die Anwendungsleistung zu beeinträchtigen.

Verwenden Sie Azure-Monitor-Metriken und VM Insights, um über mindestens 30 Tage Daten zu CPU, Arbeitsspeicher, Datenträger-IOPS und Netzwerkdurchsatz zu sammeln. Achten Sie auf die Spitzenauslastung (P95 oder P99) und nicht auf den Durchschnitt, damit die passend dimensionierte VM Lastspitzen bewältigen kann. Die Empfehlung zur passenden Dimensionierung von Azure Advisor verwendet standardmäßig einen Rückblick von 7 Tagen. In der Advisor-Konfiguration können Sie diesen Zeitraum jedoch auf 30 oder 60 Tage verlängern, um repräsentativere Daten zu erhalten.

Azure-VMs sind in SKU-Familien organisiert, die für unterschiedliche Workloads optimiert sind: D-series (universell einsetzbar), E-series (für Arbeitsspeicher optimiert), F-series (für Compute optimiert), N-series (GPU) und L-series (für Speicher optimiert). Wenn die CPU-Auslastung einer VM niedrig, die Speicherauslastung aber hoch ist, bietet der Wechsel von einer D-series zu einer E-series bei gleicher vCPU-Anzahl mehr RAM zu ähnlichen Kosten. Die Größenänderung einer VM in Azure erfordert in der Regel einen kurzen Neustart von wenigen Minuten.

Die geplante automatische Skalierung ist die richtige Wahl, wenn Workload-Muster vorhersehbar sind. Eine Einzelhandelsanwendung mit hohem Datenverkehr während der Geschäftszeiten und nahezu null Datenverkehr über Nacht kann für eine Scale-out-Planung um 07:00 Uhr und eine Scale-in-Planung um 22:00 Uhr konfiguriert werden. Virtual Machine Scale Sets (VMSS) und App Service unterstützen beide geplante Autoscale-Regeln. Bei bekannten Lastmustern ist dieser Ansatz einfacher und die Kosten sind besser vorhersehbar als bei einer metrიკისbasierten automatischen Skalierung.

Die metrikbasierte automatische Skalierung fügt als Reaktion auf Echtzeitmetriken wie CPU-Prozent, die Länge der HTTP-Anforderungswarteschlange oder über Azure Monitor veröffentlichte benutzerdefinierte Metriken dynamisch Instanzen hinzu oder entfernt sie. Sie definieren Scale-out-Regeln (wann Instanzen hinzugefügt werden) und Scale-in-Regeln (wann Instanzen entfernt werden) mit Abkühlzeiten, um ein schnelles Hin- und Herwechseln zu verhindern. Als bewährte Vorgehensweise sollte der Schwellenwert für Scale-out niedriger sein als der Schwellenwert für Scale-in – beispielsweise Scale-out bei mehr als 70 % CPU und Scale-in bei weniger als 30 % CPU – mit einer Abkühlzeit von 5 Minuten.

Azure Spot VMs ermöglichen Ihnen, nicht genutzte Azure-Kapazität mit Rabatten von bis zu 90 % gegenüber den Pay-as-you-go-Preisen zu verwenden. Der Nachteil besteht darin, dass Azure Spot-VMs mit einer Vorankündigung von 30 Sekunden entziehen kann, wenn die Kapazität wieder benötigt wird. Dadurch eignen sich Spot-Instanzen ideal für unterbrechbare Batch-Workloads wie Rendering, wissenschaftliche Berechnungen und Datenverarbeitungspipelines. VMSS unterstützt mithilfe einer Prioritätsmischungsrichtlinie die Kombination von regulären VMs (für eine Basiskapazität) und Spot-VMs (für zusätzliche Kapazität) in derselben Skalierungsgruppe.

Die Autoskalierung von Azure App Service erfolgt auf Ebene des App Service Plan: Workerinstanzen werden auf Grundlage von Regeln hinzugefügt oder entfernt, die Sie konfigurieren. Zu den verfügbaren Metrikauslösern gehören die Länge der HTTP-Warteschlange sowie die CPU- und Speicherauslastung in Prozent. Ab der Ebene Standard werden manuelle Skalierung und Autoskalierung unterstützt; die Ebene Basic unterstützt nur die manuelle Skalierung. Für serverlose Workloads empfiehlt sich Azure Functions im Consumption Plan, das bis auf null skaliert und nur pro Ausführung abgerechnet wird, wodurch Kosten für ungenutzte Instanzen vollständig entfallen.

Häufige Fallstricke bei der Autoskalierung: Sitzungsaffinität – wenn Ihre Anwendung den Sitzungsstatus im VM-Speicher ablegt, gehen beim Herunterskalieren Sitzungen verloren; verwenden Sie stattdessen Redis Cache oder datenbankgestützte Sitzungen. Lange Startzeiten – wenn VMs oder Container 10 Minuten zum Aufwärmen benötigen, kann die metrikbasierte Autoskalierung nicht schnell genug reagieren; wärmen Sie die Umgebung vor erwarteten Spitzen durch geplantes Aufskalieren vorab auf. Zu aggressives Herunterskalieren – das Beenden von Instanzen während der Verarbeitung laufender Anfragen verursacht Fehler; konfigurieren Sie eine Verbindungsentleerung und eine großzügig bemessene Abkühlzeit.

Die richtige Dimensionierung gilt auch für PaaS-Dienste. Azure SQL Database im DTU-Modell kann herunterskaliert werden, wenn der DTU-Prozentsatz dauerhaft unter 50 % liegt. Das vCore-Modell ermöglicht die unabhängige Skalierung von CPU und Speicher. Azure Cache for Redis kann von der Ebene Premium auf Standard herunterskaliert werden, wenn Persistenz und Georeplikation nicht benötigt werden. Knotenpools von Azure Kubernetes Service können den Cluster Autoscaler verwenden, um die Anzahl der Knoten abhängig vom ausstehenden oder inaktiven Zustand von Pods zu erhöhen oder zu verringern.

Die richtige Dimensionierung ist keine einmalige Maßnahme. Workloads verändern sich im Laufe der Zeit – Verkehrsmuster ändern sich, Funktionen kommen hinzu und Benutzergruppen wachsen oder schrumpfen. Verankern Sie eine monatliche Überprüfung der Dimensionierung in Ihrem FinOps-Prozess: Rufen Sie Advisor-Empfehlungen ab, überprüfen Sie die 10 am stärksten unterausgelasteten VMs und überdimensionierten PaaS-Dienste und erstellen Sie Arbeitsaufträge für die zuständigen Teams. Erfassen Sie die realisierten Einsparungen im Verhältnis zu den erstellten Empfehlungen, um den FinOps-ROI gegenüber der Führungsebene nachzuweisen.

Die optimale Kostenstrategie lautet: zuerst richtig dimensionieren, dann reservieren. Wenn Sie eine Reserved VM Instance für eine überdimensionierte VM erwerben, gehen Sie eine Bindung an die falsche SKU ein. Dimensionieren Sie die VM zunächst auf die passende Größe, beobachten Sie anschließend 30 Tage lang die neue Auslastung, um ihre Stabilität zu bestätigen, und erwerben Sie dann eine Reservierung für diese passend dimensionierte SKU. Dieser zweistufige Ansatz maximiert den Rabatt und vermeidet zugleich ungenutzte reservierte Kapazität.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900) in dieser Lektion.

In dieser Lektion haben Sie gelernt: Die richtige Dimensionierung ordnet VM-SKUs mithilfe von Leistungsmetriken den tatsächlichen Anforderungen des Workloads zu, geplante und metrikbasierte Autoskalierung passen die Kapazität dynamisch an den Bedarf an, und Spot-VMs bieten Rabatte von bis zu 90 % für unterbrechbare Batch-Workloads. Als Nächstes untersuchen wir Azure Savings Plans und Reservations für Workloads mit Bindung.