web-dev-qa-db-fra.com

Comment faire évoluer automatiquement le débit d'Amazon DynamoDB?

Amazon DynamoDB ne fournit pas de fonctionnalités intégrées pour régler automatiquement le débit en fonction de la charge dynamique. Il fournit une API pour augmenter ou diminuer le débit. Les clients sont facturés sur une base horaire pour le débit de lecture et d'écriture provisionné.

Quelles sont les différentes façons de modifier le débit de dynamodb et de réaliser des économies de coûts?

amazon-web-servicesamazon-dynamodb
29
kartik

La réponse de Chris est une réponse exacte. Juste pour ajouter quelques points d'expérience antérieure avec DynamoDB…

La situation avec DynamoDB est différente de EC2. Le service de calcul élastique dispose d'une API prise en charge directement en tant que service Web par Amazon pour vous permettre de programmer comment augmenter ou diminuer en fonction d'une logique telle que la quantité de demande. Vous programmez cela en définissant un seuil de surveillance et en déclenchant automatiquement la création ou la suppression d'instances dans un groupe.

Les serveurs de données ne fonctionnent pas de la même manière avec des déclencheurs pour ajuster leur capacité. Mais la capacité de DynamoDB est très flexible et peut être contrôlée comme l'a souligné Chris. L'API pour fournir cela est suffisamment bonne pour apporter des modifications ponctuelles. Ou des modifications manuelles équivalentes depuis la console.

Les différentes liaisons de langage pour programmer des actions de création et de mise à jour avec DynamoDB sont ici…

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

L'opération importante pour modifier la capacité est ici…

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

Ainsi, cela vous donne la possibilité d'augmenter ou de diminuer les ReadCapacityUnits ou WriteCapacityUnits de ProvisionedThroughput.

Ce qui est bien pour un changement prévu ou ponctuel. Mais ce n'est pas la même chose qu'un outil de flexibilité pour vous permettre de déclencher le changement automatiquement.

Par programme, ce que vous êtes le plus susceptible de vouloir faire est d'ajuster la capacité en réponse au changement d'utilisation dans l'intervalle de temps précédent. En particulier, vous devrez peut-être évoluer rapidement en réponse à une augmentation de la demande en définissant une tranche de temps appropriée et un seuil inférieur et supérieur à déclencher.

Une solution plus complète pour y parvenir est décrite ici…

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

La solution est maintenue par Sebastian Dahlgren et peut être trouvée avec toutes les instructions sur…

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

Je vois que la version actuelle est la 1.18.5 qui est plus récente que la dernière fois que je l'ai utilisée.

A en juger par les versions précédentes, il est simple à configurer au moyen d'un fichier de style de propriétés dynamodb.conf…

Après avoir fourni les informations d'identification et la région, les paramètres les plus cruciaux sont

  • check-interval - pour tester le débit en quelques secondes
  • min-provisioned-reads, max-provisioned-reads; reads-upper-threshold, reads-lower-threshold; increase-reads-with, decrease-reads-with - Ce sont tous des pourcentages
  • min-provisioned-writes, max-provisioned-writes; writes-upper-threshold, writes-lower-threshold; increase-writes-with, decrease-writes-with - Ce sont tous des pourcentages

Ces informations sont-elles à jour?

Eh bien, si vous regardez http://aws.Amazon.com/new/ vous ne verrez qu'une seule modification récente supplémentaire affectant DynamoDB qui affecte les documents stockés. L'entrée pour Dynamic DynamoDB est la dernière entrée publiée traitant des actions de mise à l'échelle. Il s'agit donc de la capacité de mise à l'échelle automatique DynamoDB la mieux conservée à l'heure actuelle.

24
johnz

Amazon vient d'ajouter la mise à l'échelle automatique pour dynamodb, voir les détails ici

14
NSA

Je viens de découvrir ce projet qui mettra à l'échelle automatique votre Dynamodb et est meilleur que Dynamic Dynamo, car il utilise des fonctions Lambda plutôt que des instances EC2:

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

  • Processus d'installation de 5 minutes
  • Conception sans serveur
  • Code flexible sur le style de configuration
  • Table de mise à l'échelle automatique et index secondaires globaux
  • Mise à l'échelle automatique de plusieurs tables
  • Mise à l'échelle automatique par paramètres fixes
  • Mise à l'échelle automatique par utilisation de la capacité provisionnée
  • Mise à l'échelle automatique par des mesures d'événements limitées
  • Optimisé pour les pics importants d'utilisation et les problèmes de raccourcis clavier en incorporant des mesures d'événements limitées
  • Performances optimisées à l'aide de requêtes simultanées
  • RateLimitedDecrement tel qu'imposé par AWS
  • Statistiques via "mesuré"
  • Configuration des informations d'identification AWS via "dotenv"
  • Package lambda optimisé via 'webpack'
  • Code ES7
  • 100% Flow couverture de vérification de type statique
