Skip to content
This repository has been archived by the owner on Dec 16, 2024. It is now read-only.

Table should autoscale #31

Closed
lukehoban opened this issue Aug 29, 2017 · 4 comments · Fixed by #679
Closed

Table should autoscale #31

lukehoban opened this issue Aug 29, 2017 · 4 comments · Fixed by #679
Assignees
Milestone

Comments

@lukehoban
Copy link
Contributor

We should use DynamoDB autoscaling to allow Dynamo tables to scale in and out based on actual usage.

Unfortunately it is not yet supported in Terraform: hashicorp/terraform-provider-aws#888

@lukehoban
Copy link
Contributor Author

See also hashicorp/terraform-provider-aws#919 which looks like it will track the PR to address this in Terraform.

@lukehoban lukehoban self-assigned this Sep 5, 2017
@lukehoban
Copy link
Contributor Author

Getting close: hashicorp/terraform-provider-aws#1650

@lukehoban
Copy link
Contributor Author

As part of #48 I tried forcing Table autoscaling on behind the scenes to see what the experience is like. Turns out it's still not great at all, especially for bursty workloads. Interesting post highlight some of the issues (similar to what I saw) - https://hackernoon.com/the-problems-with-dynamodb-auto-scaling-and-how-it-might-be-improved-a92029c8c10b.

We should likely still enable it, as it at least means that sufficiently backed-off retires can eventually succeed, but it does really get in the way of a true serverless experience.

@lukehoban lukehoban added this to the 0.11 milestone Jan 10, 2018
@lukehoban lukehoban modified the milestones: 0.11, 0.14 Feb 8, 2018
@lukehoban lukehoban modified the milestones: 0.14, 0.16 Apr 20, 2018
@lukehoban lukehoban modified the milestones: 0.16, 0.18 Jul 12, 2018
@lukehoban lukehoban modified the milestones: 0.18, 0.20 Sep 13, 2018
@lukehoban
Copy link
Contributor Author

On-demand is now available, which should likely be the default.

https://aws.amazon.com/blogs/aws/amazon-dynamodb-on-demand-no-capacity-planning-and-pay-per-request-pricing/

lukehoban pushed a commit that referenced this issue Dec 18, 2018
The AWS Tabe implementation used DynamoDB with an opauqe and not-configurable fixed provisioning.  This has been probematic for several reasons:
1. It does not scale with load
2. It incurs a fixed cost even when not used
3. It would require AWS-specific provisioning hooks to expose control

With the recent release of On Demand billing mode for DynamoDB, we can now avoid all three problems by setting Table to On Demand provisioning which will scale with demand (including to zero).

We may in the future allow AWS-specific options to override this, but this makes much more sense as the default for this library.

Note that the change from Provisioned to On Demand does not require replacement of the Table, it can be updated in place.  The update itself does take ~5minutes to complete, but it otherwise non-disruptive to use of the Table.

Fixes #31.
lukehoban added a commit that referenced this issue Dec 18, 2018
The AWS Tabe implementation used DynamoDB with an opauqe and not-configurable fixed provisioning.  This has been probematic for several reasons:
1. It does not scale with load
2. It incurs a fixed cost even when not used
3. It would require AWS-specific provisioning hooks to expose control

With the recent release of On Demand billing mode for DynamoDB, we can now avoid all three problems by setting Table to On Demand provisioning which will scale with demand (including to zero).

We may in the future allow AWS-specific options to override this, but this makes much more sense as the default for this library.

Note that the change from Provisioned to On Demand does not require replacement of the Table, it can be updated in place.  The update itself does take ~5minutes to complete, but it otherwise non-disruptive to use of the Table.

Fixes #31.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant