• Das AWS Systems Manager CloudWatch Dashboard wird nach dem 30. April 2026 nicht mehr verfügbar sein. Kunden können die CloudWatch Amazon-Konsole weiterhin verwenden, um ihre CloudWatch Amazon-Dashboards anzuzeigen, zu erstellen und zu verwalten, so wie sie es heute tun. Weitere Informationen finden Sie in der Amazon CloudWatch Dashboard-Dokumentation.
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.
Verwalten Parameter Store Durchsatz
Parameter StoreDer Durchsatz definiert die Anzahl der API-Transaktionen pro Sekunde (TPS), die Systems Manager verarbeiten kann. Die Durchsatzeinstellung gilt für die Parameter Store gesamte API und nicht für eine einzelne API. Parameter StoreIst standardmäßig mit einem Standarddurchsatzkontingent konfiguriert, das häufig für Workloads mit geringem bis mittlerem Volumen geeignet ist. Für Workloads mit höherem Volumen können Sie einen höheren Durchsatz aktivieren, wodurch sich die maximale Anzahl unterstützter Transaktionen pro Sekunde für Ihr Konto und Ihre Region erhöht. Sie können bei Bedarf einen höheren Durchsatz aktivieren und deaktivieren.
Durchsatzquoten in Parameter Store
In der folgenden Tabelle sind die Transaktionslimits für verschiedene API-Kategorien mit Standarddurchsatz und höherem Durchsatz aufgeführt. Zu den API-Aktionen gehören die Nutzung der AWS Konsole, AWS CLI Befehle und Lesevorgänge von Anwendungen. Weitere Informationen zu Kontingenten und Ratenbeschränkungen finden Sie unter AWS Systems Manager Endpunkte und Kontingente.
| API-Aktionen | Standarddurchsatz | Höherer Durchsatz |
|---|---|---|
| GetParameter, GetParameters und GetParametersByPath | 40 TPSwird für alle drei API-Aktionen zusammen verwendet |
GetParameter: 10,000 TPS;
GetParameters: 1,000 TPS;
GetParametersByPath: 100 TPS
|
| DeleteParameter und DeleteParameters | 3 TPS |
5 TPS |
| DescribeParameters, GetParameterHistory, LabelParameterVersion, UnlabelParameterVersion, und PutParameter | 3 TPS |
10 TPS |
In diesem Zusammenhang ist eine Transaktion eine API-Aktion für ein Konto in einer einzigen Region. Mit dem folgenden Befehl wird beispielsweise eine einzelne Transaktion erstellt.
aws ssm get-parameter --name "/myapp/prod/log-level"
Die API-Aktionen können auf Anwendungen verteilt werden. Beispielsweise erreicht jedes der folgenden Szenarien die Standarddurchsatzgrenze von 40 TPS:
-
Eine Anwendung tätigt 40
GetParameterAufrufe pro Sekunde. -
10 Anwendungen tätigen 4
GetParameterAufrufe pro Sekunde. -
40 Anwendungen tätigen einen
GetParameterAnruf pro Sekunde.
Ein Durchsatzlimit gilt für alle APIs innerhalb einer Kategorie. Beispielsweise erfüllt die folgende Kombination gleichzeitiger Parameteraufrufe für eine Anwendung das Standardlimit von 40 TPS für APIs zum Abrufen von Parametern:
-
GetParameterführt 25 Aufrufe pro Sekunde durch. -
GetParameterstätigt 10 Anrufe pro Sekunde. -
GetParameterByPathtätigt 5 Anrufe pro Sekunde.
Die DescribeParameters Anrufe haben ein separates Durchsatzlimit. Eine Anwendung kann die vorhergehenden Aufrufe tätigen und gleichzeitig 3 DescribeParameters Aufrufe pro Sekunde tätigen, ohne das Gesamtlimit für den Standarddurchsatz zu überschreiten.
Wenn Ihre Produktionsanforderungen während des Standardbetriebs oder in geplanten Perioden mit hohem Datenverkehr eine Durchsatzgrenze überschreiten, verwenden Sie die folgenden Optimierungstechniken.
Themen
Optimierung des Durchsatzes in Parameter Store
Wenn Parameter Store in einem kurzen Intervall mehrere Parameteranforderungen eingehen, kann es bei Ihrer Anwendung zu einer Drosselung kommen. Beispielsweise werden in den CloudWatch Protokollen oder Ihren Anwendungsprotokollen RateExceeded Fehler angezeigt, die vom SDK ausgelöst werden, wenn es aufgerufen wird GetParameterGetParameters, ThrottlingException oder. GetParametersByPath In anderen Fällen versucht die Anwendungslogik erfolgreich API-Aufrufe erneut, aber die Anwendungslatenz steigt. Das Ergebnis können Anwendungsausfälle, eine suboptimale Benutzererfahrung, fehlgeschlagene Bereitstellungen, komplexe Problemumgehungen und verlorene Entwicklerzeit sein.
Mehrere Faktoren können dazu führen, dass Ihre Anwendung die Parameter Store Kontingentgrenzen erreicht, darunter die folgenden:
-
Ihre Anwendung skaliert aufgrund eines Anstiegs des Datenverkehrs schnell. Ihre Anwendung läuft beispielsweise normalerweise auf 5 Amazon EC2-Instances. Wenn der Datenverkehr plötzlich zunimmt, startet Amazon EC2 Auto Scaling 50 weitere Instances. Wenn jede Instance beim Start Parameter liest, können die kombinierten Anfragen das Standard-Anforderungslimit überschreiten.
-
Ihr Container-Service startet viele Aufgaben gleichzeitig. Beispielsweise kann ein Amazon ECS-Service während eines Updates viele Ersatzaufgaben starten, und jede Aufgabe liest möglicherweise Einstellungen aus, Parameter Store wenn sie gestartet wird.
-
Ihre Lambda-Funktionen erhalten viele Anfragen gleichzeitig. Beispielsweise könnte Lambda viele Funktionsumgebungen starten, um den erhöhten Datenverkehr zu bewältigen. Jede Funktionsumgebung liest möglicherweise Parameter, wenn sie gestartet wird.
-
Ihr Build- oder Release-Prozess liest viele Parameter in einem kurzen Zeitintervall. Beispielsweise kann ein Build-Job Einstellungen für mehrere Anwendungen oder Umgebungen lesen.
-
Ihre Anwendung liest viele Parameter anhand des Pfads. Beispielsweise liest Ihre Anwendung wiederholt alle Parameter unter,
/myapp/prod/anstatt nur die spezifischen Parameter zu lesen, die sie benötigt. Diese wiederholten Anfragen können das Standardanforderungslimit überschreiten.
Sie können der Parameter Store Drosselung auf folgende ergänzende Arten begegnen:
-
Reduzierung des Durchsatzes
Ihre Anwendung ruft möglicherweise mehr Daten ab, als sie benötigt, oder ruft sie auf ineffiziente Weise ab.
-
Ermöglicht einen höheren Durchsatz
Sie können die Ausfallsicherheit von Anwendungen erhöhen, indem Sie das Durchsatzkontingent für eine bestimmte Region und ein bestimmtes Konto erhöhen. Sie können die Einstellung für einen höheren Durchsatz jederzeit für Zeiten mit hohem Datenverkehr aktivieren und deaktivieren. Bei Produktions-Workloads, bei denen regelmäßig Drosselungsfehler auftreten, sollten Sie erwägen, die Einstellung dauerhaft zu aktivieren.
Reduzierung des Durchsatzes in Parameter Store
Unabhängig davon, ob Sie den Standarddurchsatz oder einen höheren Durchsatz verwenden, überprüfen Sie die Häufigkeit und Art der Anrufe anParameter Store. In einigen Fällen können Sie die Anzahl der Anfragen reduzieren, ohne Ihre Parameter zu ändern. Da die Kosten auf der Grundlage der Nutzung und nicht anhand eines Abonnement- oder Stufenmodells bestimmt werden, sind das Ergebnis weniger fakturierte API-Interaktionen.
-
Zwischenspeichern Sie Parameterwerte in Ihrer Anwendung, anstatt bei jeder Anfrage dieselben Werte zu lesen.
Wenn Ihre Anwendung beispielsweise
/myapp/prod/log-levelviele Male pro Minute liest, kann die Anwendung den Wert einmal lesen und ihn für einen kurzen Zeitraum wiederverwenden. Diese Technik reduziert wiederholte Aufrufe vonParameter Store. Wählen Sie einen kürzeren Wiederverwendungszeitraum für Werte, die sich häufig ändern, und einen längeren Wiederverwendungszeitraum für Werte, die sich selten ändern. -
Verwenden Sie diese Option, GetParameters wenn Sie die Namen mehrerer Parameter kennen.
Anstatt beispielsweise separate GetParameter Aufrufe für die Parameter
/myapp/prod/database/host, und/myapp/prod/vendor/merchant-idzu tätigen/myapp/prod/log-level, können Sie eine Liste dieser Parameter in einer einzigenGetParametersAnforderung abrufen. -
Vermeiden Sie es, mehr Parameter zu lesen, als Ihre Anwendung benötigt.
Wenn Ihre Anwendung nur wenige bekannte Parameter benötigt, verwenden Sie
GetParameteroder,GetParametersanstatt wiederholt einen ganzen Pfad zu lesen, z./myapp/prod/B. Verwenden Sie diese Option, GetParametersByPath wenn Ihre Anwendung eine Gruppe von Parametern unter einem Pfad benötigt. Wenn Sie einen höheren Durchsatz verwenden, beträgt dasGetParameterKontingent das 100-fache des Kontingents fürGetParametersByPath. -
Der Spread-Out-Parameter wird gelesen, wenn viele Ressourcen gleichzeitig gestartet werden.
Wenn beispielsweise viele Amazon EC2-Instances oder Amazon ECS-Aufgaben während eines Updates gestartet werden, sollten Sie vermeiden, dass alle Ressourcen die Parameter exakt zur gleichen Zeit lesen. Die Kontingente gelten pro Sekunde. Wenn möglich, lesen Sie die Parameter einmal und speichern Sie ihre Werte in der Anwendung, oder fügen Sie eine kleine Verzögerung hinzu, damit nicht alle Anfragen in derselben Sekunde erfolgen.
-
Erwägen Sie für Lambda-Funktionen die Verwendung der AWS Lambda-Erweiterung Parameters and Secrets.
Die Erweiterung kann Parameterwerte lokal zur Wiederverwendung durch die Funktion speichern. Diese Technik kann die Anzahl der Aufrufe von Parameterwerten reduzieren Parameter Store und auch die Zeit reduzieren, die zum Abrufen von Parameterwerten benötigt wird. Ein Beispiel für diese Technik finden Sie unter Verwenden der Lambda-Erweiterung AWS „Parameter und Secrets“ zum Zwischenspeichern von Parametern und Geheimnissen.
Erhöhen des -Durchsatzes
Für Workloads mit höherem Volumen können Sie einen höheren Durchsatz aktivieren. Diese Einstellung erhöht die maximale Anzahl unterstützter Transaktionen pro Sekunde für Ihr Konto und Ihre Region gegen eine Gebühr. Ziehen Sie in den folgenden Szenarien einen höheren Durchsatz in Betracht:
-
Ihre Anwendung benötigt vorübergehend einen höheren Durchsatz.
Beispielsweise könnte ein Webstore während eines Wochenendverkaufs häufiger Parameter lesen. Sie können vor Verkaufsbeginn einen höheren Durchsatz aktivieren und nach Angebotsende zum Standarddurchsatz zurückkehren. Sie können einen höheren Durchsatz jederzeit auf der Seite Parameter Store „Einstellungen“ aktivieren oder deaktivieren, indem Sie die verwenden AWS CLI.
-
Ihre Produktionsanwendung ruft regelmäßig Parameter gleichzeitig ab und es treten Drosselungsprobleme auf.
Gleichzeitiges Abrufen kann auftreten, wenn mehrere Instanzen, Container, Funktionen oder Build-Jobs gleichzeitig Parameter lesen. Parameter Store Beispiele sind unter anderem:
-
Ihre Anwendung skaliert schnell. Ihre Anwendung wird beispielsweise normalerweise auf 5 Amazon EC2-Instances ausgeführt. Wenn der Datenverkehr plötzlich zunimmt, startet Amazon EC2 Auto Scaling 50 weitere Instances. Wenn jede Instance beim Start Parameter liest, können die kombinierten Anfragen das Standard-Anforderungslimit überschreiten.
-
Ihr Container-Service startet viele Aufgaben gleichzeitig. Beispielsweise kann ein Amazon ECS-Service während eines Updates viele Ersatzaufgaben starten, und jede Aufgabe liest möglicherweise Einstellungen aus, Parameter Store wenn sie gestartet wird.
-
Ihre Lambda-Funktionen erhalten viele Anfragen gleichzeitig. Beispielsweise könnte Lambda viele Funktionsumgebungen starten, um den erhöhten Datenverkehr zu bewältigen. Jede Funktionsumgebung liest möglicherweise Parameter, wenn sie gestartet wird.
-
Ihr Build- oder Release-Prozess liest viele Parameter in einem kurzen Zeitintervall. Beispielsweise kann ein Build-Job Einstellungen für mehrere Anwendungen oder Umgebungen lesen.
-
Überlegungen zu den Kosten für einen höheren Durchsatz
Für die Option mit höherem Durchsatz fallen zusätzliche Gebühren an. Aktuelle Parameter Store API-Preise und Beispiele finden Sie unter AWS Systems Manager-Preise
Die Gebühren basieren auf Parameter Store API-Interaktionen. Eine API-Interaktion ist als eine Interaktion zwischen einer API-Anfrage und einem einzelnen Parameter definiert. Wenn eine einzelne GetParameter Anfrage beispielsweise 10 Parameter zurückgibt, zählt diese Anforderung zu Abrechnungszwecken als 10 Parameter Store API-Interaktionen.
Stellen Sie sich ein Szenario vor, in dem Sie für einen kurzen Zeitraum mit erhöhtem Traffic zu einem höheren Durchsatz wechseln möchten. Ihr Webstore veranstaltet einen Wochenendverkauf und führt während des Verkaufs 1,000,000 Parameter Store API-Interaktionen durch. Wenn die Kosten für einen höheren Durchsatz in diesem Beispiel $0.05 pro 10,000 API-Interaktion anfallen, belaufen sich die zusätzlichen Gesamtkosten auf ungefähr$5. Sie können am Ende des Verkaufs wieder zum Standarddurchsatz wechseln und keine weiteren Kosten mehr anfallen.
Kombination von Durchsatz- und Parameterstufen
Der Durchsatz funktioniert unabhängig von den Parameterebenen. Während Parameterebenen die Speichergrenzen und die Verfügbarkeit von Funktionen steuern, steuern die Durchsatzeinstellungen das Anforderungsvolumen. Um die Leistungs- und Skalierungsanforderungen zu erfüllen, können Sie Stufen und Durchsatz zusammen verwenden.
Um beispielsweise einfache Anwendungen und Anwendungen mit geringer Auslastung zu unterstützen, können Sie Standardparameter mit Standarddurchsatz verwenden. Zur Unterstützung umfangreicher, hochfrequenter Zugriffsmuster können Sie erweiterte Parameter mit höherem Durchsatz kombinieren. Im Allgemeinen ist eine Erhöhung des Durchsatzes erforderlich, wenn Ihre Anwendung die TPS-Standardgrenzwerte überschreitet (z. B. bei mehreren gleichzeitigen Lese- oder Schreibvorgängen), unabhängig davon, welche Parameterebene Sie verwenden.
Weitere Informationen zum maximalen Durchsatz und zu anderen Parameter Store Kontingenten finden Sie unter AWS Systems Manager Endpunkte und Kontingente.
Änderung der Durchsatzeinstellung in Parameter Store
In den folgenden Verfahren wird beschrieben, wie Sie mit Systems Manager die Anzahl der Transaktionen pro Sekunde ändern, die für das aktuelle AWS-Konto UND verarbeitet werden Parameter Store können AWS-Region. Sie können die Einstellung jederzeit ändern.
