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 Store il throughput definisce il numero di transazioni API al secondo (TPS) che Systems Manager è in grado di elaborare. L'impostazione del throughput si applica a Parameter Store nel suo insieme anziché una singola API. Per impostazione predefinita, Parameter Store è configurato 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. Se necessario, puoi abilitare e disabilitare un throughput più elevato.
Quote di produttività in Parameter Store
La tabella seguente elenca i limiti di transazione per le diverse categorie di API utilizzando un throughput predefinito e superiore. Le azioni API includono AWS utilizzo della console, AWS CLI comandi e letture dell'applicazione. Per ulteriori informazioni sulle quote e sui limiti tariffari, vedere AWS Systems Manager endpoint e quote.
| Operazioni dell'API | Velocità di trasmissione effettiva predefinita | Velocità di trasmissione effettiva più alta |
|---|---|---|
| GetParameter, GetParameters e GetParametersByPath | 40 TPS condiviso 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 fa 40
GetParameterchiamate al secondo. -
10 applicazioni fanno 4
GetParameterchiamate al secondo. -
40 applicazioni fanno 1
GetParameterchiamata 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.
Il DescribeParameters le 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 vostre 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ò riscontrare strozzamento. Ad esempio CloudWatch I registri o i registri delle applicazioni vengono visualizzati ThrottlingException o RateExceeded errori generati dall'SDK quando chiama GetParameter, 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 causare il malfunzionamento dell'applicazione Parameter Store limiti di quota, inclusi i seguenti:
-
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 da Parameter Store quando inizia.
-
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
/myapp/prod/invece di leggere solo i parametri specifici di cui ha bisogno. Queste richieste ripetute possono superare il limite di richieste predefinito.
Puoi rivolgerti Parameter Store limitazione nei seguenti modi complementari:
-
Riduzione della 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 a Parameter Store. In alcuni casi, è possibile 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, l'applicazione può leggere il valore una volta e riutilizzarlo per un breve periodo di tempo. Questa tecnica riduce le chiamate ripetute a Parameter Store. Scegliete 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. -
Usa GetParameters quando conosci i nomi di più parametri.
Ad esempio, invece di separarli GetParameter richiede i parametri
/myapp/prod/database/host,/myapp/prod/log-level, e/myapp/prod/vendor/merchant-id, è possibile recuperare un elenco di questi parametri in un unicoGetParametersrichiesta. -
Evita di leggere più parametri di quelli necessari all'applicazione.
Se la tua applicazione richiede solo alcuni parametri noti, usa
GetParameteroGetParametersinvece di leggere ripetutamente un intero percorso come/myapp/prod/. Usare GetParametersByPath quando l'applicazione richiede un gruppo di parametri in un percorso. Quando si utilizza un throughput più elevato,GetParameterla quota è 100 volte la quota perGetParametersByPath. -
Il parametro Spread out si legge 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 di AWS Parametri e segreti dell'estensione Lambda.
L'estensione può memorizzare i valori dei parametri localmente per il riutilizzo da parte della funzione. Questa tecnica può ridurre il numero di chiamate a Parameter Store e può anche ridurre il tempo necessario per recuperare i valori dei parametri. Per un esempio dettagliato di questa tecnica, vedi Usando AWS Parameter and Secrets: estensione Lambda per memorizzare 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. È possibile abilitare o disabilitare un throughput più elevato in qualsiasi momento da Parameter Store Impostazioni pagina o utilizzando 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 da Parameter Store allo stesso tempo. Considerare i seguenti esempi:
-
La tua applicazione si espande rapidamente. 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 da Parameter Store quando inizia.
-
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 la versione attuale Parameter Store Prezzi ed esempi delle API, vedi AWS Prezzi di Systems Manager
Gli addebiti si basano su Parameter Store Interazioni API. Un'interazione API è definita come un'interazione tra una richiesta API e un singolo parametro. Ad esempio, se un singolo GetParameter la richiesta restituisce 10 parametri, questa richiesta conta come 10 Parameter Store Interazioni API per scopi di 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 e produce 1,000,000 Parameter Store Interazioni API durante la vendita. Se il costo per una maggiore produttività in questo esempio è $0.05 per 10,000 interazioni API, il costo aggiuntivo totale è di circa $5. Puoi tornare alla produttività 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, è possibile 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 altro Parameter Store quote, vedere AWS Systems Manager endpoint e quote.
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 Parameter Store può elaborare per la corrente Account AWS e Regione AWS. È possibile modificare l'impostazione in qualsiasi momento.
