• La AWS Systems Manager CloudWatch dashboard non sarà più disponibile dopo il 30 aprile 2026. I clienti possono continuare a utilizzare la CloudWatch console Amazon per visualizzare, creare e gestire le proprie CloudWatch dashboard Amazon, proprio come fanno oggi. Per ulteriori informazioni, consulta la documentazione di Amazon CloudWatch Dashboard.
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Gestione Parameter Store velocità di trasmissione effettiva
Parameter Storeil throughput definisce il numero di transazioni API al secondo (TPS) che Systems Manager è in grado di elaborare. L'impostazione del throughput si applica all'API nel Parameter Store suo insieme anziché a una singola API. Per impostazione predefinita, Parameter Store è configurata con una quota di throughput standard che è spesso adatta per carichi di lavoro di volume da basso a moderato. Per carichi di lavoro con volumi più elevati, puoi abilitare un throughput più elevato, il che aumenta il numero massimo di transazioni supportate al secondo per il tuo account e la tua regione. Puoi abilitare e disabilitare un throughput più elevato in base alle esigenze.
Quote di produttività in Parameter Store
La tabella seguente elenca i limiti di transazione per diverse categorie di API utilizzando un throughput predefinito e superiore. Le azioni API includono l'utilizzo AWS della console, AWS CLI i comandi e le letture delle applicazioni. Per ulteriori informazioni sulle quote e sui limiti di velocità, consulta AWS Systems Manager Endpoints and quotas.
| Operazioni dell'API | Velocità di trasmissione effettiva predefinita | Velocità di trasmissione effettiva più alta |
|---|---|---|
| GetParameter, GetParameters e GetParametersByPath | 40 TPScondiviso tra tutte e tre le azioni API combinate |
GetParameter: 10,000 TPS;
GetParameters: 1,000 TPS;
GetParametersByPath: 100 TPS
|
| DeleteParameter e DeleteParameters | 3 TPS |
5 TPS |
| DescribeParameters, GetParameterHistory, LabelParameterVersion, UnlabelParameterVersion, e PutParameter | 3 TPS |
10 TPS |
In questo contesto, una transazione è un'azione API per un account in una singola regione. Ad esempio, il comando seguente crea una singola transazione.
aws ssm get-parameter --name "/myapp/prod/log-level"
Le azioni API possono essere distribuite tra le applicazioni. Ad esempio, ciascuno dei seguenti scenari raggiunge il limite di throughput predefinito di 40 TPS:
-
1 applicazione effettua 40
GetParameterchiamate al secondo. -
10 applicazioni effettuano 4
GetParameterchiamate al secondo. -
40 applicazioni
GetParametereffettuano 1 chiamata al secondo.
Un limite di velocità effettiva si applica a tutte le API all'interno di una categoria. Ad esempio, la seguente combinazione di chiamate simultanee di parametri per un'applicazione soddisfa il limite predefinito di 40 TPS per le API di recupero dei parametri:
-
GetParametereffettua 25 chiamate al secondo. -
GetParameterseffettua 10 chiamate al secondo. -
GetParameterByPatheffettua 5 chiamate al secondo.
Le DescribeParameters chiamate hanno un limite di throughput separato. Un'applicazione può effettuare le chiamate precedenti effettuando anche 3 DescribeParameters chiamate al secondo senza superare il limite complessivo per la velocità effettiva standard.
Se le richieste di produzione superano un limite di produttività durante il funzionamento standard o nei periodi pianificati di traffico elevato, utilizzate le seguenti tecniche di ottimizzazione.
Argomenti
Ottimizzazione della produttività in Parameter Store
Quando Parameter Store riceve più richieste di parametri in un breve intervallo, l'applicazione può subire delle limitazioni. Ad esempio, CloudWatch i log o i log dell'applicazione mostrano RateExceeded gli errori generati dall'SDK quando chiamaGetParameter,, ThrottlingException GetParameters o. GetParametersByPath In altri casi, la logica applicativa riprova con successo le chiamate API, ma la latenza dell'applicazione aumenta. Il risultato può essere interruzioni delle applicazioni, esperienza utente non ottimale, implementazioni non riuscite, soluzioni alternative complesse e perdita di tempo per gli sviluppatori.
Diversi fattori possono far sì che l'applicazione raggiunga i limiti di quota, tra cui: Parameter Store
-
L'applicazione si espande rapidamente a causa di un picco di traffico. Ad esempio, l'applicazione viene normalmente eseguita su 5 istanze Amazon EC2. Quando il traffico aumenta improvvisamente, Amazon EC2 Auto Scaling lancia altre 50 istanze. Se ogni istanza legge i parametri all'avvio, le richieste combinate possono superare il limite di richieste predefinito.
-
Il tuo servizio container avvia molte attività contemporaneamente. Ad esempio, un servizio Amazon ECS potrebbe avviare molte attività sostitutive durante un aggiornamento e ciascuna attività potrebbe leggere le impostazioni dal Parameter Store momento dell'avvio.
-
Le tue funzioni Lambda ricevono molte richieste contemporaneamente. Ad esempio, Lambda potrebbe avviare molti ambienti funzionali per gestire l'aumento del traffico. Ogni ambiente funzionale potrebbe leggere i parametri all'avvio.
-
Il processo di compilazione o rilascio legge molti parametri in un breve intervallo di tempo. Ad esempio, un processo di compilazione potrebbe leggere le impostazioni per diverse applicazioni o ambienti.
-
L'applicazione legge molti parametri in base al percorso. Ad esempio, l'applicazione legge ripetutamente tutti i parametri in esso contenuti
/myapp/prod/anziché leggere solo i parametri specifici necessari. Queste richieste ripetute possono superare il limite di richieste predefinito.
Puoi risolvere il problema della Parameter Store limitazione nei seguenti modi complementari:
-
Ridurre la produttività
L'applicazione potrebbe recuperare più dati del necessario o recuperarli in modo inefficiente.
-
Consentire un throughput più elevato
È possibile aumentare la resilienza delle applicazioni aumentando la quota di throughput per una regione e un account specificati. Puoi abilitare e disabilitare l'impostazione di throughput più elevato in qualsiasi momento per i periodi di traffico elevato. Per i carichi di lavoro di produzione che generano regolarmente errori di limitazione, valuta la possibilità di abilitare l'impostazione in modo permanente.
Ridurre la produttività in Parameter Store
Indipendentemente dal fatto che utilizzi una velocità effettiva standard o superiore, controlla la frequenza e il tipo di chiamate verso. Parameter Store In alcuni casi, puoi ridurre il numero di richieste senza modificare i parametri. Poiché il costo è determinato in base all'utilizzo anziché a un modello di abbonamento o di livello, il risultato è un minor numero di interazioni API fatturate.
-
Memorizza nella cache i valori dei parametri nell'applicazione anziché leggere gli stessi valori per ogni richiesta.
Ad esempio, se l'applicazione legge
/myapp/prod/log-levelmolte volte al minuto, può leggere il valore una volta e riutilizzarlo per un breve periodo di tempo. Questa tecnica riduce le chiamate ripetute a. Parameter Store Scegli un periodo di riutilizzo più breve per i valori che cambiano spesso e un periodo di riutilizzo più lungo per i valori che cambiano raramente. -
Usalo GetParameters quando conosci i nomi di più parametri.
Ad esempio, invece di effettuare GetParameter chiamate separate per i parametri e
/myapp/prod/database/host/myapp/prod/log-level/myapp/prod/vendor/merchant-id, è possibile recuperare un elenco di questi parametri in un'unicaGetParametersrichiesta. -
Evita di leggere più parametri di quelli necessari all'applicazione.
Se la tua applicazione richiede solo pochi parametri noti, usa
GetParameterorGetParametersinvece di leggere ripetutamente un intero percorso, ad esempio/myapp/prod/. Da utilizzare GetParametersByPath quando l'applicazione richiede un gruppo di parametri all'interno di un percorso. Quando si utilizza un throughput più elevato, laGetParameterquota è 100 volte la quota per.GetParametersByPath -
Il parametro Spread out viene letto quando molte risorse vengono avviate contemporaneamente.
Ad esempio, se molte istanze di Amazon EC2 o attività di Amazon ECS vengono avviate durante un aggiornamento, evita che tutte le risorse leggano i parametri esattamente nello stesso momento. Le quote sono al secondo. Ove possibile, leggete i parametri una volta e memorizzatene i valori nella cache dell'applicazione, oppure aggiungete un piccolo ritardo in modo che le richieste non avvengano tutte nello stesso secondo.
-
Per le funzioni Lambda, considera l'utilizzo dell'estensione Lambda AWS Parameters and Secrets.
L'estensione può memorizzare i valori dei parametri localmente per il riutilizzo da parte della funzione. Questa tecnica può ridurre il numero di chiamate Parameter Store e può anche ridurre il tempo necessario per recuperare i valori dei parametri. Per un esempio dettagliato di questa tecnica, vedi Uso dell'estensione Lambda AWS Parameter and Secrets per memorizzare nella cache parametri e segreti.
Aumento del throughput in
Per carichi di lavoro con volumi più elevati, puoi abilitare un throughput più elevato. Questa impostazione aumenta il numero massimo di transazioni supportate al secondo per l'account e la regione, a un costo. Prendi in considerazione un throughput più elevato nei seguenti scenari:
-
La tua applicazione ha bisogno temporaneo di un throughput più elevato.
Ad esempio, un negozio online potrebbe leggere i parametri più spesso durante i saldi del fine settimana. È possibile attivare un throughput più elevato prima dell'inizio della vendita e quindi tornare al throughput standard dopo la fine della vendita. Puoi abilitare o disabilitare un throughput più elevato in qualsiasi momento dalla pagina Parameter Store Impostazioni o utilizzando il. AWS CLI
-
L'applicazione di produzione recupera regolarmente i parametri contemporaneamente e si imbatte in problemi di limitazione.
Il recupero simultaneo può avvenire quando più istanze, contenitori, funzioni o processi di compilazione leggono i parametri contemporaneamente. Parameter Store Considerare i seguenti esempi:
-
La scalabilità dell'applicazione è rapida. Ad esempio, l'applicazione viene normalmente eseguita su 5 istanze Amazon EC2. Quando il traffico aumenta improvvisamente, Amazon EC2 Auto Scaling lancia altre 50 istanze. Se ogni istanza legge i parametri all'avvio, le richieste combinate possono superare il limite di richieste predefinito.
-
Il tuo servizio container avvia molte attività contemporaneamente. Ad esempio, un servizio Amazon ECS potrebbe avviare molte attività sostitutive durante un aggiornamento e ciascuna attività potrebbe leggere le impostazioni dal Parameter Store momento dell'avvio.
-
Le tue funzioni Lambda ricevono molte richieste contemporaneamente. Ad esempio, Lambda potrebbe avviare molti ambienti funzionali per gestire l'aumento del traffico. Ogni ambiente funzionale potrebbe leggere i parametri all'avvio.
-
Il processo di compilazione o rilascio legge molti parametri in un breve intervallo di tempo. Ad esempio, un processo di compilazione potrebbe leggere le impostazioni per diverse applicazioni o ambienti.
-
Considerazioni sui costi per una maggiore produttività
Per l'opzione a maggiore produttività, si applicano costi aggiuntivi. Per i prezzi e gli esempi attuali delle Parameter Store API, vedi AWS Systems Manager Pricing
I costi si basano sulle interazioni Parameter Store API. Un'interazione API è definita come un'interazione tra una richiesta API e un singolo parametro. Ad esempio, se una singola GetParameter richiesta restituisce 10 parametri, questa richiesta conta come 10 interazioni Parameter Store API ai fini della fatturazione.
Considera uno scenario in cui desideri passare a un throughput più elevato per un breve periodo di aumento del traffico. Il tuo negozio online organizza una vendita nel fine settimana ed effettua interazioni 1,000,000 Parameter Store API durante la vendita. Se il costo per una maggiore produttività in questo esempio è $0.05 per interazioni 10,000 API, il costo aggiuntivo totale è approssimativo. $5 Puoi tornare alla velocità effettiva standard al termine della vendita e smettere di incorrere in costi.
Combinazione di livelli di produttività e parametri
Il throughput funziona indipendentemente dai livelli dei parametri. Mentre i livelli di parametro controllano i limiti di archiviazione e la disponibilità delle funzionalità, le impostazioni di throughput controllano il volume delle richieste. Per soddisfare i requisiti di prestazioni e scalabilità, puoi utilizzare contemporaneamente livelli e throughput.
Ad esempio, per supportare applicazioni semplici e a basso carico, puoi utilizzare parametri standard con throughput predefinito. Per supportare modelli di accesso su larga scala e ad alta frequenza, è possibile combinare parametri avanzati con un throughput più elevato. In generale, è necessario aumentare la velocità effettiva quando l'applicazione supera i limiti TPS predefiniti (ad esempio, durante sequenze di letture o scritture simultanee), indipendentemente dal livello di parametri utilizzato.
Per ulteriori informazioni sulla velocità effettiva massima e su altre Parameter Store quote, consulta Endpoints and quotas. AWS Systems Manager
Modifica dell'impostazione della velocità effettiva in Parameter Store
Le seguenti procedure descrivono come utilizzare Systems Manager per modificare il numero di transazioni al secondo che Parameter Store possono essere elaborate per l'attuale Account AWS e Regione AWS. È possibile modificare l'impostazione in qualsiasi momento.
