amazon-web-services - que - dynamodb en español

¿Cómo escalar automáticamente el rendimiento de Amazon DynamoDB?

Question

Amazon DynamoDB no proporciona capacidades inbuild para ajustar automáticamente el rendimiento basado en Dynamic Load. Proporciona API para aumentar o disminuir el rendimiento. Los clientes se cobran cada hora por el rendimiento de lectura y escritura aprovisionado.

¿Cuáles son las diferentes formas de alterar el rendimiento de dynamodb y lograr beneficios de ahorro de costos?

Answer 1

AWS agregó el soporte nativo de escalado automático para DynamoDB en junio de 2017. El siguiente código ( fuente ) proporciona un ejemplo de cómo configurar escalado automático utilizando el Java SDK:

package com.amazonaws.codesamples.autoscaling;

import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClient;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsResult;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesResult;
import com.amazonaws.services.applicationautoscaling.model.MetricType;
import com.amazonaws.services.applicationautoscaling.model.PolicyType;
import com.amazonaws.services.applicationautoscaling.model.PredefinedMetricSpecification;
import com.amazonaws.services.applicationautoscaling.model.PutScalingPolicyRequest;
import com.amazonaws.services.applicationautoscaling.model.RegisterScalableTargetRequest;
import com.amazonaws.services.applicationautoscaling.model.ScalableDimension;
import com.amazonaws.services.applicationautoscaling.model.ServiceNamespace;
import com.amazonaws.services.applicationautoscaling.model.TargetTrackingScalingPolicyConfiguration;

public class EnableDynamoDBAutoscaling {

    static AWSApplicationAutoScalingClient aaClient = new AWSApplicationAutoScalingClient();

    public static void main(String args[]) {

        ServiceNamespace ns = ServiceNamespace.Dynamodb;
        ScalableDimension tableWCUs = ScalableDimension.DynamodbTableWriteCapacityUnits;
        String resourceID = "table/TestTable";

        // Define the scalable target
        RegisterScalableTargetRequest rstRequest = new RegisterScalableTargetRequest()
            .withServiceNamespace(ns)
            .withResourceId(resourceID)
            .withScalableDimension(tableWCUs)
            .withMinCapacity(5)
            .withMaxCapacity(10)
            .withRoleARN("SERVICE_ROLE_ARN_GOES_HERE");

        try {
            aaClient.registerScalableTarget(rstRequest);
        } catch (Exception e) {
            System.err.println("Unable to register scalable target: ");
            System.err.println(e.getMessage());
        }

        // Verify that the target was created
        DescribeScalableTargetsRequest dscRequest = new DescribeScalableTargetsRequest()
            .withServiceNamespace(ns)
            .withScalableDimension(tableWCUs)
            .withResourceIds(resourceID);

        try {
            DescribeScalableTargetsResult dsaResult = aaClient.describeScalableTargets(dscRequest);
            System.out.println("DescribeScalableTargets result: ");
            System.out.println(dsaResult);
            System.out.println();
        } catch (Exception e) {
            System.err.println("Unable to describe scalable target: ");
            System.err.println(e.getMessage());
        }

        System.out.println();

        // Configure a scaling policy
        TargetTrackingScalingPolicyConfiguration targetTrackingScalingPolicyConfiguration = 
            new TargetTrackingScalingPolicyConfiguration()
            .withPredefinedMetricSpecification(
                new PredefinedMetricSpecification()
                .withPredefinedMetricType(MetricType. DynamoDBWriteCapacityUtilization))
            .withTargetValue(50.0)
            .withScaleInCooldown(60)
            .withScaleOutCooldown(60);

        // Create the scaling policy, based on your configuration
        PutScalingPolicyRequest pspRequest = new PutScalingPolicyRequest()
            .withServiceNamespace(ns)
            .withScalableDimension(tableWCUs)
            .withResourceId(resourceID)
            .withPolicyName("MyScalingPolicy")
            .withPolicyType(PolicyType.TargetTrackingScaling)
            .withTargetTrackingScalingPolicyConfiguration(targetTrackingScalingPolicyConfiguration);

        try {
            aaClient.putScalingPolicy(pspRequest);
        } catch (Exception e) {
            System.err.println("Unable to put scaling policy: ");
            System.err.println(e.getMessage());
        }

        // Verify that the scaling policy was created
        DescribeScalingPoliciesRequest dspRequest = new DescribeScalingPoliciesRequest()
            .withServiceNamespace(ns)
            .withScalableDimension(tableWCUs)
            .withResourceId(resourceID);

        try {
            DescribeScalingPoliciesResult dspResult = aaClient.describeScalingPolicies(dspRequest);
            System.out.println("DescribeScalingPolicies result: ");
            System.out.println(dspResult);
        } catch (Exception e) {
            e.printStackTrace();
            System.err.println("Unable to describe scaling policy: ");
            System.err.println(e.getMessage());
        }            
    }
}

