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 Store le 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 dans son ensemble plutôt que comme 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 AWS utilisation de la console, AWS CLI commandes et lectures d'applications. Pour plus d'informations sur les quotas et les limites tarifaires, voir 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 TPS partagé 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 :
-
1 demande donne 40
GetParameterappels par seconde. -
10 demandes en font 4
GetParameterappels par seconde. -
40 demandes font 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.
Le DescribeParameters les 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
Quand Parameter Store reçoit plusieurs demandes de paramètres dans un court intervalle, votre application peut en faire l'expérience étranglement. Par exemple, CloudWatch Les journaux ou les journaux de votre application s'affichent ThrottlingException ou RateExceeded erreurs générées par le SDK lorsqu'il appelle GetParameter, GetParameters, ou GetParametersByPath. 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 échecs de déploiements, des solutions de contournement complexes et une perte de temps pour les développeurs.
De multiples facteurs peuvent faire en sorte que votre application soit sélectionnée Parameter Store limites de quotas, y compris les suivantes :
-
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 de Parameter Store quand ça commence.
-
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 sous
/myapp/prod/au lieu de lire uniquement les paramètres spécifiques dont il a besoin. Ces demandes répétées peuvent dépasser la limite de demandes par défaut.
Vous pouvez adresser Parameter Store étrangler de la manière complémentaire suivante :
-
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 à 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 se lit comme suit
/myapp/prod/log-levelplusieurs fois par minute, l'application peut lire la valeur une 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 de séparer GetParameter demande les paramètres
/myapp/prod/database/host,/myapp/prod/log-level, et/myapp/prod/vendor/merchant-id, vous pouvez récupérer la liste de ces paramètres en une seuleGetParametersdemande. -
É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
GetParameterouGetParametersau lieu de lire à plusieurs reprises un chemin entier 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é,GetParameterle quota est de 100 fois le 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 AWS Paramètres et secrets de l'extension Lambda.
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 vers 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 À l'aide du AWS Extension Lambda de paramètres et de 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 le Parameter Store Réglages page 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 avoir lieu lorsque plusieurs instances, conteneurs, fonctions ou tâches de génération lisent les paramètres depuis 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 de Parameter Store quand ça commence.
-
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 le courant Parameter Store Tarification des API et exemples, voir AWS Tarification des gestionnaires de systèmes
Les frais sont basés sur Parameter Store Interactions avec les API. Une interaction d'API est définie comme une interaction entre une demande d'API et un paramètre individuel. Par exemple, si un seul GetParameter la requête renvoie 10 paramètres, cette demande compte pour 10 Parameter Store Interactions d'API à 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 propose 1,000,000 Parameter Store Interactions avec les API pendant la vente. Si le coût d'un débit plus élevé dans cet exemple est $0.05 par 10,000 Interactions API, 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 en même temps.
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 d'autres Parameter Store quotas, voir 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 qui Parameter Store peut traiter pour le courant Compte AWS et Région AWS. Vous pouvez modifier le réglage à tout moment.