13
Jesús Carrera

Vous pouvez gérer le débit par programme via pdateTable API ou manuellement via la console.

Il existe également des outils tels que Dynamic DynamoDB , bien que vous puissiez également lancer votre propre version: vous utiliseriez l'API updateTable et un processus d'arrière-plan serait en cours d'exécution pour détecter ces circonstances et appeler updateTable si nécessaire.

Certaines choses à surveiller lors du changement d'échelle de DynamoDB:

  1. Vous êtes facturé pour le débit alloué, que vous l'utilisiez ou non.
  2. Lorsque vous augmentez l'échelle, Dynamo peut allouer de nouvelles partitions pour vous, mais il ne les supprimera pas lors de la réduction. Cela peut entraîner un problème inattendu touche de hachage où vous avez beaucoup de partitions mais un débit très faible sur chacune d'entre elles.
8
Krease

Je pense que d'autres réponses ont fait du bon travail, mais j'ai une approche différente de la mise à l'échelle automatique de DynamoDB en fonction des événements en tirant parti des alarmes CloudWatch et de l'opération pdateTable de DynamoDB pour modifier la capacité provisionnée. L'approche suivante aide non seulement à réduire les coûts, mais à augmenter la capacité pour les charges inattendues.

Résumé:

Configurez les alarmes CloudWatch sur les métriques DynamoDB pour vous alerter en fonction des seuils et pousser les alertes vers une file d'attente SQS via la rubrique SNS. Un processus démon qui interroge la file d'attente SQS peut traiter ces alertes et modifier la capacité provisionnée de la table à l'aide de l'opération UpdateTable de DynamoDB et mettre à jour les seuils d'alarme CloudWatch.

Version détaillée:

Veuillez noter que cette approche nécessiterait 1. Compréhension des services AWS tels que CloudWatch, SNS, SQS 2. Bonne quantité de temps pour l'implémentation dans votre langage de programmation préféré 3. Maintenance d'un démon pour traiter les messages SQS et modifier la capacité provisionnée.

Configuration unique:

  1. Créez des alarmes CloudWatch sur les métriques ConsumedWriteCapacityUnits et ConsumedReadCapacityUnits de votre table DynamoDB. Vous pouvez utiliser ceci documentation .
  2. Configurez les alarmes CloudWatch pour alerter un SNS topic. Créez une file d'attente AWS SQS et abonnez-vous pour recevoir des alertes de la rubrique SNS.
  3. Écrivez un démon dans n'importe quel langage de programmation pour interroger la file d'attente SQS et traiter toutes les alertes. AWS a SDK dans plusieurs langues, donc choisir l'une de ces langues éviterait d'écrire beaucoup de code pour communiquer avec les services AWS.

Algorithme démon:

  1. Pour chaque message SQS qu'il reçoit, calculez la nouvelle capacité provisionnée à utiliser et exécutez une opération UpdateTable avec la nouvelle valeur.
  2. Mettez à jour l'alarme CloudWatch avec les nouveaux seuils, si nécessaire.

Vous pouvez utiliser l'approche ci-dessus pour augmenter ou réduire l'échelle. Par exemple, maintenez le seuil d'alarme CloudWatch à 80% de ProvisionedWriteCapacityUnits et chaque fois que l'utilisation dépasse 80%, augmentez la capacité et définissez le seuil d'alarme à 80% de la nouvelle valeur. De même, vous pouvez réduire votre consommation lorsque la consommation tombe en dessous de x%.

Bien que ce soit le nœud, il y aurait beaucoup de points à considérer dans une solution de qualité de production.

  1. Comprendre les partitions DynamoDB et les problèmes de touches de raccourci.
  2. Soyez conscient de tous limites DynamoDB .
  3. Contraintes sur le nombre de réductions d'échelle par jour UTC.
  4. Batch les multiples opérations UpdateTable.

Enfin, Neptune.io fournit une solution SaaS mise à l'échelle automatique de DynamoDB en utilisant cette architecture. Voir http://blog.Neptune.io/one -click-autoscaling-of-dynamodb / et http://blog.Neptune.io/dos-and-donts-of-dynamodb-autoscaling/ pour quelques lectures à ce sujet.

P.S: Je travaille pour Neptune. Et, je peux vous aider si vous avez besoin de plus de détails sur la mise en œuvre.

4
Buchi

Jeff Bar a récemment écrit un blog dans le blog officiel AWS: "Auto Scale DynamoDB With Dynamic DynamoDB":

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