Este código requiere que suministre un ARN para un rol de servicio de escalamiento automático de aplicaciones válido. Reemplace SERVICE_ROLE_ARN_GOES_HERE con el ARN actual.

Answer 2

AWS agregó el soporte nativo de escalado automático para DynamoDB en junio de 2017. Vea el anuncio here .

Puede configurar este código de uso ( ejemplo de Java SDK ), pero si tiene pocas tablas, puede usar Management Console . Haga clic en la configuración de su tabla y seleccione la pestaña Capacidad . La siguiente imagen muestra cuáles son sus opciones:

Answer 3

Acabo de descubrir este proyecto que autoescalará hacia arriba y hacia abajo su Dynamodb y se ve mejor que Dynamic Dynamo, porque usa funciones Lambda en lugar de instancias EC2:

https://github.com/channl/dynamodb-lambda-autoscale

• Proceso de instalación de 5 minutos
• Diseño sin servidor
• Código flexible sobre el estilo de configuración
• Tabla de autoescala e índices secundarios globales
• Escala automática de varias tablas
• Escala automática por configuración fija
• Autoscala por utilización de la capacidad aprovisionada
• Métrica de escala automática por aceleración
• Optimizado para grandes picos en el uso y problemas de teclas de acceso rápido incorporando métricas de eventos acelerados
• Rendimiento optimizado utilizando consultas concurrentes
• RateLimitedDecrement impuesta por AWS
• Estadísticas a través de ''medido''
• Configuración de credenciales de AWS a través de ''dotenv''
• Paquete optimizado de lambda a través de ''webpack''
• Código ES7
• Cobertura de control de tipo estático 100% Flow

Answer 4

Agregué nuevas características a Rockeee Dynamic DynamoDB Lambda. Puedes ver este proyecto:

https://github.com/touchvie/dynamic-dynamodb-lambda

• Soporte del Índice Secundario Global
• Habilitar / deshabilitar la escalada automática de lectura / escritura en el archivo config json
• Throttle Events en CloudWatch support
• Habilitar / Deshabilitar la lectura de acelerador-lectura / acelerador-escritura en el archivo config json
• Prueba agregada a lambda

Espero que pueda ayudarte.

Answer 5

Ahora que AWS ha anunciado la ejecución programada de los servicios de lambda, estos parecen ser una excelente opción para realizar escalas automáticas basadas en el tiempo. Escribí un ejemplo de cómo usar esto en medio . El código de ejemplo está en github.

Answer 6

Amazon acaba de agregar autoescalado para dynamodb, mira los detalles here

Answer 7

Creo que otras respuestas han hecho un gran trabajo, pero tengo un enfoque diferente para autoescalar DynamoDB de una manera impulsada por eventos al aprovechar las alarmas de CloudWatch y la operación UpdateTable de UpdateTable para cambiar la capacidad de aprovisionamiento. El siguiente enfoque no solo ayuda a reducir costos, sino también a aumentar la capacidad para cargas inesperadas.

Resumen:

Configure las alarmas de CloudWatch en las métricas DynamoDB para alertarlo en función de los umbrales y enviar las alertas a una cola SQS a través del tema SNS. Un proceso daemon que sondee la cola SQS puede procesar esas alertas y cambiar la capacidad aprovisionada de la tabla utilizando la operación UpdateTable de UpdateTable y actualizar los umbrales de alarma de CloudWatch.

Versión detallada:

Tenga en cuenta que este enfoque requeriría 1. Comprensión de los servicios de AWS como CloudWatch, SNS, SQS 2. Buena cantidad de tiempo para implementar en su lenguaje de programación favorito 3. Mantener un daemon para procesar los mensajes de SQS y cambiar la capacidad de suministro.

Configuración de una sola vez:

1. Cree alarmas de CloudWatch en las unidades ConsumedWriteCapacityUnits y ConsumedReadCapacityUnits de su tabla DynamoDB. Puedes usar esta documentation .
2. Configure las alarmas de CloudWatch para alertar sobre un tema de SNS . Cree una cola AWS SQS y suscríbase a la cola para recibir alertas del tema SNS.
3. Escriba un daemon en cualquier lenguaje de programación para sondear la cola de SQS y procesar todas las alertas. AWS tiene SDKs en varios idiomas, por lo que elegir cualquiera de esos idiomas evitaría escribir gran cantidad de código para comunicarse con los servicios de AWS.

