Как автоматически масштабировать пропускную способность Amazon DynamoDB?

Amazon только что добавила автомасштабирование для dynamodb, см. подробности здесь

Я только что обнаружил этот проект, который будет автоматически масштабировать ваш Dynamodb и выглядит лучше, чем динамическое Динамо, потому что он использует лямбда-функции, а не экземпляры EC2:

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

• 5-минутный процесс установки
• Serverless дизайн
• гибкий код над стилем конфигурации
• таблица автомасштабирования и глобальные вторичные индексы
• автомасштабирование несколько таблиц
• масштабирование по фиксированным настройкам
• автомасштабирование по выделенной мощности
• автоматическое масштабирование по метрикам событий
• оптимизировано для больших всплесков в использовании и горячих клавишах, включив дроссельные метрики событий
• оптимизированная производительность с использованием параллельных запросов
• RateLimitedDecrement в соответствии с AWS
• статистика через 'measured'
• конфигурация учетных данных AWS через 'dotenv'
• оптимизированный лямбда-пакет через 'webpack'
• код ES7
• 100% поток статический тип проверки покрытия

вы можете управлять пропускной способностью программно через в API updateTable или вручную через консоль.

есть также такие инструменты, как Динамический DynamoDB, хотя вы также можете свернуть свою собственную версию: вы будете использовать API updateTable и иметь некоторый фоновый процесс, запущенный для обнаружения этих обстоятельств и вызова updateTable по мере необходимости.

некоторые вещи, чтобы следить за при изменении масштаба DynamoDB:

1. вы получаете счет за выделенную пропускную способность, используете ли вы ее на самом деле или нет.
2. когда вы масштабируетесь, Dynamo может выделить вам новые разделы , но он не удалит их, когда он масштабируется. Это может привести к неожиданным Горячий Ключ хэша проблема, когда у вас много разделов, но очень низкая пропускная способность на каждом из них.

Джефф бар недавно написал блог в официальном блоге AWS: "Auto Scale DynamoDB With Dynamic DynamoDB":

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

Он представил Dynamic DynamoDB, инструмент с открытым исходным кодом, построенный независимым разработчиком для автоматической обработки этого шаблона CloudFormation.

Я думаю, что другие ответы проделали большую работу, но у меня есть другой подход к масштабированию DynamoDB в событии, управляемом способом, используя сигналы CloudWatch и DynamoDB UpdateTable операция по изменению емкости. Следующий подход помогает не только снизить затраты, но и увеличить емкость для непредвиденных нагрузок.

резюме:

настройка CloudWatch тревоги на DynamoDB метрики, чтобы предупредить вас на основе порогов и нажмите оповещения в очередь SQS через тему SNS. Процесс демона, который опрашивает очередь SQS, может обрабатывать эти предупреждения и изменять подготовленную емкость таблицы с помощью DynamoDB UpdateTable управление и обновление порогов тревоги CloudWatch.

Полная версия:

обратите внимание,что этот подход потребует 1. Понимание сервисов AWS, таких как CloudWatch, SNS, SQS 2. Хорошее количество времени для реализации на вашем любимом языке программирования 3. Поддержка демона для обработки сообщений SQS и изменения подготовленной емкости.

один раз настройка:

1. создать CloudWatch тревоги на ConsumedWriteCapacityUnits и ConsumedReadCapacityUnits метрики вашей таблицы DynamoDB. Вы можете использовать это документация.
2. настройка сигналов CloudWatch чтобы предупредить SNS темы. Создайте очередь AWS SQS и подпишитесь на нее для получения оповещений из раздела SNS.
3. писать демона в любой язык программирования для опроса очереди SQS и обработки всех предупреждений. AWS имеет SDKs на нескольких языках, поэтому выбор любого из этих языков позволит избежать написания большого количества кода для связи с сервисами AWS.

Демон:

1. для каждого сообщения SQS, которое он получает, вычислите новую подготовленную емкость для использования и выдайте UpdateTable операция с новым значением.
2. обновите будильник CloudWatch с помощью новые пороговые значения, если требуется.

вы можете использовать выше подход к масштабированию вверх или вниз. Например, поддерживать порог тревоги CloudWatch на уровне 80% от ProvisionedWriteCapacityUnits и каждый раз, когда использование пересекает 80%, увеличьте емкость и установите порог тревоги до 80% из нового значения. Аналогично, вы можете уменьшить масштаб, когда потребление падает ниже x%.

хотя это суть, было бы много пунктов, который нужно рассматривать в качестве продукции решение.

1. понять о разделах DynamoDB и горячих ключевых проблемах.
2. будьте в курсе всего пределы DynamoDB.
3. ограничения на no.снижения масштаба в день UTC.
4. пакетная обработка нескольких UpdateTable операции.