Il a présenté Dynamic DynamoDB, un outil open source construit par un développeur indépendant pour gérer cela automatiquement avec le modèle CloudFormation.

4
Robert Mao

J'ai ajouté de nouvelles fonctionnalités à Rockeee Dynamic DynamoDB Lambda. Vous pouvez voir ce projet:

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

  • Prise en charge de l'indice secondaire mondial
  • Activer/désactiver la mise à l'échelle automatique en lecture/écriture dans le fichier json de configuration
  • Throttle Events dans la prise en charge de CloudWatch
  • Activer/désactiver la vérification de la limitation/lecture/limitation dans le fichier confson json
  • Test ajouté à lambda

J'espère que cela peut vous aider.

3
angulito

Maintenant qu'AWS a annoncé l'exécution planifiée des services lambda, ceux-ci semblent parfaitement adaptés à la mise à l'échelle automatique basée sur le temps. J'ai rédigé un exemple d'utilisation de ce support sur un support . Exemple de code est sur github.

2
quodlibet

AWS a ajouté la prise en charge de la mise à l'échelle automatique native pour DynamoDB en juin 2017. Voir l'annonce ici .

Vous pouvez configurer cela en utilisant du code ( exemple du SDK Java ), mais si vous n'avez que quelques tables, vous pouvez utiliser Console de gestion . Cliquez dans la configuration de votre table et sélectionnez l'onglet Capacité . L'image suivante montre quelles sont vos options:

auto scaling configuration

2
Zanon

Instructions pour le script de mise à l'échelle automatique DynamoDB:

Les clients sont facturés sur une base horaire pour le débit de lecture et d'écriture provisionné. Vous trouverez ci-dessous les tarifs d'Amazon Dynamo DB pour l'UE (région d'Irlande).

• Débit d'écriture: 0,00735 $ par heure pour 10 unités de capacité d'écriture • Débit de lecture: 0,00735 $ par heure pour 50 unités de capacité de lecture

Amazon Dynamo DB ne fournit pas de fonctionnalités intégrées pour régler automatiquement le débit en fonction de la charge dynamique. Il fournit une API pour augmenter ou diminuer le débit avec certaines restrictions comme le débit peut être diminué deux fois par jour et augmenté à tout moment de la journée.

Quelle sera la facture mensuelle d'une table de production pour une capacité de lecture fixe de 2 000 lecture/seconde et 2 000 écriture/seconde pendant 24 heures?

Calcul: 0,00735 $ X 24 heures X 200 X 30 jours {coût d'écriture pour le mois} + 0,00735X 24 heures X 40 X 30 jours {coût de lecture pour le mois} = 1058,4+ 211,68 = fixe 1270 $/mois.

Lignes directrices pour l'écriture d'utilitaires {langages de programmation pris en charge par Amazon} qui ajustent le débit de la table et réduisent les factures mensuelles.

(A) Valeur initiale: Fondamentalement, ici, vous devez regarder et décider du débit de lecture et d'écriture pour la table en tant que valeur d'initialisation après avoir analysé l'utilisation moyenne en considérant 15 jours ou 1 mois de charge et ajouter X% supplémentaire pour la lecture et Y% supplémentaire pour l'écriture. le dessus pour résister à une charge inattendue. Débit de lecture/écriture initial = calculer le débit de lecture en fonction de l'utilisation moyenne + X {lecture}% ou Y {écriture}% X & Y peut être compris entre 10% et 30% selon l'observation.

(B) Peak Load Shaping: l'alerte sur les tables peut être définie comme lorsque la charge atteint 50% à 60% du débit provisionné, les actions nécessaires peuvent être prises comme l'appel de l'API d'incrément de débit pour augmenter le débit entre 30% et 50% du débit de provisionnement. . *

(C) Mise en forme manuelle: pour les charges lourdes connues telles que la charge par lots/la saison des festivals, le débit doit être réglé manuellement sur 200 à 300% supplémentaires des opérations quotidiennes normales jusqu'à la fin de la charge * * Une fois les heures de travail ou la charge terminées. Le débit doit être ramené à sa valeur initiale.

Remarque: Reader peut calculer les économies mensuelles en considérant 1 000 lecture/écriture pendant 16 heures. + 2 000 lecture/écriture pendant 8 heures, utilitaire fourni en place.

2
kartik

AWS a ajouté la prise en charge de la mise à l'échelle automatique native pour DynamoDB en juin 2017. Le code suivant ( source ) fournit un exemple de configuration de la mise à l'échelle automatique à l'aide du SDK Java Java:

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());
        }            
    }
}

Ce code nécessite que vous fournissiez un ARN pour un rôle de service Application Auto Scaling valide. Remplacez SERVICE_ROLE_ARN_GOES_HERE par l'ARN réel.

0
Zanon