Algoritmo de Daemon:

1. Para cada mensaje SQS que recibe, calcule la nueva capacidad provisionada que se utilizará y emita una operación UpdateTable con el nuevo valor.
2. Actualice la alarma de CloudWatch con los nuevos umbrales, si es necesario.

Puede usar el enfoque anterior para ampliar o disminuir. Por ejemplo, mantenga el umbral de alarma de CloudWatch al 80% de ProvisionedWriteCapacityUnits y cada vez que el uso cruza el 80%, aumente la capacidad y establezca el umbral de alarma en 80% del valor nuevo. De manera similar, puede reducir la escala cuando el consumo cae por debajo del x%.

Aunque este es el punto crucial, habría muchos puntos para considerar en una solución de calidad de producción.

1. Comprenda las particiones de DynamoDB y los problemas de las teclas de acceso rápido.
2. Tenga en cuenta todos los límites de DynamoDB .
3. Restricciones en no.of escalaciones por día UTC.
4. UpdateTable las múltiples operaciones de UpdateTable .

Finalmente, Neptune.io proporciona una solución SaaS empaquetada para autoescalar DynamoDB utilizando esta arquitectura. Ver http://blog.neptune.io/one-click-autoscaling-of-dynamodb/ y http://blog.neptune.io/dos-and-donts-of-dynamodb-autoscaling/ para leer sobre eso.

PD: trabajo para Neptune. Y puedo ayudarlo si necesita más detalles sobre la implementación.

Answer 8

Directrices para el script de escalamiento automático de DynamoDB:

Los clientes se cobran por hora para el rendimiento de lectura y escritura aprovisionado. A continuación se muestra el precio de Amazon Dynamo DB para la UE (Región de Irlanda).

• Rendimiento de escritura: $ 0.00735 por hora por cada 10 unidades de capacidad de escritura • Rendimiento de lectura: $ 0.00735 por hora por cada 50 unidades de capacidad de lectura

Amazon Dynamo DB no ofrece capacidades in-build para ajustar automáticamente el rendimiento en función de la carga dinámica. Proporciona API para aumentar o disminuir el rendimiento con algunas restricciones, como el rendimiento que se puede reducir dos veces en un día y aumentar en cualquier momento del día.

¿Cuál será la factura mensual de una tabla de producción para una capacidad de lectura fija de 2.000 lecturas / segundo y 2.000 escritas / segundas durante 24 horas?

Cálculo: $ 0.00735 X 24 horas X 200 X 30 días {escribir el costo del mes} + $ 0.00735X 24 horas X 40 X 30 días {leer el costo del mes} = 1058.4+ 211.68 = Remedio 1270 $ / mes.

Pautas para la utilidad de escritura {amazon supported programming languages} que ajustan el rendimiento de la tabla y reducen las facturas mensuales.

(A) Valor inicial: Básicamente, aquí debe observar y decidir el rendimiento de lectura y escritura de la tabla como valor de inicialización después de analizar el uso promedio considerando 15 días o 1 mes de carga y agregar X% extra para lectura e Y% extra para escritura la parte superior para soportar cargas inesperadas. Rendimiento de lectura / escritura inicial = calcular el rendimiento de lectura basado en el uso promedio + X {leer}% o Y {escribir}% X e Y puede ser cualquier cosa entre 10% y 30% según la observación.

(B) Forma de carga máxima: las alertas en las tablas pueden configurarse cuando la carga llega al 50% o 60% del rendimiento aprovisionado, se pueden tomar las medidas necesarias como API de incremento de llamadas para aumentar el rendimiento entre 30% y 50% del rendimiento de la provisión . *

(C) Moldeado manual: Para carga pesada conocida como carga por lotes / temporada festiva, el rendimiento debe ajustarse manualmente al 200% - 300% extra de las operaciones diarias normales hasta que la carga se complete * * Una vez que finalice el horario comercial o la carga. El rendimiento debería reducirse hasta el valor inicial.

Nota: Reader puede calcular el ahorro mensual considerando 1,000 de lectura / escritura durante 16 horas. + 2,000 de lectura / escritura durante 8 horas, siempre que la utilidad esté en su lugar.

Answer 9

Jeff Bar escribió recientemente un blog en el blog oficial de AWS: "Auto Scale DynamoDB con Dynamic DynamoDB":