наконец, Нептун.Ио предоставляет упакованное решение SaaS для автоматического масштабирования DynamoDB с помощью этой архитектуры. Видеть http://blog.neptune.io/one-click-autoscaling-of-dynamodb/ и http://blog.neptune.io/dos-and-donts-of-dynamodb-autoscaling/ для некоторого чтения на этом.

P. S: Я работаю на Нептун. И, я могу помочь вам, если вам нужно больше деталей реализации.

Я добавил новые функции в Rockeee Dynamic DynamoDB Lambda. Вы можете увидеть этот проект:

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

• Поддержка глобального вторичного индекса
• включить/отключить авто масштабирование чтения / записи в файле конфигурации json
• события дроссельной заслонки в поддержке CloudWatch
• включить / отключить дроссель-чтение / дроссель-запись проверки в файле конфигурации json
• добавлен тест для лямбда!--8-->

Я надеюсь, что это может помочь вам.

рекомендации для сценария автоматического масштабирования DynamoDB:

клиенты взимаются ежечасно за подготовленную пропускную способность чтения и записи. Ниже приведена цена Amazon Dynamo DB для ЕС (регион Ирландия).

• объем записи: $ 0.00735 в час для каждых 10 блоков емкости записи * Пропускная способность чтения: $ 0.00735 в час за каждые 50 единиц емкости чтения

Amazon Dynamo DB не предоставляет встроенных возможностей автоматической настройки пропускной способности на основе динамических Нагрузка. Он предоставляет API для увеличения или уменьшения пропускной способности с некоторыми ограничениями, такими как пропускная способность может быть уменьшена дважды в день и увеличена в любое время дня.

Что будет ежемесячным счетом таблицы продукции для фиксированной прочитанной емкости 2,000 прочитанной / во-вторых и 2,000 пишут/во-вторых на 24 часа?

расчет: $0.00735 X 24hrs X 200 X 30days {стоимость записи за месяц} + $0.00735 X 24hrs X 40 X 30 days {стоимость чтения за месяц} = 1058.4+ 211.68 = фиксированный 1270 $ / месяц.

рекомендации по написанию утилиты {поддерживаемые amazon языки программирования}, которые регулируют пропускную способность таблицы и сокращают ежемесячные счета.

(A) начальное значение: в основном, здесь вы должны смотреть и решать пропускную способность чтения и записи для таблицы в качестве значения инициализации после анализа среднего использования с учетом 15 дней или 1 месяца нагрузки и добавить X% дополнительно для чтения и Y% дополнительно для записи сверху, чтобы выдержать неожиданную нагрузку. Начальная пропускная способность чтения/записи = вычислить чтение пропускная способность на основе среднего использования +X {read} % или Y {write} % X & Y может быть что угодно между 10% и 30% на основе наблюдения.

(B) формирование пиковой нагрузки: предупреждение по таблицам может быть установлено, когда нагрузка достигает от 50% до 60% подготовленной пропускной способности, необходимые действия могут быть предприняты, например, вызов API увеличения пропускной способности для увеличения пропускной способности от 30% до 50% пропускной способности.*

(C) ручной формировать: для известной тяжелой нагрузки как сезон нагрузки серии / фестиваля, объем должен быть установлен вручную к 200% - 300% экстра нормальных ежедневных деятельностей до тех пор пока нагрузка не будет закончена* * После окончания рабочего времени или нагрузки. Пропускная способность должна уменьшаться до начального значения.

Примечание: читатель может высчитать ежемесячные сбережения рассматривая 1,000 прочитанное / пишет на 16 hrs. + 2,000 чтение/запись в течение 8 часов, при условии утилиты на месте.

теперь, когда AWS объявила о запланированном выполнении лямбда-сервисов, они отлично подходят для автоматического масштабирования на основе времени. Я написал пример того, как использовать это на medium. пример кода находится на github.

AWS добавила встроенную поддержку автоматического масштабирования для DynamoDB в июне 2017 года. Смотрите объявление здесь.

вы можете настроить это с помощью код (Java SDK пример), но если у вас есть несколько таблиц, вы можете использовать Консоль. Нажмите в конфигурации таблицы и выберите емкости tab. На следующем рисунке показано, каковы ваши варианты:

AWS добавила встроенную поддержку автоматического масштабирования для DynamoDB в июне 2017 года. Следующий код (источник) предоставляет пример настройки автоматического масштабирования с помощью 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());
        }            
    }
}

этот код требует, чтобы вы предоставили ARN для допустимой роли службы автоматического масштабирования приложения. Замените SERVICE_ROLE_ARN_GOES_HERE фактическим ARN.