• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la documentation Amazon CloudWatch Dashboard.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Gestion Parameter Store débit
Parameter Storele débit définit le nombre de transactions d'API par seconde (TPS) que Systems Manager peut traiter. Le paramètre de débit s'applique à Parameter Store l'API dans son ensemble plutôt qu'à une API individuelle. Par défaut, Parameter Store est configuré avec un quota de débit standard qui convient souvent aux charges de travail à volume faible à modéré. Pour les charges de travail plus volumineuses, vous pouvez activer un débit plus élevé, ce qui augmente le nombre maximum de transactions prises en charge par seconde pour votre compte et votre région. Vous pouvez activer et désactiver un débit plus élevé selon vos besoins.
Quotas de débit en Parameter Store
Le tableau suivant répertorie les limites de transactions pour les différentes catégories d'API en utilisant le débit par défaut et un débit plus élevé. Les actions de l'API incluent l'utilisation de la AWS console, AWS CLI les commandes et les lectures d'applications. Pour plus d'informations sur les quotas et les limites de débit, consultez la section AWS Systems Manager Points de terminaison et quotas.
| Actions d’API | Débit par défaut | Débit supérieur |
|---|---|---|
| GetParameter, GetParameters et GetParametersByPath | 40 TPSpartagé entre les trois actions d'API combinées |
GetParameter: 10,000 TPS;
GetParameters: 1,000 TPS;
GetParametersByPath: 100 TPS
|
| DeleteParameter et DeleteParameters | 3 TPS |
5 TPS |
| DescribeParameters, GetParameterHistory, LabelParameterVersion, UnlabelParameterVersion et PutParameter | 3 TPS |
10 TPS |
Dans ce contexte, une transaction est une action d'API pour un compte dans une seule région. Par exemple, la commande suivante crée une transaction unique.
aws ssm get-parameter --name "/myapp/prod/log-level"
Les actions de l'API peuvent être distribuées entre les applications. Par exemple, chacun des scénarios suivants atteint la limite de débit par défaut de 40 TPS :
-
Une application passe 40
GetParameterappels par seconde. -
10 applications passent 4
GetParameterappels par seconde. -
40 applications passent 1
GetParameterappel par seconde.
Une limite de débit s'applique à toutes les API d'une catégorie. Par exemple, la combinaison suivante d'appels de paramètres simultanés pour une application respecte la limite par défaut de 40 TPS pour les API de récupération de paramètres :
-
GetParameterpasse 25 appels par seconde. -
GetParameterspasse 10 appels par seconde. -
GetParameterByPathpasse 5 appels par seconde.
Les DescribeParameters appels ont une limite de débit distincte. Une application peut effectuer les appels précédents tout en effectuant 3 DescribeParameters appels par seconde sans dépasser la limite globale du débit standard.
Si vos demandes de production dépassent une limite de débit pendant les opérations standard ou pendant les périodes planifiées de trafic élevé, utilisez les techniques d'optimisation suivantes.
Rubriques
Optimisation du débit dans Parameter Store
Lorsque Parameter Store vous recevez plusieurs demandes de paramètres dans un court intervalle, votre application peut être ralentie. Par exemple, CloudWatch les journaux ou les journaux de votre application indiquent ThrottlingException RateExceeded les erreurs générées par le SDK lorsqu'il appelle GetParameterGetParameters, ouGetParametersByPath. Dans d'autres cas, la logique de l'application tente de nouveau les appels d'API avec succès, mais la latence de l'application augmente. Il peut en résulter des pannes d'applications, une expérience utilisateur sous-optimale, des déploiements échoués, des solutions de contournement complexes et une perte de temps pour les développeurs.
Plusieurs facteurs peuvent faire en sorte que votre demande atteigne les limites de Parameter Store quota, notamment les suivants :
-
Votre application évolue rapidement en raison d'un pic de trafic. Par exemple, votre application s'exécute normalement sur 5 instances Amazon EC2. Lorsque le trafic augmente soudainement, Amazon EC2 Auto Scaling lance 50 instances supplémentaires. Si chaque instance lit les paramètres au démarrage, les demandes combinées peuvent dépasser la limite de requêtes par défaut.
-
Votre service de conteneurs commence de nombreuses tâches en même temps. Par exemple, un service Amazon ECS peut démarrer de nombreuses tâches de remplacement lors d'une mise à jour, et chaque tâche peut lire les paramètres Parameter Store dès son démarrage.
-
Vos fonctions Lambda reçoivent de nombreuses demandes en même temps. Par exemple, Lambda peut démarrer de nombreux environnements fonctionnels pour gérer l'augmentation du trafic. Chaque environnement de fonction peut lire les paramètres lorsqu'il démarre.
-
Votre processus de compilation ou de publication lit de nombreux paramètres dans un court intervalle de temps. Par exemple, une tâche de génération peut lire les paramètres de plusieurs applications ou environnements.
-
Votre application lit de nombreux paramètres par chemin. Par exemple, votre application lit à plusieurs reprises tous les paramètres ci-dessous
/myapp/prod/au lieu de lire uniquement les paramètres spécifiques dont elle a besoin. Ces demandes répétées peuvent dépasser la limite de demandes par défaut.
Vous pouvez résoudre le problème de l'Parameter Storeétranglement des manières complémentaires suivantes :
-
Réduire le débit
Il se peut que votre application récupère plus de données que ce dont elle a besoin ou qu'elle les récupère de manière inefficace.
-
Permettre un débit plus élevé
Vous pouvez améliorer la résilience des applications en augmentant le quota de débit pour une région et un compte spécifiques. Vous pouvez activer et désactiver le paramètre de haut débit à tout moment pendant les périodes de trafic élevé. Pour les charges de travail de production qui génèrent régulièrement des erreurs d'étranglement, pensez à activer le paramètre de façon permanente.
Réduire le débit dans Parameter Store
Que vous utilisiez un débit standard ou supérieur, vérifiez la fréquence et le type d'appels adressés àParameter Store. Dans certains cas, vous pouvez réduire le nombre de demandes sans modifier vos paramètres. Comme le coût est déterminé en fonction de l'utilisation plutôt que d'un modèle d'abonnement ou de niveau, il en résulte une diminution des interactions facturées avec les API.
-
Mettez en cache les valeurs des paramètres dans votre application au lieu de lire les mêmes valeurs à chaque demande.
Par exemple, si votre application lit
/myapp/prod/log-levelplusieurs fois par minute, elle peut lire la valeur une seule fois et la réutiliser pendant une courte période. Cette technique permet de réduire les appels répétés àParameter Store. Choisissez une période de réutilisation plus courte pour les valeurs qui changent souvent et une période de réutilisation plus longue pour les valeurs qui changent rarement. -
À utiliser GetParameters lorsque vous connaissez le nom de plusieurs paramètres.
Par exemple, au lieu d'effectuer des GetParameter appels séparés pour les paramètres
/myapp/prod/database/host/myapp/prod/log-level, et/myapp/prod/vendor/merchant-id, vous pouvez récupérer une liste de ces paramètres dans une seuleGetParametersrequête. -
Évitez de lire plus de paramètres que ce dont votre application a besoin.
Si votre application n'a besoin que de quelques paramètres connus, utilisez
GetParameterouGetParametersplutôt que de lire à plusieurs reprises un chemin complet tel que/myapp/prod/. À utiliser GetParametersByPath lorsque votre application a besoin d'un groupe de paramètres sous un chemin. Lorsque vous utilisez un débit plus élevé, leGetParameterquota est 100 fois supérieur au quota pourGetParametersByPath. -
Répartissez les lectures de paramètres lorsque de nombreuses ressources démarrent en même temps.
Par exemple, si de nombreuses instances Amazon EC2 ou tâches Amazon ECS démarrent pendant une mise à jour, évitez que toutes les ressources lisent les paramètres exactement au même moment. Les quotas sont définis par seconde. Dans la mesure du possible, lisez les paramètres une seule fois et mettez leurs valeurs en cache dans l'application, ou ajoutez un léger délai pour que les demandes n'apparaissent pas toutes dans la même seconde.
-
Pour les fonctions Lambda, pensez à utiliser l'extension Lambda AWS Parameters and Secrets.
L'extension peut stocker les valeurs des paramètres localement pour les réutiliser par la fonction. Cette technique permet de réduire le nombre d'appels Parameter Store et peut également réduire le temps nécessaire pour récupérer les valeurs des paramètres. Pour un exemple de présentation de cette technique, voir Utilisation de l'extension Lambda AWS Parameter and Secrets pour mettre en cache les paramètres et les secrets.
Accroissement du débit
Pour les charges de travail plus volumineuses, vous pouvez activer un débit plus élevé. Ce paramètre augmente le nombre maximum de transactions prises en charge par seconde pour votre compte et votre région, moyennant un coût. Envisagez un débit plus élevé dans les scénarios suivants :
-
Votre application a temporairement besoin d'un débit plus élevé.
Par exemple, une boutique en ligne peut lire les paramètres plus souvent lors d'une vente le week-end. Vous pouvez activer un débit plus élevé avant le début de la vente, puis revenir au débit standard une fois la vente terminée. Vous pouvez activer ou désactiver un débit plus élevé à tout moment depuis la page Parameter Store Paramètres ou en utilisant le AWS CLI.
-
Votre application de production récupère régulièrement les paramètres simultanément et rencontre des problèmes de limitation.
La récupération simultanée peut se produire lorsque plusieurs instances, conteneurs, fonctions ou tâches de construction lisent les paramètres Parameter Store en même temps. Voici quelques exemples :
-
Votre application évolue rapidement. Par exemple, votre application s'exécute normalement sur 5 instances Amazon EC2. Lorsque le trafic augmente soudainement, Amazon EC2 Auto Scaling lance 50 instances supplémentaires. Si chaque instance lit les paramètres au démarrage, les demandes combinées peuvent dépasser la limite de requêtes par défaut.
-
Votre service de conteneurs commence de nombreuses tâches en même temps. Par exemple, un service Amazon ECS peut démarrer de nombreuses tâches de remplacement lors d'une mise à jour, et chaque tâche peut lire les paramètres Parameter Store dès son démarrage.
-
Vos fonctions Lambda reçoivent de nombreuses demandes en même temps. Par exemple, Lambda peut démarrer de nombreux environnements fonctionnels pour gérer l'augmentation du trafic. Chaque environnement de fonction peut lire les paramètres lorsqu'il démarre.
-
Votre processus de compilation ou de publication lit de nombreux paramètres dans un court intervalle de temps. Par exemple, une tâche de génération peut lire les paramètres de plusieurs applications ou environnements.
-
Considérations relatives aux coûts pour un débit plus élevé
Pour l'option haut débit, des frais supplémentaires s'appliquent. Pour consulter les tarifs actuels des Parameter Store API et des exemples, consultez la section Tarification de AWS Systems Manager
Les frais sont basés sur les interactions avec Parameter Store l'API. Une interaction d'API est définie comme une interaction entre une demande d'API et un paramètre individuel. Par exemple, si une seule GetParameter demande renvoie 10 paramètres, cette demande compte pour 10 interactions d'Parameter StoreAPI à des fins de facturation.
Envisagez un scénario dans lequel vous souhaitez passer à un débit plus élevé pendant une courte période d'augmentation du trafic. Votre boutique en ligne organise une vente le week-end et effectue des interactions avec 1,000,000 Parameter Store l'API pendant la vente. Si, dans cet exemple, le coût d'un débit plus élevé est $0.05 calculé par interaction d'10,000API, le coût supplémentaire total est d'environ$5. Vous pouvez revenir au débit standard à la fin de la vente et ne plus avoir à encourir de frais.
Combiner le débit et les niveaux de paramètres
Le débit fonctionne indépendamment des niveaux de paramètres. Alors que les niveaux de paramètres contrôlent les limites de stockage et la disponibilité des fonctionnalités, les paramètres de débit contrôlent le volume des demandes. Pour répondre aux exigences de performances et d'évolutivité, vous pouvez utiliser les niveaux et le débit conjointement.
Par exemple, pour prendre en charge des applications simples et à faible charge, vous pouvez utiliser des paramètres standard avec un débit par défaut. Pour prendre en charge des modèles d'accès à grande échelle et à haute fréquence, vous pouvez combiner des paramètres avancés avec un débit plus élevé. En général, il est nécessaire d'augmenter le débit lorsque votre application dépasse les limites TPS par défaut (par exemple, lors de rafales de lectures ou d'écritures simultanées), quel que soit le niveau de paramètres que vous utilisez.
Pour plus d'informations sur le débit maximal et les autres Parameter Store quotas, consultez la section AWS Systems Manager Points de terminaison et quotas.
Modification du paramètre de débit dans Parameter Store
Les procédures suivantes décrivent comment utiliser Systems Manager pour modifier le nombre de transactions par seconde Parameter Store pouvant être traitées pour les transactions en cours Compte AWS et Région AWS. Vous pouvez modifier le réglage à tout moment.