https://aws.amazon.com/blogs/aws/auto-scale-dynamodb-with-dynamic-dynamodb/

Introdujo Dynamic DynamoDB, una herramienta de código abierto desarrollada por un desarrollador independiente para manejar esto automáticamente con la plantilla de CloudFormation.

Answer 10

La respuesta de Chris es una respuesta precisa. Solo para agregar algunos puntos de la experiencia previa con DynamoDB ...

La situación con DynamoDB es diferente de EC2. El servicio de cálculo elástico tiene una API compatible directamente como un servicio web de Amazon para permitirle programar cómo escalar hacia arriba o hacia abajo según alguna lógica, como la cantidad de demanda existente. Usted programa esto definiendo un umbral de monitoreo y activando automáticamente la creación o eliminación de instancias en un grupo.

Los servidores de datos no funcionan de la misma manera con los desencadenadores para ajustar su capacidad. Pero la capacidad de DynamoDB es muy flexible y puede controlarse como ha señalado Chris. La API para proporcionar esto es lo suficientemente buena como para hacer que uno cambie. O cambios manuales equivalentes desde la consola.

Las diferentes combinaciones de idiomas para crear y actualizar acciones con DynamoDB están aquí ...

http://docs.aws.amazon.com/cli/latest/reference/dynamodb/index.html

La operación importante para modificar la capacidad está aquí ...

http://docs.aws.amazon.com/cli/latest/reference/dynamodb/update-table.html

Por lo tanto, esto le brinda la posibilidad de aumentar o disminuir las ReadCapacityUnits o WriteCapacityUnits de ProvisionedThputput.

Lo cual está bien para un cambio predicho o único. Pero eso no es lo mismo que una herramienta de flexibilidad que le permita activar el cambio automáticamente.

Programáticamente, lo que probablemente desee hacer es ajustar la capacidad en respuesta al cambio en la utilización en el intervalo de tiempo anterior. En particular, es posible que necesite escalar rápidamente en respuesta a un aumento en la demanda al definir un intervalo de tiempo apropiado y un umbral inferior y superior para activar.

Aquí se describe una solución más completa para lograr esto ...

https://aws.amazon.com/blogs/aws/auto-scale-dynamodb-with-dynamic-dynamodb/

La solución es mantenida por Sebastian Dahlgren y se puede encontrar con todas las instrucciones en ...

https://github.com/sebdah/dynamic-dynamodb

Veo que la versión actual es 1.18.5, que es más reciente que cuando la utilicé por última vez.

A juzgar por las versiones anteriores, es simple de configurar mediante un archivo de estilo de propiedades dynamodb.conf ...

Habiendo proporcionado las credenciales y la región, los ajustes más importantes son

• check-interval : para probar el rendimiento en segundos
• min-provisioned-reads, max-provisioned-reads; reads-upper-threshold, reads-lower-threshold; increase-reads-with, decrease-reads-with min-provisioned-reads, max-provisioned-reads; reads-upper-threshold, reads-lower-threshold; increase-reads-with, decrease-reads-with -These are all porcentages
• min-provisioned-writes, max-provisioned-writes; writes-upper-threshold, writes-lower-threshold; increase-writes-with, decrease-writes-with min-provisioned-writes, max-provisioned-writes; writes-upper-threshold, writes-lower-threshold; increase-writes-with, decrease-writes-with - Estos son todos porcentajes

¿Esta información está actualizada?

Bien, si mira http://aws.amazon.com/new/ verá un solo cambio reciente que afecta a DynamoDB y afecta los documentos almacenados. La entrada para Dynamic DynamoDB es la última entrada publicada que trata de acciones de escala. Por lo tanto, esta es la capacidad de escalado automático de DynamoDB mejor conservada en este momento.

Answer 11

Puede gestionar el rendimiento de forma programática a través de la API de la tabla de actualizaciones o manualmente a través de la consola.

También hay herramientas como Dynamic DynamoDB , aunque también podría ejecutar su propia versión: usaría la API updateTable y se ejecutaría un proceso en segundo plano para detectar esas circunstancias y llamar a updateTable según sea necesario.

Algunas cosas a tener en cuenta al cambiar la escala de DynamoDB:

1. Se le factura por el rendimiento asignado, ya sea que lo esté usando o no.
2. Si amplía, Dynamo puede asignar nuevas particiones para usted, pero no las eliminará cuando se reduzca. Esto puede provocar un problema inesperado de la tecla hash caliente en la que tiene muchas particiones pero un rendimiento muy bajo en cada una de ellas.