Administración del rendimiento del Parameter Store
El rendimiento del Parameter Store define la cantidad de transacciones de API por segundo (TPS) que Systems Manager puede procesar. La configuración de rendimiento se aplica al Parameter Store en su conjunto y no a una API individual. De forma predeterminada, el Parameter Store está configurado con una cuota de rendimiento estándar que suele ser adecuada para cargas de trabajo de volumen bajo a moderado. Para cargas de trabajo de mayor volumen, puede habilitar un mayor rendimiento, lo que aumenta el número máximo de transacciones admitidas por segundo para su cuenta y región. Puede habilitar y deshabilitar el rendimiento superior según sea necesario.
Cuotas de rendimiento en el Parameter Store
En la siguiente tabla, se enumeran los límites de transacción para las diferentes categorías de API con un rendimiento predeterminado y uno superior. Las acciones de la API incluyen el uso de la consola de AWS, los comandos de la AWS CLI y las lecturas de las aplicaciones. Para obtener más información sobre los límites de frecuencia y las cuotas, consulte Puntos de conexión y cuotas de AWS Systems Manager.
| acciones de API | Rendimiento predeterminado | Mayor rendimiento |
|---|---|---|
| GetParameter, GetParameters y GetParametersByPath | 40 TPS compartidos en las tres acciones de la API combinadas |
GetParameter: 10,000 TPS; GetParameters: 1,000 TPS; GetParametersByPath: 100 TPS |
| DeleteParameter y DeleteParameters | 3 TPS |
5 TPS |
| DescribeParameters, GetParameterHistory, LabelParameterVersion, UnlabelParameterVersion y PutParameter | 3 TPS |
10 TPS |
En este contexto, una transacción es una acción de API para una cuenta en una sola región. Por ejemplo, el siguiente comando crea una sola transacción.
aws ssm get-parameter --name "/myapp/prod/log-level"
Las acciones de la API se pueden distribuir entre aplicaciones. Por ejemplo, cada uno de los siguientes escenarios alcanza el límite de rendimiento predeterminado de 40 TPS:
-
Una aplicación hace 40 llamadas a
GetParameterpor segundo. -
10 aplicaciones hacen 4 llamadas a
GetParameterpor segundo. -
40 aplicaciones hacen 1 llamada a
GetParameterpor segundo.
Se aplica un límite de rendimiento a todas las API de una categoría. Por ejemplo, la siguiente combinación de llamadas de parámetros simultáneas para una aplicación cumple el límite predeterminado de 40 TPS para las API de recuperación de parámetros:
-
GetParameterhace 25 llamadas por segundo. -
GetParametershace 10 llamadas por segundo. -
GetParameterByPathhace 5 llamadas por segundo.
Las llamadas a DescribeParameters tienen un límite de rendimiento independiente. Una aplicación puede hacer las llamadas anteriores mientras hace 3 llamadas a DescribeParameters por segundo sin superar el límite general de rendimiento estándar.
Si las solicitudes de producción superan un límite de rendimiento durante el funcionamiento estándar o durante periodos planificados de mucho tráfico, utilice las siguientes técnicas de optimización.
Temas
Optimización del rendimiento en el Parameter Store
Cuando el Parameter Store recibe varias solicitudes de parámetros en un intervalo breve, la aplicación puede sufrir una limitación. Por ejemplo, Registros de CloudWatch o los registros de la aplicación muestran los errores ThrottlingException o RateExceeded generados por el SDK cuando llama a GetParameter, GetParameters o GetParametersByPath. En otros casos, la lógica de la aplicación reintenta correctamente las llamadas a la API, pero la latencia de la aplicación aumenta. El resultado puede ser interrupciones en las aplicaciones, una experiencia de usuario subóptima, implementaciones fallidas, soluciones alternativas complejas y pérdida de tiempo para los desarrolladores.
Hay varios factores que pueden llevar a que la aplicación alcance los límites de cuota del Parameter Store, entre los que se incluyen los siguientes:
-
La aplicación se escala horizontalmente de forma rápida debido a un pico de tráfico. Por ejemplo, la aplicación se ejecuta normalmente en 5 instancias de Amazon EC2. Cuando el tráfico aumenta repentinamente, Amazon EC2 Auto Scaling lanza 50 instancias más. Si cada instancia lee los parámetros al iniciarse, las solicitudes combinadas pueden superar el límite de solicitudes predeterminado.
-
El servicio de contenedores inicia muchas tareas al mismo tiempo. Por ejemplo, un servicio de Amazon ECS puede iniciar muchas tareas de reemplazo durante una actualización y cada tarea puede leer la configuración desde el Parameter Store cuando se inicia.
-
Las funciones de Lambda reciben muchas solicitudes al mismo tiempo. Por ejemplo, Lambda podría iniciar muchos entornos de funciones para gestionar el aumento del tráfico. Cada entorno de funciones puede leer los parámetros al iniciarse.
-
El proceso de creación o publicación lee muchos parámetros en un breve intervalo de tiempo. Por ejemplo, un trabajo de creación puede leer la configuración de varias aplicaciones o entornos.
-
La aplicación lee muchos parámetros por ruta. Por ejemplo, la aplicación lee repetidamente todos los parámetros de
/myapp/prod/en lugar de leer solo los parámetros específicos que necesita. Estas solicitudes repetidas pueden superar el límite de solicitudes predeterminado.
Puede abordar la limitación del Parameter Store de las siguientes formas complementarias:
-
Reducción del rendimiento
Es posible que la aplicación recupere más datos de los que necesita o que los recupere de forma ineficiente.
-
Habilitación de mayor rendimiento
Para aumentar la resiliencia de las aplicaciones, puede aumentar la cuota de rendimiento para una región y una cuenta específicas. Puede habilitar y deshabilitar la configuración de mayor rendimiento en cualquier momento para los periodos de alto tráfico. En el caso de las cargas de trabajo de producción que suelen generar errores de limitación, considere la posibilidad de habilitar la configuración de forma permanente.
Reducción del rendimiento en el Parameter Store
Tanto si utiliza un rendimiento estándar como superior, revise la frecuencia y el tipo de llamadas al Parameter Store. En algunos casos, puede reducir el número de solicitudes sin cambiar los parámetros. Como el costo se determina en función del uso y no de un modelo de suscripción o nivel, el resultado es un menor número de interacciones de API facturadas.
-
Guarde en caché los valores de los parámetros en la aplicación en lugar de leer los mismos valores en cada solicitud.
Por ejemplo, si la aplicación lee
/myapp/prod/log-levelmuchas veces por minuto, puede leer el valor una vez y reutilizarlo durante un breve periodo de tiempo. Esta técnica reduce las llamadas repetidas al Parameter Store. Elija un periodo de reutilización más corto para los valores que cambien con frecuencia y uno más largo para los valores que cambien con poca frecuencia. -
Utilice GetParameters cuando conozca los nombres de varios parámetros.
Por ejemplo, en lugar de hacer llamadas a GetParameter independientes para los parámetros
/myapp/prod/database/host,/myapp/prod/log-levely/myapp/prod/vendor/merchant-id, puede recuperar una lista de estos parámetros en una sola solicitudGetParameters. -
Evite leer más parámetros de los que necesita la aplicación.
Si la aplicación solo necesita unos pocos parámetros conocidos, utilice
GetParameteroGetParametersen lugar de leer repetidamente una ruta completa, como/myapp/prod/. Utilice GetParametersByPath cuando la aplicación necesite un grupo de parámetros en una ruta. Cuando se utiliza un rendimiento más alto, la cuota deGetParameteres 100 veces mayor que la cuota deGetParametersByPath. -
Distribuya las lecturas de parámetros cuando se inicien varios recursos al mismo tiempo.
Por ejemplo, si muchas instancias de Amazon EC2 o tareas de Amazon ECS se inician durante una actualización, evite que todos los recursos lean los parámetros exactamente al mismo tiempo. Las cuotas son por segundo. Siempre que sea posible, lea los parámetros una vez y almacene en caché los valores en la aplicación o agregue un pequeño retraso para que las solicitudes no se produzcan todas en el mismo segundo.
-
Para las funciones de Lambda, considere la posibilidad de utilizar la extensión de Lambda para secretos y parámetros de AWS.
La extensión puede almacenar los valores de los parámetros de forma local para que la función los reutilice. Esta técnica puede reducir el número de llamadas al Parameter Store, así como el tiempo necesario para recuperar los valores de los parámetros. Para ver un ejemplo de esta técnica, consulte Uso de la extensión de Lambda para secretos y parámetros de AWS para almacenar parámetros y secretos en caché
.
Aumento del rendimiento
Para cargas de trabajo de mayor volumen, puede habilitar un mayor rendimiento. Esta configuración aumenta el número máximo de transacciones admitidas por segundo para su cuenta y región, con un costo adicional. Considere la posibilidad de utilizar un mayor rendimiento en las siguientes situaciones:
-
La aplicación necesita temporalmente un mayor rendimiento.
Por ejemplo, una tienda web podría leer los parámetros con más frecuencia durante una oferta de fin de semana. Puedes habilitar un mayor rendimiento antes de que comience la oferta y, después, volver al rendimiento estándar una vez finalizada. Puede habilitar o deshabilitar un rendimiento superior en cualquier momento desde la página de Configuración de Parameter Store o mediante la AWS CLI.
-
La aplicación de producción recupera los parámetros de forma periódica y simultánea y se enfrenta a problemas de limitación.
La recuperación simultánea puede producirse cuando varias instancias, contenedores, funciones o trabajos de creación leen parámetros del Parameter Store al mismo tiempo. Algunos ejemplos son los siguientes:
-
La aplicación escala horizontalmente de forma rápida. Por ejemplo, la aplicación se ejecuta normalmente en 5 instancias de Amazon EC2. Cuando el tráfico aumenta repentinamente, Amazon EC2 Auto Scaling lanza 50 instancias más. Si cada instancia lee los parámetros al iniciarse, las solicitudes combinadas pueden superar el límite de solicitudes predeterminado.
-
El servicio de contenedores inicia muchas tareas al mismo tiempo. Por ejemplo, un servicio de Amazon ECS puede iniciar muchas tareas de reemplazo durante una actualización y cada tarea puede leer la configuración desde el Parameter Store cuando se inicia.
-
Las funciones de Lambda reciben muchas solicitudes al mismo tiempo. Por ejemplo, Lambda podría iniciar muchos entornos de funciones para gestionar el aumento del tráfico. Cada entorno de funciones puede leer los parámetros al iniciarse.
-
El proceso de creación o publicación lee muchos parámetros en un breve intervalo de tiempo. Por ejemplo, un trabajo de creación puede leer la configuración de varias aplicaciones o entornos.
-
Consideraciones de costos para un mayor rendimiento
Para la opción de mayor rendimiento, se aplican cargos adicionales. Para ver los precios y ejemplos actuales de las API del Parameter Store, consulte Precios de AWS Systems Manager
Los cargos se basan en las interacciones de API del Parameter Store. Una interacción de API se define como una interacción entre una solicitud de API y un parámetro individual. Por ejemplo, si una sola solicitud GetParameter devuelve 10 parámetros, esta solicitud cuenta como 10 interacciones de API del Parameter Store a efectos de facturación.
Imagine una situación en la que desee cambiar a un mayor rendimiento durante un breve periodo de aumento del tráfico. La tienda web tiene una oferta de fin de semana y lleva a cabo 1,000,000 interacciones de API del Parameter Store durante la oferta. Si el costo de un mayor rendimiento en este ejemplo es $0.05 por 10,000 interacciones de API, el costo adicional total es aproximadamente $5. Puede volver al rendimiento estándar al final de la oferta y dejar de incurrir en costos.
Combinación de niveles de parámetros y rendimiento
El rendimiento funciona independientemente de los niveles de parámetros. Mientras que las capas de parámetros controlan los límites de almacenamiento y la disponibilidad de las características, la configuración de rendimiento controla el volumen de solicitudes. Para cumplir con los requisitos de rendimiento y escalado, puede utilizar los niveles y el rendimiento juntos.
Por ejemplo, para admitir aplicaciones sencillas y de baja carga, puede utilizar parámetros estándar con un rendimiento predeterminado. Para admitir patrones de acceso a gran escala y alta frecuencia, puede combinar parámetros avanzados con un mayor rendimiento. En general, es necesario aumentar el rendimiento cuando la aplicación supera los límites de TPS predeterminados (por ejemplo, durante ráfagas de lecturas o escrituras simultáneas), independientemente de la capa de parámetros que utilice.
Para obtener más información acerca del rendimiento máximo y otras cuotas de Parameter Store, consulte Puntos de conexión de AWS Systems Manager.
Cambio de la configuración de rendimiento en el Parameter Store
Los siguientes procedimientos describen cómo utilizar Systems Manager para cambiar el número de transacciones por segundo que el Parameter Store puede procesar para la Cuenta de AWS y la Región de AWS actuales. Puede cambiar la configuración en cualquier momento.
