En esta sección se proporciona información general sobre cómo evaluar si tiene aprovisionamiento del tamaño adecuado en las tablas de DynamoDB. A medida que evolucione la carga de trabajo, debe modificar los procedimientos operativos de manera adecuada, especialmente si la tabla de DynamoDB está configurada en modo aprovisionado y corre el riesgo de aprovisionar en exceso o de manera insuficiente las tablas.
Los procedimientos que se describen a continuación requieren información estadística que se debe capturar de las tablas de DynamoDB que son compatibles con la aplicación de producción. Para entender el comportamiento de la aplicación, debe definir un periodo de tiempo que sea lo suficientemente significativo como para captar la estacionalidad de los datos de la aplicación. Por ejemplo, si la aplicación muestra patrones semanales, utilizar un periodo de tres semanas debería darle suficiente espacio para analizar las necesidades de rendimiento de la aplicación.
Si no sabe por dónde empezar, utilice al menos un mes de uso de datos para los cálculos que se indican a continuación.
Al evaluar la capacidad, las tablas de DynamoDB pueden configurar las unidades de capacidad de lectura (RCU) y las unidades de capacidad de escritura (WCU) de forma independiente. Si las tablas tienen algún índice secundario global (GSI) configurado, deberá especificar el rendimiento que consumirá, que también será independiente de las RCU y las WCU de la tabla base.
nota
Los índices secundarios locales (LSI) consumen capacidad de la tabla base.
Temas
Cómo recuperar las métricas de consumo de las tablas de DynamoDB
Para evaluar la tabla y la capacidad del GSI, monitoree las siguientes métricas de CloudWatch y seleccione la dimensión adecuada para recuperar la información de la tabla o del GSI:
| Unidades de capacidad de lectura | Unidades de capacidad de escritura |
|---|---|
|
|
|
|
|
|
|
|
|
Puede hacer esto a través de la AWS CLI o la AWS Management Console.
Antes de recuperar las métricas de consumo de la tabla, tendremos que empezar por capturar algunos puntos de datos históricos mediante la API de CloudWatch.
Comience por crear dos archivos: write-calc.json y read-calc.json. Estos archivos representarán los cálculos de una tabla o GSI. Deberá actualizar algunos de los campos, como se indica en la tabla siguiente, para que coincidan con el entorno.
| Nombre del campo | Definición | Ejemplo |
|---|---|---|
<table-name> |
El nombre de la tabla que analizará | SampleTable |
<period> |
El periodo de tiempo que utilizará para evaluar el objetivo de utilización, en segundos | Para un periodo de 1 hora, debe especificar: 3600 |
<start-time> |
El comienzo del intervalo de evaluación, especificado en formato ISO8601 | 2022-02-21T23:00:00 |
<end-time> |
El final del intervalo de evaluación, especificado en formato ISO8601 | 2022-02-22T06:00:00 |
El archivo de cálculos de escritura recuperará la cantidad de WCU aprovisionadas y consumidas en el periodo de tiempo del intervalo de fechas especificado. También generará un porcentaje de utilización que se usará para el análisis. El contenido completo del archivo write-calc.json debe ser similar al siguiente:
{
"MetricDataQueries": [
{
"Id": "provisionedWCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/DynamoDB",
"MetricName": "ProvisionedWriteCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": "<table-name>"
}
]
},
"Period": <period>,
"Stat": "Average"
},
"Label": "Provisioned",
"ReturnData": false
},
{
"Id": "consumedWCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/DynamoDB",
"MetricName": "ConsumedWriteCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": "<table-name>""
}
]
},
"Period": <period>,
"Stat": "Sum"
},
"Label": "",
"ReturnData": false
},
{
"Id": "m1",
"Expression": "consumedWCU/PERIOD(consumedWCU)",
"Label": "Consumed WCUs",
"ReturnData": false
},
{
"Id": "utilizationPercentage",
"Expression": "100*(m1/provisionedWCU)",
"Label": "Utilization Percentage",
"ReturnData": true
}
],
"StartTime": "<start-time>",
"EndTime": "<ent-time>",
"ScanBy": "TimestampDescending",
"MaxDatapoints": 24
} El archivo de cálculos de lectura utiliza un archivo similar. Este archivo recuperará cuántas RCU se aprovisionaron y consumieron durante el periodo de tiempo del intervalo de fechas especificado. El contenido del archivo read-calc.json debe ser similar al siguiente:
{
"MetricDataQueries": [
{
"Id": "provisionedRCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/DynamoDB",
"MetricName": "ProvisionedReadCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": "<table-name>"
}
]
},
"Period": <period>,
"Stat": "Average"
},
"Label": "Provisioned",
"ReturnData": false
},
{
"Id": "consumedRCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/DynamoDB",
"MetricName": "ConsumedReadCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": "<table-name>"
}
]
},
"Period": <period>,
"Stat": "Sum"
},
"Label": "",
"ReturnData": false
},
{
"Id": "m1",
"Expression": "consumedRCU/PERIOD(consumedRCU)",
"Label": "Consumed RCUs",
"ReturnData": false
},
{
"Id": "utilizationPercentage",
"Expression": "100*(m1/provisionedRCU)",
"Label": "Utilization Percentage",
"ReturnData": true
}
],
"StartTime": "<start-time>",
"EndTime": "<end-time>",
"ScanBy": "TimestampDescending",
"MaxDatapoints": 24
} Una vez que haya creado los archivos, podrá empezar a recuperar los datos de uso.
-
Para recuperar los datos de utilización de escritura, ejecute el siguiente comando:
aws cloudwatch get-metric-data --cli-input-json file://write-calc.json -
Para recuperar los datos de utilización de lectura, ejecute el siguiente comando:
aws cloudwatch get-metric-data --cli-input-json file://read-calc.json
El resultado de ambas consultas será una serie de puntos de datos en formato JSON que se utilizarán para el análisis. El resultado dependerá de la cantidad de puntos de datos que haya especificado, del periodo y de los propios datos de carga de trabajo específicos. Podría tener un aspecto similar al siguiente:
{
"MetricDataResults": [
{
"Id": "utilizationPercentage",
"Label": "Utilization Percentage",
"Timestamps": [
"2022-02-22T05:00:00+00:00",
"2022-02-22T04:00:00+00:00",
"2022-02-22T03:00:00+00:00",
"2022-02-22T02:00:00+00:00",
"2022-02-22T01:00:00+00:00",
"2022-02-22T00:00:00+00:00",
"2022-02-21T23:00:00+00:00"
],
"Values": [
91.55364583333333,
55.066631944444445,
2.6114930555555556,
24.9496875,
40.94725694444445,
25.61819444444444,
0.0
],
"StatusCode": "Complete"
}
],
"Messages": []
} nota
Si especifica un periodo corto y un intervalo de tiempo largo, es posible que tenga que modificar MaxDatapoints, que es el valor predeterminado establecido en 24 en el script. Este representa un punto de datos por hora y 24 por día.
Cómo identificar tablas de DynamoDB con falta de aprovisionamiento
Para la mayoría de las cargas de trabajo, una tabla se considera con falta de aprovisionamiento cuando consume de forma continua más del 80 % de la capacidad aprovisionada.
La capacidad de ampliación es una característica de DynamoDB que permite a los clientes consumir temporalmente más RCU o WCU de las aprovisionadas originalmente (más que el rendimiento aprovisionado por segundo que se definió en la tabla). La capacidad de ampliación se creó para absorber los aumentos repentinos del tráfico debido a eventos especiales o picos de uso. Esta capacidad de ampliación no dura para siempre. Tan pronto como se agoten las RCU y WCU no utilizadas, se verá limitado si intenta consumir más capacidad de la aprovisionada. Cuando el tráfico de la aplicación se acerca a la tasa de utilización del 80 %, el riesgo de limitación es significativamente mayor.
La regla de la tasa de utilización del 80 % varía según la estacionalidad de los datos y el crecimiento del tráfico. Considere los siguientes escenarios:
-
Si el tráfico se ha mantenido estable a una tasa de utilización de aproximadamente el 90 % durante los últimos 12 meses, la tabla tiene la capacidad adecuada
-
Si el tráfico de la aplicación crece a un ritmo del 8 % mensual en menos de 3 meses, llegará al 100 %
-
Si el tráfico de la aplicación crece a un ritmo del 5 % mensual en un poco más de 4 meses, llegará al 100 %
Los resultados de las consultas anteriores proporcionan una imagen de la tasa de utilización. Úselos como guía para evaluar con más detalle otras métricas que pueden ayudarle a aumentar la capacidad de la tabla según sea necesario (por ejemplo, una tasa de crecimiento mensual o semanal). Trabaje con el equipo de operaciones para definir cuál es un buen porcentaje para la carga de trabajo y las tablas.
Hay escenarios especiales en los que los datos están sesgados cuando los analizamos a diario o semanalmente. Por ejemplo, en el caso de las aplicaciones estacionales que tienen picos de uso durante las horas de trabajo (pero que luego se reducen a casi cero fuera del horario laboral), podría resultar beneficioso programar el escalado automático en el que se especifiquen las horas del día (y los días de la semana) para aumentar la capacidad aprovisionada y cuándo reducirla. En lugar de optar por una mayor capacidad para cubrir las horas más ocupadas, también puede aprovechar las configuraciones de escalado automático de tablas de DynamoDB si la estacionalidad es menos pronunciada.
nota
Al crear una configuración de escalado automático de DynamoDB para la tabla base, recuerde incluir otra configuración para cualquier GSI que esté asociado a la tabla.
Cómo identificar tablas de DynamoDB con exceso de aprovisionamiento
Los resultados de la consulta obtenidos de los scripts anteriores proporcionan los puntos de datos necesarios para realizar algunos análisis iniciales. Si el conjunto de datos presenta valores de utilización inferiores al 20 % durante varios intervalos, es posible que la tabla tenga sobreaprovisionamiento. Para definir con más detalle si necesita reducir el número de WCU y RCU, debe revisitar las demás lecturas en los intervalos.
Cuando las tablas contienen varios intervalos de uso bajo, puede beneficiarse mucho del uso de políticas de escalado automático, ya sea programando el escalado automático o simplemente configurando las políticas de escalado automático predeterminadas para la tabla, que se basan en la utilización.
Si tiene una carga de trabajo con una relación de limitación entre baja utilización y alta (Max(ThrottleEvents)/Min(ThrottleEvents) en el intervalo), esto podría ocurrir cuando tenga una carga de trabajo muy elevada, en la que el tráfico aumente considerablemente durante algunos días (u horas), pero en general el tráfico es continuamente bajo. En estos escenarios, puede resultar beneficioso utilizar el escalado automático programado.
