Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Verwenden Sie historische Muster, um Amazon ECS-Services mit vorausschauender Skalierung zu skalieren Die prädiktive Skalierung betrachtet vergangene Lastdaten aus Datenverkehrsströmen, um tägliche oder wöchentliche Muster zu analysieren. Anschließend verwendet sie diese Analyse, um zukünftige Bedürfnisse vorherzusehen und die Aufgaben in Ihrem Service nach Bedarf proaktiv zu erhöhen. Prädiktives Auto Scaling ist in den folgenden Situationen am nützlichsten: + Zyklischer Datenverkehr – Erhöhte Auslastung von Ressourcen während der normalen Geschäftszeiten und niedrige Auslastung von Ressourcen am Abend und am Wochenende + Wiederkehrende on-and-off Workload-Muster — Beispiele hierfür sind Batch-Verarbeitung, Tests oder regelmäßige Datenanalysen. + Anwendungen mit langen Startzeiten – Dies kann eine spürbare Latenzauswirkung auf die Anwendungsleistung bei Aufskalierungsereignissen haben. Sie sollten die prädiktive Skalierung in Betracht ziehen, wenn Sie regelmäßige Datenverkehrszuwächse haben und Anwendungen nutzen, deren Initialisierung lange dauert. Die prädiktive Skalierung hilft Ihnen, schneller zu skalieren, indem sie proaktiv die Anzahl der Aufgaben für prognostizierte Lasten erhöht, anstatt ausschließlich dynamische Skalierungsrichtlinien wie die Ziel-Nachverfolgung oder die schrittweise Skalierung zu verwenden. Durch prädiktive Skalierung können Sie die Möglichkeit einer Überbereitstellung der Anzahl an Aufgaben vermeiden, und Sie können möglicherweise auch Geld sparen. Nehmen wir als Beispiel eine Anwendung, die eine hohe Auslastung während der Geschäftszeiten und eine geringe Nutzung über Nacht aufweist. Zu Beginn eines jeden Werktages kann die prädiktive Skalierung vor dem ersten Zustrom des Datenverkehrs die Aufgaben aufskalieren. Auf diese Weise kann Ihre Anwendung eine hohe Verfügbarkeit und Leistung aufrechterhalten, wenn sie von einer geringeren Auslastung zu einem Zeitraum mit höherer Auslastung übergeht. Sie müssen nicht warten, bis die dynamische Skalierung auf sich ändernden Datenverkehr reagiert. Sie müssen auch keine Zeit damit verbringen, die Lastmuster Ihrer Anwendung zu überprüfen und mithilfe der geplanten Skalierung die richtige Kapazität zu planen. Prädiktive Skalierung ist eine Funktion auf Service-Ebene, die die Aufgabe Ihres Services unabhängig von der Skalierung der zugrunde liegenden Rechenkapazität (z. B. EC2 oder Fargate) skaliert. AWS Verwaltet und skaliert für Fargate die zugrunde liegende Kapazität automatisch auf der Grundlage der Aufgabenanforderungen. Für EC2-Kapazität können Sie Auto-Scaling-Gruppenkapazitätsanbieter verwenden, um die zugrunde liegenden EC2-Instances automatisch auf der Grundlage der Skalierungsanforderungen Ihrer Aufgaben zu skalieren. **Topics** + [Überblick über die prädiktive Skalierung](#predictive-auto-scaling-overview) + [Eine Richtlinie für die prädiktive Skalierung erstellen](predictive-scaling-create-policy.md) + [Auswertung Ihrer Richtlinien für prädiktive Skalierung](predictive-scaling-graphs.md) + [Prognose überschreiben](predictive-scaling-overriding-forecast-capacity.md) + [Verwenden benutzerdefinierter Metriken](predictive-scaling-custom-metrics.md) ## So funktioniert die prädiktive Skalierung in Amazon ECS Hier erfahren Sie mehr über Überlegungen zur Verwendung der prädiktiven Skalierung, wie sie funktioniert und wo die Grenzen liegen. ### Überlegungen zur Verwendung der prädiktiven Skalierung + Sie sollten sicherstellen, dass die prädiktive Skalierung für Ihren Workload geeignet ist. Sie können dies überprüfen, indem Sie Skalierungsrichtlinien im Modus **Nur Prognosen** konfigurieren und herausfinden, was die Konsole empfiehlt. Bevor Sie mit der prädiktiven Skalierung beginnen, sollten Sie die Prognose und die Empfehlungen auswerten. + Bevor die prädiktive Skalierung Prognosen erstellen kann, werden mindestens 24 Stunden an historischen Daten benötigt. Je mehr historische Daten verfügbar sind, desto effektiver ist die Prognose, wobei zwei Wochen ideal sind. Außerdem müssen Sie 24 Stunden warten, bis die prädiktive Skalierung neue Prognosen generieren kann, wenn Sie einen Amazon-ECS-Service löschen und einen neuen erstellen. Eine Möglichkeit, dies zu beschleunigen, besteht darin, benutzerdefinierte Metriken zu verwenden, um Metriken über den alten und neuen Amazon-ECS-Service hinweg zu aggregieren. + Wählen Sie eine Lastmetrik, die die volle Auslastung Ihrer Anwendung genau wiedergibt und den Aspekt Ihrer Anwendung darstellt, der für die Skalierung am wichtigsten ist. + Dynamische Skalierung mit prädiktiver Skalierung hilft Ihnen, die Nachfrage nach Ihrer Anwendung genau zu verfolgen, sodass Sie in Ruhephasen skalieren und bei unerwartetem Anstieg des Datenverkehrs aufskalieren können. Wenn mehrere Skalierungsrichtlinien aktiv sind, bestimmt jede Richtlinie die gewünschte Anzahl an Aufgaben unabhängig, und die gewünschte Anzahl an Aufgaben wird auf das Maximum dieser Richtlinien festgelegt. + Sie können prädiktive Skalierung zusammen mit Ihren dynamischen Skalierungsrichtlinien wie Ziel-Nachverfolgung oder schrittweise Skalierung verwenden, sodass Ihre Anwendungen sowohl auf Echtzeit- als auch auf historischen Mustern skaliert werden. Prädiktive Skalierung allein skaliert Ihre Aufgaben nicht ab. + Wenn Sie beim Aufrufen der `register-scalable-target`-API eine benutzerdefinierte Rolle verwenden, wird möglicherweise eine Fehlermeldung angezeigt, die besagt, dass die Richtlinie zur prädiktiven Skalierung nur funktionieren kann, wenn SLR aktiviert ist. In diesem Fall sollten Sie `register-scalable-target` erneut aufrufen, jedoch ohne role-arn. Verwenden Sie SLR, wenn Sie das skalierbare Ziel registrieren und die `put-scaling-policy`-API aufrufen. ### So funktioniert Auto Scaling Sie verwenden Predictive Scaling, indem Sie eine Predictive Scaling-Richtlinie erstellen, die die zu überwachende und zu analysierende CloudWatch Metrik festlegt. Die prädiktive Skalierung muss mindestens 24 Stunden an Daten enthalten, um mit der Prognose von zukünftigen Werten zu beginnen. Nachdem Sie die Richtlinie erstellt haben, beginnt die prädiktive Skalierung mit der Analyse von Metrikdaten der letzten 14 Tage, um Muster zu identifizieren. Diese Analyse wird verwendet, um stündliche Prognosen für die Anforderungen der nächsten 48 Stunden zu generieren. Die neuesten CloudWatch Daten werden verwendet, um die Prognose alle sechs Stunden zu aktualisieren. Wenn neue Daten eintreffen, verbessert die prädiktive Skalierung kontinuierlich die Genauigkeit zukünftiger Prognosen. Wenn Sie die prädiktive Skalierung zum ersten Mal aktivieren, wird sie im Modus *nur Prognose* ausgeführt. In diesem Modus werden Prognosen generiert, Ihr Amazon-ECS-Service wird jedoch nicht auf der Grundlage dieser Prognosen skaliert. Das bedeutet, dass Sie die Genauigkeit und Eignung der Prognose bewerten können. Sie können Prognosedaten mithilfe des `GetPredictiveScalingForecast`-API-Vorgangs oder der AWS-Managementkonsole anzeigen. Wenn Sie sich entscheiden, prädiktive Skalierung zu verwenden, schalten Sie die Skalierungsrichtlinie in den Modus *Prognose und Skalierung* um. In diesem Modus passiert Folgendes. Ihr Amazon-ECS-Service wird standardmäßig zu Beginn jeder Stunde auf der Grundlage der Prognose für diese Stunde skaliert. Sie können wählen, ob Sie früher beginnen möchten, indem Sie die `SchedulingBufferTime`-Eigenschaft im `PutScalingPolicy`-API-Vorgang verwenden. Dadurch werden neue Aufgaben vor dem prognostizierten Bedarf gestartet und sie haben Zeit, den Vorgang zu starten und für den Datenverkehr bereit zu sein. ### Maximale Grenze für Aufgaben Wenn Sie Amazon-ECS-Services für die Skalierung registrieren, definieren Sie eine maximale Anzahl von Aufgaben, die pro Service gestartet werden können. Wenn Skalierungsrichtlinien festgelegt sind, können sie die Anzahl der Aufgaben standardmäßig nicht über die Höchstgrenze bringen. Alternativ können Sie zulassen, dass die maximale Anzahl von Aufgaben des Service automatisch erhöht wird, wenn sich die Prognose der maximalen Anzahl von Aufgaben des Amazon-ECS-Service nähert oder diese überschreitet. **Warnung** Seien Sie vorsichtig, wenn Sie zulassen, dass die maximale Anzahl von Aufgaben automatisch erhöht wird. Dies kann dazu führen, dass mehr Aufgaben als vorgesehen gestartet werden, wenn die erhöhte maximale Anzahl von Aufgaben nicht überwacht und verwaltet wird. Die erhöhte maximale Anzahl von Aufgaben wird dann zur neuen normalen Höchstanzahl von Aufgaben für den Amazon-ECS-Service, bis Sie sie manuell aktualisieren. Die maximale Anzahl von Aufgaben wird nicht automatisch auf das ursprüngliche Maximum zurückgesetzt. ### Unterstützte -Regionen + USA Ost (Nord-Virginia) + USA Ost (Ohio) + USA West (Nordkalifornien) + USA West (Oregon) + Africa (Cape Town) + Asia Pacific (Hongkong) + Asien-Pazifik (Jakarta) + Asien-Pazifik (Mumbai) + Asien-Pazifik (Osaka) + Asien-Pazifik (Seoul) + Asien-Pazifik (Singapur) + Asien-Pazifik (Sydney) + Asien-Pazifik (Tokio) + Canada (Central) + China (Peking) + China (Ningxia) + Europe (Frankfurt) + Europa (Irland) + Europa (London) + Europa (Milan) + Europe (Paris) + Europe (Stockholm) + Middle East (Bahrain) + Südamerika (São Paulo) + AWS GovCloud (US-Ost) + AWS GovCloud (US-West) # Eine Richtlinie für die prädiktive Skalierung für Service-Auto-Scaling von Amazon ECS erstellen Erstellen Sie eine Richtlinie für die prädiktive Skalierung, damit Amazon ECS die Anzahl der Aufgaben, die von Ihrem Service ausgeführt werden, auf Grundlage historischer Daten erhöht oder verringert. **Anmerkung** Ein neuer Service muss Daten für mindestens 24 Stunden bereitstellen, bevor eine Prognose generiert werden kann. ## Konsole 1. Zusätzlich zu den IAM-Standardberechtigungen für das Erstellen und Aktualisieren von Services benötigen Sie zusätzliche Berechtigungen. Weitere Informationen finden Sie unter [Erforderliche IAM-Berechtigungen für Service-Auto-Scaling von Amazon ECS](auto-scaling-IAM.md). 1. Ermitteln Sie die Metriken, die für die Richtlinie verwendet werden sollen. Die folgenden Metriken sind verfügbar: + **ECSServiceDurchschnitt CPUUtilization** — Die durchschnittliche CPU-Auslastung, die der Service verwenden sollte. + **ECSServiceAverageMemoryUtilization**— Durchschnittliche Speicherauslastung, die der Service verwenden sollte. + **ALBRequestCountPerTarget**— Die durchschnittliche Anzahl von Anfragen pro Minute, die diese Aufgabe idealerweise erhalten sollte. Sie können alternativ eine benutzerdefinierte Metrik verwenden. Sie müssen die folgenden Werte definieren: + Auslastung – eine Metrik, die die volle Auslastung Ihrer Anwendung genau wiedergibt und den Aspekt Ihrer Anwendung darstellt, der für die Skalierung am wichtigsten ist. + Skalierungsmetrik – der beste Indikator dafür, wie viel Auslastung für Ihre Anwendung ideal ist. 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Service-Auto-Scaling** und dann **Anzahl der Aufgaben festlegen** aus. 1. Wählen Sie unter **Anzahl der Aufgaben für den Amazon-ECS-Service** die Option **Auto Scaling verwenden** aus. Der Abschnitt **Anzahl der Aufgaben** wird angezeigt. 1. Geben Sie unter **Mindestanzahl an Aufgaben**, die Untergrenze der Anzahl der Aufgaben an, die das Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht unterschreiten. 1. Geben Sie unter **Maximum** die Höchstanzahl der Aufgaben an, die Service-Auto-Scaling verwenden kann. Die gewünschte Anzahl wird diese Anzahl nicht überschreiten. 1. Wählen Sie **Speichern**. Die Richtlinien-Seite wird angezeigt. 1. Wählen Sie **Skalierungsrichtlinie erstellen** aus. Die Seite **Richtlinie erstellen** wird angezeigt. 1. Wählen Sie für **Typ der Skalierungsrichtlinie** die Option **Prädiktive Skalierung** aus. 1. Geben Sie unter **Policy name** (Richtlinienname) einen Namen für diese Richtlinie ein. 1. Für **Metrikpaar** wählen Sie Ihre Metriken aus der Liste der Optionen aus. Wenn Sie **Anzahl der Application Load Balancer pro Ziel** auswählen, wählen Sie anschließend in **Zielgruppe** eine Zielgruppe aus. **Anzahl and Anforderungen pro Ziel für Application Load Balancer** wird nur unterstützt, wenn Sie eine Zielgruppe für Application Load Balancer an Ihren Service angehängt haben. Wenn Sie **Benutzerdefiniertes Metrikpaar** auswählen, wählen Sie dann aus den Listen individuelle Metriken für **Lastmetrik** und **Skalierungsmetrik** aus. 1. Geben Sie für **Zielauslastung** den Zielwert für den Prozentsatz der Aufgaben ein, die Amazon ECS aufrechterhalten soll. Service-Auto-Scaling skaliert Ihre Kapazität auf, bis die durchschnittliche Auslastung der Zielauslastung entspricht oder bis sie die von Ihnen angegebene maximale Anzahl von Aufgaben erreicht. 1. Wählen Sie **Skalierungsrichtlinie erstellen** aus. ## AWS CLI Gehen Sie AWS CLI wie folgt vor, um Richtlinien für die vorausschauende Skalierung für Ihren Amazon ECS-Service zu konfigurieren. Ersetzen Sie jeden *user input placeholder* durch Ihre Informationen. Weitere Informationen zu den CloudWatch Metriken, die Sie angeben können, finden Sie [PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)in der *Amazon EC2 Auto Scaling API-Referenz.* ### Beispiel 1: Eine Richtlinie für die prädiktive Skalierung mit vordefiniertem Arbeitsspeicher. Nachstehend finden Sie eine Beispielrichtlinie mit einer vordefinierten Speicherkonfiguration. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 40, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceMemoryUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` Das folgende Beispiel veranschaulicht die Erstellung der Richtlinie, indem der [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)Befehl mit der angegebenen Konfigurationsdatei ausgeführt wird. ``` aws application-autoscaling put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` Wenn der Befehl erfolgreich ausgeführt wurde, gibt er den ARN der Richtlinie zurück. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` ### Beispiel 2: Eine Richtlinie für die prädiktive Skalierung mit vordefiniertem CPU. Folgendes ist eine Beispielrichtlinie mit einer vordefinierten CPU-Konfiguration. ``` cat policy.json { "MetricSpecifications": [ { "TargetValue": 0.00000004, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ECSServiceCPUUtilization" } } ], "SchedulingBufferTime": 3600, "MaxCapacityBreachBehavior": "HonorMaxCapacity", "Mode": "ForecastOnly" } ``` Das folgende Beispiel zeigt, wie die Richtlinie erstellt wird, indem der [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)Befehl mit der angegebenen Konfigurationsdatei ausgeführt wird. ``` aws aas put-scaling-policy \ --service-namespace ecs \ --region us-east-1 \ --policy-name predictive-scaling-policy-example \ --resource-id service/MyCluster/test \ --policy-type PredictiveScaling \ --scalable-dimension ecs:service:DesiredCount \ --predictive-scaling-policy-configuration file://policy.json ``` Wenn der Befehl erfolgreich ausgeführt wurde, gibt er den ARN der Richtlinie zurück. ``` { "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example", "Alarms": [] } ``` # Auswertung Ihrer Richtlinien für prädiktive Skalierung für Amazon ECS Bevor Sie eine Richtlinie für die prädiktive Skalierung Ihrer Services verwenden, überprüfen Sie die Empfehlungen und andere Daten zu Ihrer Richtlinie in der Amazon-ECS-Konsole. Dies ist wichtig, denn eine Richtlinie für prädiktive Skalierung soll Ihre tatsächliche Kapazität erst dann skalieren, wenn Sie wissen, dass die Prognosen korrekt sind. Wenn der Service neu ist, kann es 24 Stunden dauern, bis die erste Prognose erstellt wird. Bei AWS der Erstellung einer Prognose werden historische Daten verwendet. Wenn Ihr Service noch nicht über ausreichend aktuelle Verlaufsdaten verfügt, füllt die prädiktive Skalierung die Prognose möglicherweise vorübergehend mit Aggregaten auf, die aus den aktuell verfügbaren Verlaufsaggregaten erstellt wurden. Prognosen werden bis zu zwei Wochen vor dem Erstellungsdatum einer Richtlinie aufgefüllt. ## Anzeigen Ihrer Richtlinien für prädiktive Skalierung Für eine effektive Analyse sollte Service-Auto-Scaling über mindestens zwei Richtlinien für prädiktive Skalierung zum Vergleich verfügen. (Sie können die Ergebnisse jedoch weiterhin für eine einzelne Richtlinie überprüfen.) Wenn Sie mehrere Richtlinien erstellen, können Sie eine Richtlinie, die eine Metrik verwendet, gegen eine Richtlinie auswerten, die eine andere Metrik verwendet. Sie können auch die Auswirkungen verschiedener Zielwert- und Metrikkombinationen bewerten. Nachdem Richtlinien für die prädiktive Skalierung erstellt wurden, beginnt Amazon ECS sofort mit der Auswertung, welche Richtlinie für die Skalierung Ihrer Gruppe besser geeignet wäre. **So zeigen Sie Empfehlungen in der Amazon-ECS-Konsole an** 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Service-Auto-Scaling** aus. 1. Wählen Sie die Richtlinie für die prädiktive Skalierung und dann **Aktionen**, **Prädiktive Skalierung**, **Empfehlungen anzeigen** aus. Sie können Details zu einer Richtlinie sowie unsere Empfehlung anzeigen. In der Empfehlung erfahren Sie, ob es besser wäre, die Richtlinie für prädiktive Skalierung zu verwenden, oder nicht. Wenn Sie sich nicht sicher sind, ob eine prädiktive Skalierungsrichtlinie für Ihre Gruppe geeignet ist, prüfen Sie die Spalten **Auswirkungen auf die Verfügbarkeit** und **Auswirkungen auf die Kosten**, um die richtige Richtlinie auszuwählen. Die Informationen in den einzelnen Spalten geben Aufschluss über die Auswirkungen der jeweiligen Richtlinie. + **Auswirkungen auf die Verfügbarkeit**: Beschreibt, ob die Richtlinie negative Auswirkungen auf die Verfügbarkeit vermeiden würde, indem genügend Aufgaben zur Bewältigung des Workloads bereitgestellt werden, und zieht einen Vergleich für den Fall, dass die Richtlinie nicht verwendet wird. + **Auswirkungen auf die Kosten**: Beschreibt, ob die Richtlinie negative Auswirkungen auf Ihre Kosten vermeiden würde, indem Aufgaben nicht übermäßig bereitgestellt werden, und zieht einen Vergleich für den Fall, dass die Richtlinie nicht verwendet wird. Eine zu hohe Bereitstellung führt dazu, dass Ihre Services nicht ausgelastet sind oder sich im Leerlauf befinden, was die Kosten nur noch weiter erhöht. Wenn Sie über mehrere Richtlinien verfügen, wird neben dem Namen der Richtlinie, die die meisten Verfügbarkeitsvorteile zu geringeren Kosten bietet, ein Tag für die **Beste Prognose** angezeigt. Die Auswirkungen auf die Verfügbarkeit werden stärker gewichtet. 1. (Optional) Um den gewünschten Zeitraum für die Empfehlungsergebnisse auszuwählen, wählen Sie den gewünschten Wert aus der Dropdown-Liste **Auswertungszeitraum**: **2 Tage**, **1 Woche** oder **2 Wochen**. Standardmäßig wird der Auswertungszeitraum auf die letzten zwei Wochen festgelegt. Ein längerer Auswertungszeitraum liefert mehr Datenpunkte für die Empfehlungsergebnisse. Das Hinzufügen weiterer Datenpunkte verbessert die Ergebnisse jedoch möglicherweise nicht, wenn sich Ihre Lastmuster geändert haben, z. B. nach einer Phase außergewöhnlich hoher Nachfrage. In diesem Fall können Sie eine gezieltere Empfehlung erhalten, indem Sie sich aktuellere Daten ansehen. **Anmerkung** Empfehlungen werden nur für Richtlinien generiert, die sich im Modus **Nur Prognose** befinden. Das Empfehlungs-Feature liefert bessere Ergebnisse, wenn sich eine Richtlinie während des gesamten Bewertungszeitraums im Modus **Nur Prognose** befindet. Wenn Sie eine Richtlinie im **Prognose- und Skalierungsmodus** starten und diese später in den Modus **Nur Prognose** wechselt, sind die Ergebnisse für diese Richtlinie wahrscheinlich verzerrt. Dies liegt daran, dass die Richtlinie bereits zur tatsächlichen Kapazität beigetragen hat. ## Anzeigen von Diagrammen zur Überwachung der prädiktiven Skalierung In der Konsole können Sie die Prognose der vergangenen Tage, Wochen oder Monate überprüfen, um zu visualisieren, wie gut die Richtlinie im Laufe der Zeit funktioniert. Sie können diese Informationen auch zur Auswertung der Genauigkeit von Vorhersagen verwenden, wenn Sie entscheiden, ob die tatsächliche Anzahl an Aufgaben durch eine Richtlinie skalieren lassen möchten. **So überprüfen Sie Überwachungsdiagramme für die prädiktive Skalierung in der Amazon-ECS-Konsole** 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2). 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Service-Auto-Scaling** aus. 1. Wählen Sie die Richtlinie für die prädiktive Skalierung und dann **Aktionen**, **Prädiktive Skalierung**, **Diagramm anzeigen** aus. 1. Im Abschnitt **Überwachung** können Sie die vergangenen und zukünftigen Prognosen Ihrer Richtlinie für Last und Kapazität im Vergleich zu tatsächlichen Werten anzeigen. Das Diagramm für **Last** zeigt Auslastungsprognosen und tatsächliche Werte für die ausgewählte Auslastungsmetrik. Das Diagramm zur **Kapazität** zeigt die Anzahl der von der Richtlinie vorhergesagten Aufgaben. Es enthält auch die tatsächliche Anzahl der gestarteten Aufgaben. Die vertikale Linie trennt Verlaufswerte von zukünftigen Prognosen. Diese Diagramme stehen kurz nach der Erstellung der Richtlinie zur Verfügung. 1. (Optional) Um die Menge der im Diagramm angezeigten Verlaufsdaten zu ändern, wählen Sie Ihren bevorzugten Wert aus der Dropdown-Liste **Auswertungszeitraum** oben auf der Seite aus. Der Auswertungszeitraum verändert die Daten auf dieser Seite in keiner Weise. Er ändert nur die Menge der angezeigten Verlaufsdaten. **Vergleichen von Daten im Diagramm für **Last**** Jede horizontale Linie stellt einen anderen Satz von Datenpunkten dar, die in einstündigen Intervallen gemeldet werden: 1. **Tatsächliche beobachtete Last** verwendet die SUM-Statistik für die von Ihnen gewählte Lastmetrik, um die gesamte stündliche Last im Verlauf anzuzeigen. 1. **Von der Richtlinie prognostizierte Last** zeigt die stündliche Lastprognose. Diese Prognose basiert auf den tatsächlichen Lastbeobachtungen der letzten zwei Wochen. **Vergleichen von Daten im Diagramm zur **Kapazität**** Jede horizontale Linie stellt einen anderen Satz von Datenpunkten dar, die in einstündigen Intervallen gemeldet werden: 1. **Tatsächliche beobachtete Anzahl an Aufgaben** zeigt die tatsächliche Kapazität Ihres Amazon-ECS-Service in der Vergangenheit an, die von Ihren anderen Skalierungsrichtlinien und der für den ausgewählten Zeitraum geltenden Mindestgruppengröße abhängt. 1. **Von der Richtlinie prognostizierte Kapazität** zeigt die Basiskapazität an, die Sie zu Beginn jeder Stunde erwarten können, wenn sich die Richtlinie im Modus **Prognose und Skalierung** befindet. 1. **Abgeleitete erforderliche Anzahl an Aufgaben** zeigt die ideale Anzahl von Aufgaben in Ihrem Service, um die Skalierungsmetrik auf dem von Ihnen gewählten Zielwert zu halten. 1. **Mindestanzahl an Aufgaben** gibt die Mindestanzahl von Aufgaben in Ihrem Service an. 1. **Maximale Kapazität** gibt die maximale Anzahl von Aufgaben in Ihrem Service an. Um die abgeleitete erforderliche Kapazität zu berechnen, gehen wir zunächst davon aus, dass jede Aufgabe bei einem bestimmten Zielwert gleichmäßig ausgelastet ist. In der Praxis wird die Anzahl der Aufgaben nicht gleichmäßig ausgelastet. Wenn wir jedoch davon ausgehen, dass die Auslastung gleichmäßig auf die Aufgaben verteilt ist, können wir eine wahrscheinliche Schätzung der benötigten Kapazität vornehmen. Der erforderliche Anzahl an Aufgaben wird dann umgekehrt proportional zu der Skalierungsmetrik berechnet, die Sie für Ihre Richtlinie für prädiktive Skalierung verwendet haben. Mit anderen Worten heißt das: Wenn die Anzahl an Aufgaben zunimmt, nimmt die Skalierungsmetrik im gleichen Maß ab. Wenn sich beispielsweise die Anzahl an Aufgaben verdoppelt, muss die Skalierungsmetrik um die Hälfte verringert werden. Die Formel für die abgeleitete erforderliche Kapazität lautet wie folgt: `sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)` Als Beispiel nehmen wir den `actualServiceUnits` (`10`) und den `scalingMetricValue` (`30`) für eine bestimmte Stunde her. Wir nehmen dann die `targetUtilization`, die Sie in Ihrer Richtlinie für prädiktive Skalierung (`60`) angegeben haben, und berechnen die abgeleitete erforderliche Kapazität für dieselbe Stunde. Dies gibt den Wert `5` zurück. Das bedeutet, dass fünf die abgeleitete Kapazität ist, die erforderlich ist, um die Kapazität im direkt umgekehrten Verhältnis zum Zielwert der Skalierungsmetrik zu erhalten. **Anmerkung** Es stehen Ihnen verschiedene Möglichkeiten zur Verfügung, mit denen Sie die Kosteneinsparungen und die Verfügbarkeit Ihrer Anwendung verbessern können. Sie verwenden die prädiktive Skalierung für die Basiskapazität und die dynamische Skalierung für den Umgang mit zusätzlicher Kapazität. Die dynamische Skalierung funktioniert unabhängig von der prädiktiven Skalierung, indem sie basierend auf der aktuellen Auslastung ab- und aufskaliert. Zunächst berechnet Amazon ECS die empfohlene Anzahl an Aufgaben für jede nicht geplante Skalierungsrichtlinie. Anschließend skaliert die Lösung basierend auf der Richtlinie, die die größte Anzahl von Aufgaben bereitstellt. Damit bei sinkender Last eine Abskalierung erfolgen kann, sollte Ihr Service immer über mindestens eine dynamische Skalierungsrichtlinie verfügen, bei der das Abskalieren aktiviert ist. Sie können die Skalierungsleistung verbessern, indem Sie sicherstellen, dass Ihre Mindest- und Höchstkapazität nicht zu restriktiv ist. Eine Richtlinie mit einer empfohlenen Anzahl von Aufgaben, die nicht innerhalb des Mindest- und Höchstkapazitätsbereichs liegt, wird an der Ab- und Aufskalierung gehindert. # Überwachen Sie prädiktive Skalierungsmetriken für Amazon ECS mit CloudWatch Sie können Amazon verwenden CloudWatch , um Ihre Daten im Hinblick auf eine vorausschauende Skalierung zu überwachen. Eine Richtlinie für die prädiktive Skalierung sammelt Daten, um Ihre zukünftige Last zu prognostizieren. Die gesammelten Daten werden automatisch in regelmäßigen CloudWatch Abständen gespeichert und können verwendet werden, um zu visualisieren, wie gut die Richtlinie im Laufe der Zeit abschneidet. Sie können auch CloudWatch Alarme einrichten, um Sie zu benachrichtigen, wenn sich Leistungsindikatoren über die von Ihnen definierten Grenzwerte hinaus ändern. ## Visualisieren historischer Prognosedaten Ladeprognosedaten für eine Richtlinie zur vorausschauenden Skalierung können in eingesehen werden CloudWatch und können nützlich sein, wenn Prognosen im Vergleich zu anderen CloudWatch Metriken in einem einzigen Diagramm visualisiert werden. Sie können auch einen größeren Zeitraum anzeigen, um Trends im Zeitverlauf zu erkennen. Ihnen stehen historische Metriken von bis zu 15 Monaten zur Verfügung, um die Leistung Ihrer Richtlinie besser analysieren zu können. **Um historische Prognosedaten mit der Konsole anzuzeigen CloudWatch** 1. Öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. Wählen Sie im Navigationsbereich **Metrics** (Metriken) und dann **All metrics** (Alle Metriken) aus. 1. Wählen Sie den Metrik-Namespace für **Application Auto Scaling** aus. 1. Wählen Sie **Prädiktive Skalierung: Lastprognosen** aus. 1. Geben Sie im Suchfeld den Namen der Richtlinie für die prädiktive Skalierung oder den Namen der Amazon–ECS-Servicegruppe ein, und drücken Sie dann die Eingabetaste, um die Ergebnisse zu filtern. 1. Um eine Metrik grafisch darzustellen, müssen Sie das Kontrollkästchen neben der Metrik aktivieren. Wenn Sie den Namen des Diagramms ändern möchten, wählen Sie das Bleistiftsymbol. Wenn Sie den Zeitraum ändern möchten, müssen Sie einen der vordefinierten Werte oder **custom (benutzerdefiniert)** auswählen. Weitere Informationen finden Sie unter [Grafische Darstellung einer Metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html) im * CloudWatch Amazon-Benutzerhandbuch*. 1. Wenn Sie die Statistik ändern möchten, wählen Sie die Registerkarte **Graphed metrics** aus. Wählen Sie die Spaltenüberschrift oder einen einzelnen Wert und anschließend eine andere Statistik aus. Sie können zwar für jede Metrik eine beliebige Statistik wählen, aber nicht alle Statistiken sind für **PredictiveScalingLoadForecast**Metriken nützlich. So sind zum Beispiel die Statistiken **Durchschnitt**, **Minimum** und **Maximum** hilfreich, die Statistik **Summe** jedoch nicht. 1. Wenn Sie dem Diagramm eine weitere Metrik hinzufügen möchten, wählen Sie unter **Browse** (Durchsuchen) die Option **All** (Alle) aus, suchen Sie nach der spezifischen Metrik, und aktivieren Sie dann das zugehörige Kontrollkästchen. Sie können bis zu 10 Metriken hinzufügen. 1. (Optional) Um das Diagramm zu einem CloudWatch Dashboard hinzuzufügen, wählen Sie **Aktionen**, **Zum Dashboard hinzufügen** aus. ## Erstellen von Genauigkeitsmetriken mithilfe von Metrikberechnungen Mit metrischer Mathematik können Sie mehrere CloudWatch Metriken abfragen und mathematische Ausdrücke verwenden, um neue Zeitreihen auf der Grundlage dieser Metriken zu erstellen. Sie können die resultierenden Zeitreihen auf der CloudWatch Konsole visualisieren und sie zu Dashboards hinzufügen. Weitere Informationen zur metrischen Mathematik finden Sie unter [Verwenden von metrischer Mathematik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) im * CloudWatch Amazon-Benutzerhandbuch*. Mithilfe von Metrikberechnungen können Sie die Daten, die Service-Auto-Scaling für die prädiktive Skalierung generiert, auf unterschiedliche Weise grafisch darstellen. So können Sie die Leistung von Richtlinien im Zeitverlauf überwachen und erkennen, ob Ihre Kombination von Metriken möglicherweise verbessert werden kann. Sie können beispielsweise einen Metrikberechnungsausdruck verwenden, um den [Mean Absolute Percentage Error](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error) (MAPE) zu überwachen. Die MAPE-Metrik hilft bei der Überwachung der Differenz zwischen den prognostizierten Werten und den tatsächlichen Werten eines bestimmten Prognosefensters. Änderungen des MAPE-Werts können Aufschluss darüber geben, ob sich die Leistung der Richtlinie im Laufe der Zeit verschlechtert, wenn sich Ihre Anwendung verändert. Eine Erhöhung des MAPE-Werts bedeutet eine größere Diskrepanz zwischen prognostizierten und tatsächlichen Werten. **Beispiel: Metrikberechnungsausdruck** Für die ersten Schritte mit dieser Art von Diagramm können Sie beispielsweise den Metrikberechnungsausdruck aus dem folgenden Beispiel erstellen. Anstelle einer einzelnen Metrik gibt es für `MetricDataQueries` ein Array von Abfragestrukturen für Metrikdaten. Jedes Element in `MetricDataQueries` ruft eine Metrik ab oder wendet einen mathematischen Ausdruck an. Das erste Element (`e1`) ist der mathematische Ausdruck. Der angegebene Ausdruck legt den Parameter `ReturnData` auf `true` fest, was letztendlich eine einzelne Zeitreihe generiert. Für alle anderen Metriken hat `ReturnData` den Wert `false`. In diesem Beispiel verwendet der angegebene Ausdruck die tatsächlichen und prognostizierten Werte als Eingabe und gibt die neue Metrik (MAPE) zurück. `m1`ist die CloudWatch Metrik, die die tatsächlichen Lastwerte enthält (vorausgesetzt, die CPU-Auslastung ist die Lastmetrik, die ursprünglich für die genannte `my-predictive-scaling-policy` Richtlinie angegeben wurde). `m2`ist die CloudWatch Metrik, die die prognostizierten Lastwerte enthält. Die mathematische Syntax für die MAPE-Metrik lautet wie folgt: *Durchschnitt von (abs ((tatsächlicher Wert - prognostizierter Wert)/(tatsächlichen Wert)))* ### Visualisieren Ihrer Genauigkeitsmetriken und Festlegen von Alarmen Um die Genauigkeitsmetrikdaten zu visualisieren, wählen Sie in der CloudWatch Konsole die Registerkarte **Metriken** aus. Von dort aus können Sie die Daten grafisch darstellen. Weitere Informationen finden Sie unter [Hinzufügen eines mathematischen Ausdrucks zu einem CloudWatch Diagramm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console) im * CloudWatch Amazon-Benutzerhandbuch*. Im Abschnitt **Metrics** (Metriken) können Sie auch einen Alarm für eine von Ihnen überwachte Metrik festlegen. Wählen Sie auf der Registerkarte **Graphed metrics** (Grafisch dargestellte Metriken) unter der Spalte **Actions** (Aktionen) das Symbol **Create alarm** (Alarm erstellen) aus. Das Symbol **Create alarm** (Alarm erstellen) wird als kleine Glocke dargestellt. Weitere Informationen und Benachrichtigungsoptionen finden Sie unter [Erstellen eines CloudWatch Alarms auf der Grundlage eines metrischen mathematischen Ausdrucks](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) und [Benachrichtigung von Benutzern über Alarmänderungen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html) im * CloudWatch Amazon-Benutzerhandbuch*. Alternativ können Sie [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)und verwenden, [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html)um Berechnungen mithilfe metrischer Mathematik durchzuführen und Alarme auf der Grundlage der Ausgabe zu erstellen. # Geplante Aktionen verwenden, um Prognosewerte für Amazon ECS zu überschreiben Manchmal haben Sie möglicherweise zusätzliche Informationen zu Ihren zukünftigen Anwendungsanforderungen, die bei der Prognoseberechnung nicht berücksichtigt werden können. Prognoseberechnungen können beispielsweise die Aufgaben unterschätzen, die für ein bevorstehendes Marketing-Ereignis benötigt wird. Sie können geplante Aktionen verwenden, um die Prognose in zukünftigen Zeiträumen vorübergehend zu überschreiben. Die geplanten Aktionen können auf einer wiederkehrenden Basis oder zu einem bestimmten Zeitpunkt ausgeführt werden, wenn einmalige Nachfrageschwankungen auftreten. Sie können beispielsweise eine geplante Aktion mit einer höheren Anzahl an Aufgaben als die prognostizierte erstellen. Zur Laufzeit aktualisiert Amazon ECS die Mindestanzahl von Aufgaben in Ihrem Service. Da die prädiktive Skalierung die Anzahl der Aufgaben optimiert, wird eine geplante Aktion mit einer minimalen Anzahl an Aufgaben, die höher als die Prognosewerte ist, berücksichtigt. Dadurch wird verhindert, dass die Anzahl der Aufgaben geringer ist als erwartet. Um das Überschreiben der Prognose zu stoppen, setzen Sie über eine zweite geplante Aktion die minimale Anzahl an Aufgaben auf ihre ursprüngliche Einstellung zurück. Im folgenden Verfahren werden die Schritte zum Überschreiben der Prognose in zukünftigen Zeiträumen erläutert. **Topics** + [Schritt 1: (Optional) Analysieren von Zeitreihendaten](#analyzing-time-series-data) + [Schritt 2: Erstellen von zwei geplanten Aktionen](#scheduling-capacity) **Wichtig** In diesem Thema wird davon ausgegangen, dass Sie versuchen, die Prognose zu überschreiben, um auf eine höhere Kapazität als die prognostizierte zu skalieren. Wenn Sie die Anzahl der Aufgaben vorübergehend verringern müssen, ohne dass dies durch eine Richtlinie zur prädiktiven Skalierung beeinträchtigt wird, verwenden Sie stattdessen den Modus *Nur Prognose*. Im Modus Nur Prognose generiert die prädiktive Skalierung zwar weiterhin Prognosen, die Anzahl der Aufgaben wird jedoch nicht automatisch erhöht. Anschließend können Sie die Ressourcennutzung überwachen und die Anzahl der Aufgaben nach Bedarf manuell verringern. ## Schritt 1: (Optional) Analysieren von Zeitreihendaten Beginnen Sie mit der Analyse der Prognose-Zeitreihendaten. Dies ist ein optionaler Schritt, aber es ist hilfreich, wenn Sie die Details der Prognose verstehen möchten. 1. **Rufen Sie die Prognose ab** Nachdem die Prognose erstellt wurde, können Sie einen bestimmten Zeitraum in der Prognose abfragen. Ziel der Abfrage ist es, einen vollständigen Überblick über die Zeitreihendaten für einen bestimmten Zeitraum zu erhalten. Ihre Abfrage kann Prognosedaten bis zwei Tage in die Zukunft enthalten. Wenn Sie die prädiktive Skalierung eine Weile verwenden, können Sie auch auf Ihre früheren Prognosedaten zugreifen. Der maximale Zeitraum zwischen der Start- und Endzeit beträgt jedoch 30 Tage. Um die Prognose mithilfe des [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI Befehls abzurufen, geben Sie im Befehl die folgenden Parameter an: + Geben Sie den Namen des Clusters im Parameter `resource-id` an. + Geben Sie den Namen der Richtlinie im `--policy-name`-Parameter an. + Geben Sie die Startzeit im `--start-time`-Parameter an, um nur prognostizierte Daten für den angegebenen Zeitpunkt oder danach zurückzugeben. + Geben Sie die Endzeit im `--end-time`-Parameter an, um nur prognostizierte Daten für den angegebenen Zeitpunkt oder davor zurückzugeben. ``` aws application-autoscaling get-predictive-scaling-forecast \ --service-namespace ecs \ --resource-id service/MyCluster/test \ --policy-name cpu40-predictive-scaling-policy \ --scalable-dimension ecs:service:DesiredCount \ --start-time "2021-05-19T17:00:00Z" \ --end-time "2021-05-19T23:00:00Z" ``` Bei erfolgreicher Ausführung gibt der Befehl Daten zurück, die in etwa wie folgt aussehen: ``` { "LoadForecast": [ { "Timestamps": [ "2021-05-19T17:00:00+00:00", "2021-05-19T18:00:00+00:00", "2021-05-19T19:00:00+00:00", "2021-05-19T20:00:00+00:00", "2021-05-19T21:00:00+00:00", "2021-05-19T22:00:00+00:00", "2021-05-19T23:00:00+00:00" ], "Values": [ 153.0655799339254, 128.8288551285919, 107.1179447150675, 197.3601844551528, 626.4039934516954, 596.9441277518481, 677.9675713779869 ], "MetricSpecification": { "TargetValue": 40.0, "PredefinedMetricPairSpecification": { "PredefinedMetricType": "ASGCPUUtilization" } } } ], "CapacityForecast": { "Timestamps": [ "2021-05-19T17:00:00+00:00", "2021-05-19T18:00:00+00:00", "2021-05-19T19:00:00+00:00", "2021-05-19T20:00:00+00:00", "2021-05-19T21:00:00+00:00", "2021-05-19T22:00:00+00:00", "2021-05-19T23:00:00+00:00" ], "Values": [ 2.0, 2.0, 2.0, 2.0, 4.0, 4.0, 4.0 ] }, "UpdateTime": "2021-05-19T01:52:50.118000+00:00" } ``` Die Antwort enthält zwei Prognosen: `LoadForecast` und `CapacityForecast`. `LoadForecast` zeigt die stündliche Lastprognose an. `CapacityForecast` zeigt Prognosewerte für die Kapazität an, die stündlich benötigt wird, um die prognostizierte Last zu verarbeiten, während ein `TargetValue` von 40,0 (40 % durchschnittliche CPU-Auslastung) aufrechterhalten bleibt. 1. **Identifizieren des Zielzeitraums** Ermitteln Sie die Stunde oder die Stunden, zu der/zu denen die einmalige Nachfrageschwankung stattfinden soll. Denken Sie daran, dass die in der Prognose angezeigten Datumsangaben und Uhrzeiten in UTC angegeben sind. ## Schritt 2: Erstellen von zwei geplanten Aktionen Erstellen Sie als Nächstes zwei geplante Aktionen für einen bestimmten Zeitraum, in dem Ihre Anwendung eine höhere Last aufweist als die prognostizierte Last. Wenn Sie beispielsweise während eines Marketing-Ereignisses für einen begrenzten Zeitraum ein erhöhtes Daten-Volume erwarten, können Sie eine einmalige Aktion planen, um die Mindestkapazität bei deren Beginn zu aktualisieren. Planen Sie dann eine weitere Aktion, um die Mindestkapazität auf die ursprüngliche Einstellung zurückzusetzen, wenn das Ereignis endet. 1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2. 1. Wählen Sie auf der **Cluster**-Seite den Cluster aus. 1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus. Die Service-Detailseite wird angezeigt. 1. Wählen Sie **Service-Auto-Scaling** aus. Die Richtlinien-Seite wird angezeigt. 1. Wählen Sie **Geplante Aktionen** und dann **Erstellen** aus. Die Seite **Geplante Aktion erstellen** wird angezeigt. 1. Geben Sie für **Aktionsname** einen eindeutigen Namen ein. 1. Wählen Sie für **Zeitzone** eine Zeitzone aus. Alle aufgelisteten Zeitzonen stammen aus der IANA-Zeitzonendatenbank. Weitere Informationen finden Sie unter [Liste der Zeitzonen der TZ-Datenbank](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). 1. Geben Sie als **Startzeit** das **Datum** und die **Uhrzeit** ein, zu der die Aktion gestartet wird. 1. Wählen Sie für **Recurrence (Wiederholung)** **Once (Einmal)** aus. 1. Geben Sie unter **Aufgabenanpassungen** für Minimum einen Wert ein, der kleiner oder gleich der maximalen Anzahl von Aufgaben ist. 1. Wählen Sie **Geplante Aktion erstellen**. Die Richtlinien-Seite wird angezeigt. 1. Konfigurieren Sie eine zweite geplante Aktion, um die Mindestanzahl an Aufgaben am Ende des Ereignisses wieder auf die ursprüngliche Einstellung zurückzustellen. Die prädiktive Skalierung kann die Kapazität nur skalieren, wenn der Wert, den Sie für **Minimum** angeben, niedriger ist als die Prognosewerte. **Erstellen von zwei geplanten Aktionen für einmalige Ereignisse (AWS CLI)** Verwenden Sie den Befehl [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html), AWS CLI um die geplanten Aktionen zu erstellen. Lassen Sie uns als Beispiel einen Zeitplan definieren, der am 19. Mai um 17:00 Uhr acht Stunden lang eine Mindestkapazität von drei Instances beibehält. Die folgenden Befehle veranschaulichen die Implementierung dieses Szenarios. Der erste Befehl [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) weist Amazon EC2 Auto Scaling an, die Mindestkapazität der angegebenen Auto Scaling-Gruppe am 19. Mai 2021 um 17:00 Uhr UTC zu aktualisieren. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \ --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3 ``` Der zweite Befehl weist Amazon EC2 Auto Scaling an, die Mindestkapazität der Gruppe am 20. Mai 2021 um 1:00 Uhr UTC auf eins zu setzen. ``` aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \ --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1 ``` Nachdem Sie der Auto-Scaling-Gruppe diese geplanten Aktionen hinzugefügt haben, führt Amazon EC2 Auto Scaling folgende Schritte aus: + Um 17:00 Uhr UTC am 19. Mai 2021 wird die erste geplante Aktion ausgeführt. Wenn die Gruppe derzeit weniger als drei Instances hat, wird die Gruppe auf drei Instances skaliert. Während dieser Zeit und für die Dauer der nächsten acht Stunden kann Amazon EC2 Auto Scaling weiterhin skaliert werden, wenn die prognostizierte Kapazität höher als die tatsächliche Kapazität ist oder wenn eine Richtlinie für dynamische Skalierung in Kraft ist. + Um 1:00 Uhr UTC am 20. Mai 2021 wird die zweite geplante Aktion ausgeführt. Dadurch wird die Mindestkapazität am Ende des Ereignisses auf die ursprüngliche Einstellung zurückgesetzt. ### Skalierung basierend auf wiederkehrenden Zeitplänen Um die Prognose jede Woche während des gleichen Zeitraums zu überschreiben, erstellen Sie zwei geplante Aktionen und stellen die Zeit- und Datumslogik mithilfe eines Cron-Ausdrucks bereit. Der Cron-Ausdruck besteht aus fünf Feldern, getrennt durch Leerzeichen: [Minute] [Stunde] [Tag\$1des\$1Monats] [Monat\$1des\$1Jahres] [Wochentag]. Felder können alle zulässigen Werte enthalten, einschließlich Sonderzeichen. Beispielsweise führt der folgende Cron-Ausdruck jeden Dienstag um 6:30 Uhr die Aktion aus. Das Sternchen wird als Platzhalter verwendet, um alle Werte für ein Feld abzugleichen. ``` 30 6 * * 2 ``` ### Weitere Informationen finden Sie auch unter Weitere Informationen zur Verwaltung von geplanten Aktionen finden Sie unter [Verwenden Sie geplante Aktionen, um Amazon ECS-Services zu skalieren](service-autoscaling-schedulescaling.md). # Erweiterte prädiktive Skalierungsrichtlinie mit benutzerdefinierten Metriken für Amazon ECS In einer prädiktiven Skalierungsrichtlinie können Sie vordefinierte oder benutzerdefinierte Metriken verwenden. Benutzerdefinierte Metriken sind nützlich, wenn die vordefinierten Metriken (z. B. CPU, Arbeitsspeicher usw.) nicht ausreichen, um Ihre Anwendungslast ausreichend zu beschreiben. Wenn Sie eine Richtlinie für vorausschauende Skalierung mit benutzerdefinierten Metriken erstellen, können Sie andere Metriken angeben, die von bereitgestellt werden. CloudWatch AWS Alternativ können Sie Metriken angeben, die Sie selbst definieren und veröffentlichen. Sie können auch metrische Mathematik verwenden, um bestehende Metriken zu aggregieren und in eine neue Zeitreihe umzuwandeln, die AWS nicht automatisch erfasst wird. Wenn Sie beispielsweise Werte in Ihren Daten kombinieren, indem Sie neue Summen oder Durchschnittswerte berechnen, nennt man das *Aggregieren*. Die resultierenden Daten werden als *Aggregat* bezeichnet. Der folgende Abschnitt enthält bewährte Verfahren und Beispiele für die Erstellung der JSON-Struktur für die Richtlinie. ## Voraussetzungen Um benutzerdefinierte Metriken zu Ihrer prädiktiven Skalierungsrichtlinie hinzuzufügen, müssen Sie über entsprechende `cloudwatch:GetMetricData`-Berechtigungen verfügen. Wenn Sie Ihre eigenen Kennzahlen anstelle der bereitgestellten Metriken angeben möchten, müssen Sie Ihre Metriken zunächst auf veröffentlichen CloudWatch. AWS Weitere Informationen finden Sie unter [Veröffentlichen benutzerdefinierter Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) im * CloudWatch Amazon-Benutzerhandbuch*. Sollten Sie Ihre eigenen Metriken veröffentlichen, achten Sie darauf, dass Sie die Datenpunkte mindestens alle fünf Minuten veröffentlichen. Datenpunkte werden CloudWatch basierend auf der Länge des benötigten Zeitraums abgerufen. In der Lastmetrikspezifikation werden beispielsweise stündliche Messwerte verwendet, um die Auslastung Ihrer Anwendung zu messen. CloudWatch verwendet Ihre veröffentlichten Metrikdaten, um einen einzelnen Datenwert für einen beliebigen Zeitraum von einer Stunde bereitzustellen, indem alle Datenpunkte mit Zeitstempeln aggregiert werden, die in jeden Zeitraum von einer Stunde fallen. ## Best Practices Die folgenden bewährten Methoden können Ihnen helfen, benutzerdefinierte Metriken effektiver zu nutzen: + Bei der Angabe der Lastmetrik ist die sinnvollste Metrik eine, die die Last einer Auto-Scaling-Gruppe als Ganzes darstellt. + Bei der Angabe der Skalierungsmetrik ist die sinnvollste Metrik für die Skalierung ein durchschnittlicher Durchsatz oder eine durchschnittliche Auslastung pro Aufgabe. + Die Zielauslastung muss mit der Art der Skalierungsmetrik übereinstimmen. Bei einer Richtlinienkonfiguration, die die CPU-Auslastung verwendet, ist dies beispielsweise ein Zielprozentsatz. + Wenn diese Empfehlungen nicht befolgt werden, werden die prognostizierten zukünftigen Werte der Zeitreihen wahrscheinlich falsch sein. Um zu überprüfen, ob die Daten korrekt sind, können Sie die prognostizierten Werte in der Konsole einsehen. Sie können auch nach der Erstellung Ihrer Richtlinie für vorausschauende Skalierung die `LoadForecast` Objekte überprüfen, die durch einen API-Aufruf zurückgegeben wurden. [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html) + Wir empfehlen Ihnen dringend, die prädiktive Skalierung im Modus Nur Prognose zu konfigurieren, damit Sie die Prognose auswerten können, bevor die prädiktive Skalierung mit der aktiven Skalierung beginnt. ## Einschränkungen + Sie können Datenpunkte von bis zu 10 Metriken in einer Metrikspezifikation abfragen. + Für die Zwecke dieses Limits zählt ein Ausdruck als eine Metrik. ## Fehlerbehebung einer Richtlinie für die prädiktive Skalierung mit benutzerdefinierten Metriken Wenn bei der Verwendung von benutzerdefinierten Metriken ein Problem auftritt, empfehlen wir Ihnen, wie folgt vorzugehen: + Wenn bei einer blue/green Bereitstellung bei der Verwendung eines Suchausdrucks ein Problem auftritt, stellen Sie sicher, dass Sie einen Suchausdruck erstellt haben, der nach einer teilweisen und nicht nach einer exakten Übereinstimmung sucht. Vergewissern Sie sich außerdem, dass Ihre Anfrage nur die Auto-Scaling-Gruppen findet, in denen die betreffende Anwendung ausgeführt wird. Weitere Informationen zur Syntax von Suchausdrücken finden Sie unter [Syntax von CloudWatch Suchausdrücken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html) im * CloudWatch Amazon-Benutzerhandbuch*. + Der [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html)Befehl validiert einen Ausdruck, wenn Sie Ihre Skalierungsrichtlinie erstellen. Es besteht jedoch die Möglichkeit, dass dieser Befehl die genaue Ursache der erkannten Fehler nicht identifizieren kann. Um die Probleme zu beheben, beheben Sie die Fehler, die Sie als Antwort auf eine Anfrage auf den [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html)Befehl erhalten. Sie können den Ausdruck auch von der CloudWatch Konsole aus beheben. + Sie müssen `false` für `ReturnData` angeben, wenn `MetricDataQueries` die Funktion SEARCH() allein ohne eine mathematische Funktion wie SUM() angibt. Das liegt daran, dass Suchausdrücke mehrere Zeitreihen zurückgeben können, während eine auf einem Ausdruck basierende Metrikspezifikation nur eine Zeitreihe zurückgeben kann. + Alle an einem Suchausdruck beteiligten Metriken sollten die gleiche Auflösung haben. # Erstellen der JSON für benutzerdefinierte Metriken für die prädiktive Skalierung mit Amazon ECS Der folgende Abschnitt enthält Beispiele für die Konfiguration der prädiktiven Skalierung für die Abfrage von Daten von CloudWatch. Es gibt zwei verschiedene Methoden, um diese Option zu konfigurieren, und die von Ihnen gewählte Methode wirkt sich darauf aus, welches Format Sie verwenden, um den JSON für Ihre prädiktive Skalierungsrichtlinie zu erstellen. Wenn Sie metrische Berechnungen verwenden, variiert das Format von JSON je nach der durchgeführten metrischen Berechnung weiter. 1. Informationen zum Erstellen einer Richtlinie, mit der Daten direkt aus anderen CloudWatch Metriken abgerufen werden, die von bereitgestellt werden AWS oder für die Sie Daten veröffentlichen CloudWatch, finden [Beispiel für eine Richtlinie zur vorausschauenden Skalierung mit benutzerdefinierten Last- und Skalierungsmetriken unter Verwendung von AWS CLI](#predictive-scaling-custom-metrics-example1) Sie unter. ## Beispiel für eine Richtlinie zur vorausschauenden Skalierung mit benutzerdefinierten Last- und Skalierungsmetriken unter Verwendung von AWS CLI Um eine Richtlinie für vorausschauende Skalierung mit benutzerdefinierten Last- und Skalierungsmetriken mit dem zu erstellen AWS CLI, speichern Sie die Argumente für `--predictive-scaling-configuration` in einer JSON-Datei mit dem Namen. `config.json` Sie beginnen mit dem Hinzufügen benutzerdefinierter Metriken, indem Sie die ersetzbaren Werte im folgenden Beispiel durch die Werte Ihrer Metriken und Ihrer Zielauslastung ersetzen. ``` { "MetricSpecifications": [ { "TargetValue": 50, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Id": "scaling_metric", "MetricStat": { "Metric": { "MetricName": "MyUtilizationMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Average" } } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "MyLoadMetric", "Namespace": "MyNameSpace", "Dimensions": [ { "Name": "MyOptionalMetricDimensionName", "Value": "MyOptionalMetricDimensionValue" } ] }, "Stat": "Sum" } } ] } } ] } ``` Weitere Informationen finden Sie [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)in der *Amazon EC2 Auto Scaling API-Referenz.* **Anmerkung** Im Folgenden finden Sie einige zusätzliche Ressourcen, die Ihnen bei der Suche nach Metriknamen, Namespaces, Dimensionen und Statistiken für Metriken helfen können: CloudWatch Informationen zu den verfügbaren Metriken für AWS Services finden Sie im * CloudWatch Amazon-Benutzerhandbuch* unter [AWS Services, die CloudWatch Metriken veröffentlichen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html). Den genauen Metriknamen, den Namespace und die Dimensionen (falls zutreffend) für eine CloudWatch Metrik mit dem finden Sie unter AWS CLI[list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html). Um diese Richtlinie zu erstellen, führen Sie den [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html)Befehl mit der JSON-Datei als Eingabe aus, wie im folgenden Beispiel gezeigt. ``` aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json ``` Wenn der Befehl erfolgreich ausgeführt wurde, gibt er den Amazon-Ressourcennamen (ARN) der Richtlinie zurück. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy", "Alarms": [] } ``` # Metrikberechnungs-Ausdrücke verwenden Der folgende Abschnitt enthält Informationen zur Verwendung von Metrikberechnungen mit Richtlinien zur prädiktiven Skalierung in Ihrer Richtlinie. ## Metrikberechnung verstehen Wenn Sie lediglich vorhandene Metrikdaten aggregieren möchten, erspart Ihnen CloudWatch Metric Math den Aufwand und die Kosten für die Veröffentlichung einer weiteren Metrik in CloudWatch. Sie können jede verfügbare Metrik verwenden AWS , und Sie können auch Metriken verwenden, die Sie als Teil Ihrer Anwendungen definieren. Weitere Informationen finden Sie unter [Verwenden von metrischer Mathematik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) im * CloudWatch Amazon-Benutzerhandbuch*. Wenn Sie sich für die Verwendung eines metrischen mathematischen Ausdrucks in Ihrer prädiktiven Skalierungsrichtlinie entscheiden, sollten Sie die folgenden Punkte beachten: + Metrische mathematische Operationen verwenden die Datenpunkte der eindeutigen Kombination aus Metriknamen, Namespace und keys/value Dimensionspaaren von Metriken. + Sie können einen beliebigen arithmetischen Operator (\$1 - \$1/^), jede statistische Funktion (wie AVG oder SUM) oder eine andere Funktion verwenden, die diese Funktion unterstützt. CloudWatch + Sie können sowohl Metriken als auch die Ergebnisse anderer mathematischer Ausdrücke in den Formeln des mathematischen Ausdrucks verwenden. + Ihre metrischen mathematischen Ausdrücke können aus verschiedenen Aggregationen zusammengesetzt sein. Für das endgültige Aggregationsergebnis ist es jedoch eine bewährte Methode, `Average` für die Skalierungsmetrik und `Sum` für die Lastmetrik zu verwenden. + Alle Ausdrücke, die in einer metrischen Spezifikation verwendet werden, müssen letztendlich eine einzige Zeitreihe ergeben. Um metrische Mathematik zu verwenden, gehen Sie wie folgt vor: + Wählen Sie eine oder mehrere CloudWatch Metriken aus. Erstellen Sie dann den Ausdruck. Weitere Informationen finden Sie unter [Verwenden von metrischer Mathematik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) im * CloudWatch Amazon-Benutzerhandbuch*. + Stellen Sie mithilfe der CloudWatch Konsole oder der CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html)API sicher, dass der metrische mathematische Ausdruck gültig ist. ## Beispiel für eine prädiktive Skalierungspolitik, die Metriken mit metrischer Mathematik kombiniert (AWS CLI) Manchmal müssen Sie die Metrik nicht direkt angeben, sondern die Daten erst auf irgendeine Weise verarbeiten. Sie könnten zum Beispiel eine Anwendung haben, die Arbeit aus einer Amazon SQS-Warteschlange abruft, und Sie könnten die Anzahl der Objekte in der Warteschlange als Kriterium für die prädiktive Skalierung verwenden wollen. Die Anzahl der Nachrichten in der Warteschlange bestimmt nicht allein die Anzahl der Instances, die Sie benötigen. Daher ist weitere Arbeit erforderlich, um eine Metrik zu erstellen, die zur Berechnung des Rückstands pro Instance verwendet werden kann. Im Folgenden finden Sie ein Beispiel für eine prädiktive Skalierungsrichtlinie für dieses Szenario. Sie legt Skalierungs- und Auslastungsmetriken fest, die auf der Amazon SQS `ApproximateNumberOfMessagesVisible`-Metrik basieren, d.h. der Anzahl der Nachrichten, die für den Abruf aus der Warteschlange verfügbar sind. Es verwendet auch die Amazon EC2 Auto Scaling `GroupInServiceInstances`-Metrik und einen mathematischen Ausdruck, um den Rückstand pro Instance für die Skalierungsmetrik zu berechnen. ``` aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \ --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json --service-namespace ecs \ --resource-id service/MyCluster/test \ "MetricSpecifications": [ { "TargetValue": 100, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Label": "Get the queue size (the number of messages waiting to be processed)", "Id": "queue_size", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Get the group size (the number of running instances)", "Id": "running_capacity", "MetricStat": { "Metric": { "MetricName": "GroupInServiceInstances", "Namespace": "AWS/AutoScaling", "Dimensions": [ { "Name": "AutoScalingGroupName", "Value": "my-asg" } ] }, "Stat": "Sum" }, "ReturnData": false }, { "Label": "Calculate the backlog per instance", "Id": "scaling_metric", "Expression": "queue_size / running_capacity", "ReturnData": true } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_metric", "MetricStat": { "Metric": { "MetricName": "ApproximateNumberOfMessagesVisible", "Namespace": "AWS/SQS", "Dimensions": [ { "Name": "QueueName", "Value": "my-queue" } ], }, "Stat": "Sum" }, "ReturnData": true } ] } } ] } ``` Das Beispiel gibt den ARN der Richtlinie zurück. ``` { "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy", "Alarms": [] } ```