Autoscaling in Dynamodb with boto3

In this post I will explain how to create table of dynamodb, that will scale in response to increasing requests, for complete details about what happens, read boto3 documentation

tldr : public gist with full code

The problem we were facing at JobTeaser was something you often have to deal when working on Cloud development, which is to properly manage resources on both financial and performance aspects.

We, at JobTeaser use Dynamodb to store ML computed results (as key-value {user_id: [id_offer_1, id_offer_2]}). Our workflow is as follows

• Load huge amount of ML results in dynamodb every night
• Read each of them during the day in order to set up a newsletter

By following the usual method to create tables in Dynamodb, in other words, by setting a low value for Read/Write capacity to save cost would slow down all associated operations. On the other hand, if we set a high value, we waste capacity 90% of the uptime.

The solution we came to was to optimize the performance/cost factor was to use ApplicationAutoScaling client from boto3.

Let’s create a table in dynamodb. To keep things simple, I will just set one key in my example.

We will have to set up values for ReadCapacityUnits and WriteCapacityUnits when creating the table that will be use as hard limit for the corresponding capacity, but this will soon become irrelevant once we start using autoscaling.

table created in AWS console

Now it’s time to begin the autoscaling by setting a lower and upper limit inside which the current capacity can fluctuate.

We do so using

boto3.client(‘application-autoscaling’)

with the following parameters.

• ServiceNamepace as dynamodb¹
• RessourceId is in format “/table/<table_name>”
• the ScalableDimension in this case are ReadCapacityUnits and WriteCapacityUnits but you can only put down one value and keep the other set.

We can now look at the interface and saw that both are marked as autoscaling

And that, is how it should work … But AWS has other plan coming

NOPE !

We still need to do one more thing i.e. havz AWS know when to scale our dynamodb resource and how we want it to do so.

What we need is to define a policy; we have choice between TargetTrackingScaling and StepScaling.

TargetTrackingScaling

This is the most straight forward method and the one I recommend; you will need to specify how much you want to use one resource in normal cases.

• ScalableDimension here dynamodb:table:ReadCapacityUnits or dynamodb:table:WriteCapacityUnits
• TargetValue percent of resource we expect to use in a typical situation
• PredefinedMetricType any existing CloudWatch metric that will be used to indicate if we need to scale up or down

We can now see the alarms created by our policy in CloudWatch.

StepScaling

This is almost the same as the previous except we go into details on how the CloudWatch alarms will be created and the step value for every time we scale up or down.

• ChangeInCapacity: Add or substract to the current capacity (specified at the table creation time) the ScalingAdjustment.
• ExactCapacity: Change the current capacity to the ScalingAdjustment value.
• PercentChangeInCapacity: Multiplies current capacity by the percent in ScalingAdjustment.
• ScalableDimension: Here dynamodb:table:ReadCapacityUnits or dynamodb:table:WriteCapacityUnits.
• TargetValue: Percent of resource we expect to use in normal situations.
• PredefinedMetricType: Any existing CloudWatch metric that will be used to indicate if we need to scale up or down

There is actually a lot more options available like the MetricAggregationType but to keep this article short and simple, we will not go into further detail; you can found more informations in AWS documentation

Conclusion

This helped to reduce greatly the time of our operations and I a second part we will take a look at our metrics and how the two approch differs in terms of result.

1. We need to fill this info because this client is not restricted to dynamodb