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. # Prädiktive Skalierung für Application Auto Scaling Predictive Scaling skaliert Ihre Anwendung proaktiv. Predictive Scaling analysiert historische Lastdaten, um tägliche oder wöchentliche Muster im Verkehrsfluss zu erkennen. Es verwendet diese Informationen, um den future Kapazitätsbedarf zu prognostizieren, um die Kapazität Ihrer Anwendung proaktiv an die erwartete Auslastung anzupassen. Die prädiktive Skalierung eignet sich gut für Situationen, in denen Sie Folgendes haben: + Zyklischen Datenverkehr, z. B. hohe 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, wie z. B. Stapelverarbeitung, Tests oder regelmäßige Datenanalysen. + Anwendungen, die eine lange Zeit in Anspruch nehmen, was zu einer spürbaren Latenzauswirkung auf die Anwendungsleistung bei Aufskalierungsereignissen führt **Topics** + [Funktionsweise](aas-predictive-scaling-how-it-works.md) + [Eine Richtlinie für die prädiktive Skalierung erstellen](aas-create-predictive-scaling-policy.md) + [Prognose überschreiben](aas-predictive-scaling-overriding-forecast-capacity.md) + [Verwenden benutzerdefinierter Metriken](aas-predictive-scaling-customized-metric-specification.md) # So funktioniert die prädiktive Skalierung von Application Auto Scaling Um prädiktive Skalierung zu verwenden, erstellen Sie eine Richtlinie für prädiktive Skalierung, die die zu überwachende und zu analysierende CloudWatch Metrik festlegt. Sie können eine vordefinierte Metrik oder eine benutzerdefinierte Metrik verwenden. Damit die prädiktive Skalierung mit der Prognose future Werte beginnen kann, muss diese Metrik Daten für mindestens 24 Stunden enthalten. Nachdem Sie die Richtlinie erstellt haben, beginnt die prädiktive Skalierung mit der Analyse von Metrikdaten der letzten 14 Tage, um Muster zu identifizieren. Anhand dieser Analyse wird eine stündliche Prognose des Kapazitätsbedarfs für die nächsten 48 Stunden erstellt. Die Prognose wird alle 6 Stunden anhand der neuesten CloudWatch Daten aktualisiert. Wenn neue Daten eintreffen, kann die prädiktive Skalierung die Genauigkeit zukünftiger Prognosen kontinuierlich verbessern. Sie können die prädiktive Skalierung zunächst *nur im Prognosemodus* aktivieren. In diesem Modus werden Kapazitätsprognosen generiert, Ihre Kapazität wird jedoch nicht auf der Grundlage dieser Prognosen skaliert. Auf diese Weise können Sie die Genauigkeit und Eignung der Prognose bewerten. Nachdem Sie die Prognosedaten überprüft und beschlossen haben, mit der Skalierung auf der Grundlage dieser Daten zu beginnen, schalten Sie die Skalierungsrichtlinie in den Prognose- und Skalierungsmodus um. In diesem Modus: + Wenn in der Prognose ein Anstieg der Last erwartet wird, wird durch vorausschauende Skalierung die Kapazität erhöht. + Wenn in der Prognose ein Rückgang der Auslastung erwartet wird, wird die vorausschauende Skalierung nicht so skaliert, dass Kapazität abgebaut wird. Dadurch wird sichergestellt, dass Sie nur dann skalieren, wenn die Nachfrage tatsächlich sinkt, und nicht nur aufgrund von Prognosen. Um Kapazität zu entfernen, die nicht mehr benötigt wird, müssen Sie eine Target Tracking- oder Step Scaling-Richtlinie erstellen, da diese auf Metrikdaten in Echtzeit reagieren. Standardmäßig skaliert Predictive Scaling Ihre skalierbaren Ziele zu Beginn jeder Stunde auf der Grundlage der Prognose für diese Stunde. Sie können optional eine frühere Startzeit angeben, indem Sie die `SchedulingBufferTime` Eigenschaft im `PutScalingPolicy` API-Vorgang verwenden. Auf diese Weise können Sie die prognostizierte Kapazität vor dem prognostizierten Bedarf in Betrieb nehmen, sodass die neue Kapazität ausreichend Zeit hat, um den Verkehr abzuwickeln. ## Maximale Kapazitätsgrenze Standardmäßig können Skalierungsrichtlinien die Kapazität nicht über die maximale Kapazität hinaus erhöhen. Alternativ können Sie zulassen, dass die maximale Kapazität des skalierbaren Ziels automatisch erhöht wird, wenn sich die prognostizierte Kapazität der maximalen Kapazität des skalierbaren Ziels nähert oder diese überschreitet. Um dieses Verhalten zu aktivieren, verwenden Sie die `MaxCapacityBuffer` Eigenschaften `MaxCapacityBreachBehavior` und im `PutScalingPolicy` API-Vorgang oder die Einstellung für das **Verhalten „Max. Kapazität**“ in AWS-Managementkonsole. **Warnung** Seien Sie vorsichtig, wenn Sie zulassen, dass die maximale Kapazität automatisch erhöht wird. Die maximale Kapazität wird nicht automatisch auf das ursprüngliche Maximum zurückgesetzt. ## Häufig verwendete Befehle zur Erstellung, Verwaltung und Löschung von Skalierungsrichtlinien Zu den häufig verwendeten Befehlen für die Arbeit mit Richtlinien zur vorausschauenden Skalierung gehören: + `register-scalable-target`um Ressourcen als skalierbare Ziele zu registrieren AWS oder anzupassen, die Skalierung auszusetzen und die Skalierung wieder aufzunehmen. + `put-scaling-policy`um eine prädiktive Skalierungsrichtlinie zu erstellen. + `get-predictive-scaling-forecast`um die Prognosedaten für eine prädiktive Skalierungsrichtlinie abzurufen. + `describe-scaling-activities`um Informationen über Skalierungsaktivitäten in einem AWS-Region zurückzugeben. + `describe-scaling-policies`um Informationen über Skalierungsrichtlinien in einem zurückzugeben AWS-Region. + `delete-scaling-policy`um eine Skalierungsrichtlinie zu löschen. **Benutzerdefinierte Metriken** Benutzerdefinierte Metriken können verwendet werden, um die für eine Anwendung benötigte Kapazität vorherzusagen. Benutzerdefinierte Metriken sind nützlich, wenn vordefinierte Metriken nicht ausreichen, um die Auslastung Ihrer Anwendung zu erfassen. ## Überlegungen Die folgenden Überlegungen gelten für die Arbeit mit prädiktiver Skalierung. + Prüfen Sie, ob Predictive Scaling für Ihre Anwendung geeignet ist. Eine Anwendung eignet sich gut für die prädiktive Skalierung, wenn sie wiederkehrende Lastmuster aufweist, die für den Wochentag oder die Tageszeit spezifisch sind. Evaluieren Sie die Prognose, bevor Sie Predictive Scaling Ihre Anwendung aktiv skalieren lassen. + Für die prädiktive Skalierung werden mindestens 24 Stunden an historischen Daten benötigt, damit mit der Prognose begonnen werden kann. Prognosen sind jedoch effektiver, wenn Verlaufsdaten für zwei volle Wochen zur Verfügung stehen. + 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. # Erstellen Sie eine Richtlinie zur vorausschauenden Skalierung für Application Auto Scaling Die folgende Beispielrichtlinie verwendet die AWS CLI , um eine prädiktive Skalierungsrichtlinie für den 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.* 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 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": [] } ``` # Überschreiben von Prognosewerten mithilfe geplanter Aktionen 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 Kapazität unterschätzen, die für eine bevorstehende Marketingveranstaltung 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 Mindestkapazität als die prognostizierte Aktion erstellen. Zur Laufzeit aktualisiert Application Auto Scaling die Mindestkapazität Ihres skalierbaren Ziels. Da die prädiktive Skalierung für die Kapazität optimiert wird, wird eine geplante Aktion mit einer minimalen Kapazität, die höher als die Prognosewerte ist, berücksichtigt. Dadurch wird verhindert, dass die Kapazität geringer ist als erwartet. Um das Überschreiben der Prognose zu beenden, setzen Sie über eine zweite geplante Aktion die minimale Kapazität 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 Kapazität vorübergehend verringern müssen, ohne dass dies durch eine Richtlinie zur vorausschauenden Skalierung beeinträchtigt wird, verwenden Sie stattdessen den Modus „*Nur Prognose*“. Im Modus „Nur Prognose“ generiert die vorausschauende Skalierung zwar weiterhin Prognosen, erhöht aber nicht automatisch die Kapazität. Anschließend können Sie die Ressourcennutzung überwachen und die Größe Ihrer Gruppe 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. Verwenden Sie den [get-predictive-scaling-forecast](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/application-autoscaling/get-predictive-scaling-forecast.html)Befehl, um die Prognose abzurufen. Im folgenden Beispiel wird die Prognose für die vorausschauende Skalierung für den Amazon ECS-Service abgerufen. ``` aws application-autoscaling get-predictive-scaling-forecast --service-namespace ecs \ --scalable-dimension ecs:service:DesiredCount \ --resource-id 1234567890abcdef0 --policy-name predictive-scaling-policy \ --start-time "2021-05-19T17:00:00Z" \ --end-time "2021-05-19T23:00:00Z" ``` Die Antwort umfasst zwei Prognosen: `LoadForecast` und`CapacityForecast`. `LoadForecast`zeigt die stündliche Lastprognose. `CapacityForecast`zeigt Prognosewerte für die Kapazität, die stündlich benötigt wird, um die prognostizierte Last unter Beibehaltung einer bestimmten `TargetValue` Last zu bewältigen. 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. **Erstellen von zwei geplanten Aktionen für einmalige Ereignisse (AWS CLI)** Verwenden Sie den [ put-scheduled-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/application-autoscaling/put-scheduled-action.html)Befehl, um die geplanten Aktionen zu erstellen. Das folgende Beispiel definiert einen Zeitplan für Amazon EC2 Auto Scaling, der acht Stunden lang eine Mindestkapazität von drei Instances am 19. Mai um 17:00 Uhr vorsieht. 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 ``` # Erweiterte prädiktive Skalierungsrichtlinie unter Verwendung benutzerdefinierter Metriken In einer prädiktiven Skalierungsrichtlinie können Sie vordefinierte oder benutzerdefinierte Metriken verwenden. Benutzerdefinierte Metriken sind nützlich, wenn die vordefinierten Metriken die Auslastung Ihrer Anwendung nicht ausreichend beschreiben. Wenn Sie eine Richtlinie zur vorausschauenden Skalierung mit benutzerdefinierten Metriken erstellen, können Sie andere CloudWatch Metriken angeben, die von bereitgestellt werden AWS, oder Sie können 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 Werte in Ihren Daten kombinieren, indem Sie z.B. 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. **Topics** + [Best Practices](#custom-metrics-best-practices) + [Voraussetzungen](#custom-metrics-prerequisites) + [Konstruieren von JSON für benutzerdefinierte Metriken](construct-json-custom-metrics.md) + [Überlegungen zu benutzerdefinierten Metriken in einer Richtlinie zur prädiktiven Skalierung](custom-metrics-troubleshooting.md) ## Best Practices Die folgenden bewährten Methoden können Ihnen helfen, benutzerdefinierte Metriken effektiver zu nutzen: + Für die Lastmetrikspezifikation ist die nützlichste Metrik eine Metrik, die die Auslastung Ihrer Anwendung darstellt. + Die Skalierungsmetrik muss umgekehrt proportional zur Kapazität sein. Das heißt, wenn das skalierbare Ziel zunimmt, sollte sich die Skalierungsmetrik ungefähr im gleichen Verhältnis verringern. Um sicherzustellen, dass sich die prädiktive Skalierung wie erwartet verhält, müssen die Lastmetrik und die Skalierungsmetrik auch stark miteinander korrelieren. + Die Zielauslastung muss mit der Art der Skalierungsmetrik übereinstimmen. Bei einer Richtlinienkonfiguration, die die CPU-Auslastung verwendet, ist dies ein Zielprozentsatz. Bei einer Richtlinienkonfiguration, die den Durchsatz verwendet, wie z.B. die Anzahl der Anfragen oder Nachrichten, ist dies die angestrebte Anzahl von Anfragen oder Nachrichten pro Instance während eines einminütigen Intervalls. + 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 sich die prognostizierten Werte ansehen. Sie können auch nach der Erstellung Ihrer Richtlinie für vorausschauende Skalierung die `CapacityForecast` Objekte `LoadForecast` und überprüfen, die [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html)durch einen API-Aufruf zurückgegeben wurden. + 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 der Kapazität beginnt. ## 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 Metriken anstelle der bereitgestellten Metriken angeben möchten, müssen Sie Ihre Metriken zunächst auf CloudWatch veröffentlichen. 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. Application Auto Scaling ruft die Datenpunkte CloudWatch basierend auf der Länge des benötigten Zeitraums ab. Beispielsweise verwendet die Lastmetrikspezifikation stündliche Metriken, 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. # Konstruieren von JSON für benutzerdefinierte Metriken Der folgende Abschnitt enthält Beispiele für die Konfiguration von Predictive Scaling zur Abfrage von Daten CloudWatch für Amazon EC2 Auto Scaling. 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 Sie unter. [Beispiel einer prädiktiven Skalierungsrichtlinie mit benutzerdefinierten Last- und Skalierungsmetriken (AWS CLI)](#custom-metrics-ex1) 1. Informationen zum Erstellen einer Richtlinie, mit der mehrere CloudWatch Messwerte abgefragt und mithilfe mathematischer Ausdrücke neue Zeitreihen auf der Grundlage dieser Messwerte erstellt werden können, finden Sie unter[Metrikberechnungs-Ausdrücke verwenden](using-math-expression-examples.md). ## Beispiel einer prädiktiven Skalierungsrichtlinie mit benutzerdefinierten Last- und Skalierungsmetriken (AWS CLI) Um eine prädiktive Skalierungsrichtlinie 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://awscli.amazonaws.com/v2/documentation/api/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 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 und Beispiele für Richtlinien zur vorausschauenden Skalierung, die zeigen, wie Sie metrische Berechnungen in Ihrer Richtlinie verwenden können. **Topics** + [Metrikberechnung verstehen](#custom-metrics-metric-math) + [Beispiel für eine prädiktive Skalierungsrichtlinie für Amazon EC2 Auto Scaling, die Metriken mithilfe von Metric Math () kombiniert AWS CLI](#custom-metrics-ex2) + [Beispiel für eine Richtlinie zur vorausschauenden Skalierung zur Verwendung in einem blue/green Bereitstellungsszenario ()AWS CLI](#custom-metrics-ex3) ## 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 Rechenoperationen verwenden die Datenpunkte der eindeutigen Kombination aus Metrikname, Namespace und Dimensionsschlüssel/Wertpaaren 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 CloudWatch Funktion unterstützt. + 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 Skalierungsrichtlinie für Amazon EC2 Auto Scaling, die Metriken mithilfe von Metric Math () 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 autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json { "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": [] } ``` ## Beispiel für eine Richtlinie zur vorausschauenden Skalierung zur Verwendung in einem blue/green Bereitstellungsszenario ()AWS CLI Ein Suchausdruck bietet eine erweiterte Option, mit der Sie eine Metrik aus mehreren Auto-Scaling-Gruppen abfragen und mathematische Ausdrücke auf sie anwenden können. Dies ist besonders nützlich für blue/green Bereitstellungen. **Anmerkung** Eine *blau/grüne Bereitstellung* ist eine Bereitstellungsmethode, bei der Sie zwei separate, aber identische Auto-Scaling-Gruppen erstellen. Nur eine der Gruppen empfängt den Produktionsverkehr. Der Benutzerverkehr wird zunächst auf die frühere ("blaue") Auto-Scaling-Gruppe geleitet, während eine neue Gruppe („grün“) zum Testen und Evaluieren einer neuen Version einer Anwendung oder eines Dienstes verwendet wird. Der Benutzerverkehr wird auf die grüne Auto-Scaling-Gruppe verlagert, nachdem eine neue Bereitstellung getestet und akzeptiert wurde. Sie können die blaue Gruppe dann löschen, nachdem die Bereitstellung erfolgreich war. Wenn im Rahmen einer blue/green Bereitstellung neue Auto Scaling Scaling-Gruppen erstellt werden, kann der Metrikverlauf jeder Gruppe automatisch in die Predictive Scaling-Richtlinie aufgenommen werden, ohne dass Sie die Metrikspezifikationen ändern müssen. Weitere Informationen finden Sie im Compute-Blog unter [Verwenden von Richtlinien zur vorausschauenden Skalierung von EC2 Auto Scaling mit Blue/Green-Bereitstellungen](https://aws.amazon.com/blogs/compute/retaining-metrics-across-blue-green-deployment-for-predictive-scaling/). AWS Die folgende Beispielrichtlinie zeigt, wie dies geschehen kann. In diesem Beispiel verwendet die Richtlinie die von Amazon EC2 ausgegebene `CPUUtilization`-Metrik. Es verwendet die Amazon EC2 Auto Scaling `GroupInServiceInstances`-Metrik und einen mathematischen Ausdruck, um den Wert der Skalierungsmetrik pro Instance zu berechnen. Sie gibt auch eine Kapazitätsmetrik an, um die `GroupInServiceInstances`-Metrik zu erhalten. Der Suchausdruck findet das `CPUUtilization` von Instances in mehreren Auto-Scaling-Gruppen anhand der angegebenen Suchkriterien. Wenn Sie zu einem späteren Zeitpunkt eine neue Auto-Scaling-Gruppe erstellen, die denselben Suchkriterien entspricht, werden die `CPUUtilization` der Instances in der neuen Auto-Scaling-Gruppe automatisch einbezogen. ``` aws autoscaling put-scaling-policy --policy-name my-blue-green-predictive-scaling-policy \ --auto-scaling-group-name my-asg --policy-type PredictiveScaling \ --predictive-scaling-configuration file://config.json { "MetricSpecifications": [ { "TargetValue": 25, "CustomizedScalingMetricSpecification": { "MetricDataQueries": [ { "Id": "load_sum", "Expression": "SUM(SEARCH('{AWS/EC2,AutoScalingGroupName} MetricName=\"CPUUtilization\" ASG-myapp', 'Sum', 300))", "ReturnData": false }, { "Id": "capacity_sum", "Expression": "SUM(SEARCH('{AWS/AutoScaling,AutoScalingGroupName} MetricName=\"GroupInServiceInstances\" ASG-myapp', 'Average', 300))", "ReturnData": false }, { "Id": "weighted_average", "Expression": "load_sum / capacity_sum", "ReturnData": true } ] }, "CustomizedLoadMetricSpecification": { "MetricDataQueries": [ { "Id": "load_sum", "Expression": "SUM(SEARCH('{AWS/EC2,AutoScalingGroupName} MetricName=\"CPUUtilization\" ASG-myapp', 'Sum', 3600))" } ] }, "CustomizedCapacityMetricSpecification": { "MetricDataQueries": [ { "Id": "capacity_sum", "Expression": "SUM(SEARCH('{AWS/AutoScaling,AutoScalingGroupName} MetricName=\"GroupInServiceInstances\" ASG-myapp', 'Average', 300))" } ] } } ] } ``` 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-blue-green-predictive-scaling-policy", "Alarms": [] } ``` # Überlegungen zu benutzerdefinierten Metriken in einer Richtlinie zur prädiktiven Skalierung Wenn bei der Verwendung von benutzerdefinierten Metriken ein Problem auftritt, empfehlen wir Ihnen, wie folgt vorzugehen: + Wenn eine Fehlermeldung angezeigt wird, lesen Sie die Nachricht und beheben Sie das gemeldete Problem, falls möglich. + Wenn Sie einen Ausdruck nicht im Voraus validiert haben, validiert der [ put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/application-autoscaling/put-scaling-policy.html)Befehl ihn, 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 an den [get-metric-data](https://awscli.amazonaws.com/v2/documentation/api/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. **Einschränkungen** Die folgenden Einschränkungen gelten: + 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.