Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
En esta sección se ofrece información general sobre cómo evaluar si dispone de un aprovisionamiento de tamaño adecuado en sus tablas de Amazon Keyspaces. A medida que evolucione la carga de trabajo, debe modificar los procedimientos operativos de manera adecuada, en particular si la tabla de Amazon Keyspaces está configurada en modo aprovisionado y corre el riesgo de sobreaprovisionar o subaprovisionar sus tablas.
Los procedimientos que se describen en esta sección requieren información estadística que se debería capturar de tablas de Amazon Keyspaces que sean 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 su 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, para las tablas de Amazon Keyspaces puede configurar las unidades de capacidad de lectura (RCUs) y las unidades de capacidad de escritura (WCU) de forma independiente.
Temas
Recuperación de métricas de consumo de sus tablas de Amazon Keyspaces
Para evaluar la capacidad de la tabla, supervise las siguientes CloudWatch métricas y seleccione la dimensión adecuada para recuperar la información de la tabla:
| Unidades de capacidad de lectura | Unidades de capacidad de escritura |
|---|---|
|
|
|
|
|
|
|
|
|
Puede hacerlo mediante el AWS CLI o el AWS Management Console.
Antes de recuperar las métricas de consumo de la tabla, debes empezar por capturar algunos puntos de datos históricos mediante la CloudWatch API.
Comience por crear dos archivos: write-calc.json y read-calc.json. Estos archivos representan los cálculos de la tabla. Debe actualizar algunos de los campos, como se indica en la tabla siguiente, para que coincidan con su entorno.
nota
Si el nombre de la tabla no es único dentro de su cuenta, deberá especificar también el nombre del espacio de claves.
| Nombre del campo | Definición | Ejemplo |
|---|---|---|
<table-name> |
El nombre de la tabla que vaya a analizar | SampleTable |
<period> |
El periodo 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 ISO86 01 | 2022-02-21T23:00:00 |
<end-time> |
El final del intervalo de evaluación, especificado en formato ISO86 01 | 2022-02-22T06:00:00 |
El archivo de cálculos de escritura recupera el número de WCU aprovisionadas y consumidas en el periodo de tiempo para el intervalo de fechas especificado. También genera un porcentaje de utilización que puede utilizarse para el análisis. El contenido completo del archivo write-calc.json debería asemejarse al del siguiente ejemplo.
{
"MetricDataQueries": [
{
"Id": "provisionedWCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Cassandra",
"MetricName": "ProvisionedWriteCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": "<table-name>"
}
]
},
"Period": <period>,
"Stat": "Average"
},
"Label": "Provisioned",
"ReturnData": false
},
{
"Id": "consumedWCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Cassandra",
"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": "<end-time>",
"ScanBy": "TimestampDescending",
"MaxDatapoints": 24
} El archivo de cálculos de lectura utiliza una métrica similar. Este archivo recupera cuántos RCUs se aprovisionaron y consumieron durante el período correspondiente al intervalo de fechas especificado. El contenido del archivo read-calc.json debería asemejarse al del siguiente ejemplo.
{
"MetricDataQueries": [
{
"Id": "provisionedRCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Cassandra",
"MetricName": "ProvisionedReadCapacityUnits",
"Dimensions": [
{
"Name": "TableName",
"Value": "<table-name>"
}
]
},
"Period": <period>,
"Stat": "Average"
},
"Label": "Provisioned",
"ReturnData": false
},
{
"Id": "consumedRCU",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Cassandra",
"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 creados los archivos, puede empezar a recuperar los datos de utilización.
-
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 es una serie de puntos de datos en formato JSON que pueden utilizarse para el análisis. Sus resultados dependen del número de puntos de datos que haya especificado, del periodo y de sus propios datos específicos de carga de trabajo. Podría asemejarse al ejemplo 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 el valor MaxDatapoints, que de forma predeterminada está fijado en 24 en el script. Este representa un punto de datos por hora y 24 por día.
Identificación de tablas de DynamoDB subaprovisionadas
Para la mayoría de las cargas de trabajo, una tabla se considera subaprovisionada cuando consume de forma continua más del 80 % de la capacidad aprovisionada.
La capacidad de ráfaga es una función de Amazon Keyspaces que permite a los clientes consumir temporalmente más RCUs/de WCUs lo que se había aprovisionado originalmente (más del 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 es limitada. Para obtener más información, consulte Uso eficaz de la capacidad de ampliación en Amazon Keyspaces. Tan pronto como la capacidad no utilizada RCUs y WCUs se agote, se pueden producir errores de rendimiento de baja capacidad si intentas consumir más capacidad de la aprovisionada. Cuando el tráfico de su aplicación se acerque a la tasa de utilización del 80 %, el riesgo de experimentar eventos de error de baja capacidad de rendimiento será 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.
Existen escenarios especiales en los que los datos se sesgan al analizarlos a diario o semanalmente. Por ejemplo, con aplicaciones estacionales que tienen picos de utilización durante las horas de trabajo (pero luego caen casi a cero fuera de las horas de trabajo), podría beneficiarse de programar el escalado automático de la aplicación, donde usted especifica las horas del día (y los días de la semana) para aumentar la capacidad aprovisionada, así como cuándo reducirla. En vez de optar por una mayor capacidad para poder cubrir las horas de mayor actividad, también podría beneficiarse de las configuraciones de escalado automático de tablas de Amazon Keyspaces si su estacionalidad es menos pronunciada.
Identificación de tablas de DynamoDB sobreaprovisionadas
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 es necesario reducir el número de RCUs WCUs y RCUs, debería revisar las demás lecturas de los intervalos.
Si su tabla contiene varios intervalos de baja utilización, puede beneficiarse del uso de políticas de Application Auto Scaling, ya sea programando Application Auto Scaling o simplemente configurando las políticas de Application Auto Scaling predeterminadas para la tabla que se basen en la utilización.
Si tiene una carga de trabajo con un índice de utilización bajo y una relación de aceleración alta (máx. (ThrottleEvents) /minuto (ThrottleEvents) en el intervalo), esto podría ocurrir si tiene una carga de trabajo muy intensa, en la que el tráfico aumenta significativamente en días (o momentos del día) específicos, pero por lo demás es constantemente bajo. En estos escenarios, podría ser beneficioso utilizar Application Auto Scaling programado.
