Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable write autoscaling for active DynamoDB tables #507

Merged
merged 15 commits into from
Aug 14, 2017
Merged

Conversation

aaron7
Copy link
Contributor

@aaron7 aaron7 commented Jul 14, 2017

Fixes #476. Original plan: #476 (comment)

@aaron7
Copy link
Contributor Author

aaron7 commented Jul 27, 2017

@aaron7 aaron7 changed the title [WIP] Enable write autoscaling for active DynamoDB tables Enable write autoscaling for active DynamoDB tables Aug 10, 2017
@aaron7 aaron7 requested a review from jml August 10, 2017 15:15
Copy link
Contributor

@jml jml left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! A few comments.

Help: "Time spent doing ApplicationAutoScaling requests.",

// ApplicationAutoScaling latency seems to range from a few ms to a few sec and is
// important. So use 8 buckets from 128us to 2s.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually true, or copy-pasted?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is copied and pasted from another AWS request metric. We will not know for sure what the latency will be until in dev/prod. I believe the requests are non-blocking as they are just setting configs which a watcher is then using later to scale the tables. I would expect the latency to be a standard AWS latency.

I will add a TODO here to check this later.

if err != nil {
return err
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure, but I think I'd write it like this:

var err error
if !current.WriteScaleEnabled {
	if expected.WriteScaleEnabled {
		err = d.enableAutoScaling(ctx, expected)
	}
} else {
	if !expected.WriteScaleEnabled {
		err = d.disableAutoScaling(ctx, expected)
	} else if !current.AutoScalingEquals(expected) {
		err = d.enableAutoScaling(ctx, expected)
	}
}
if err != nil {
	return err
}

But I can't articulate why, and am not sure it's better. WDYT?

Copy link
Contributor Author

@aaron7 aaron7 Aug 11, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I originally extracted out the expressions into variables to make it clear what each path was for, as it may take some time to get your head around why the combination of flags mean that we should either enable or disable. However, it's not that complex and it's clear which path is update and which one is disable, so I will update.

@@ -208,3 +304,95 @@ func (d dynamoTableClient) UpdateTable(ctx context.Context, current, expected Ta
}
return nil
}

func (d dynamoTableClient) enableAutoScaling(ctx context.Context, desc TableDesc) error {
// Registers or updates a scallable target
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scalable

}

func (d dynamoTableClient) disableAutoScaling(ctx context.Context, desc TableDesc) error {
// Deregister scallable target
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scalable

WriteScaleMaxCapacity int64
WriteScaleOutCooldown int64
WriteScaleInCooldown int64
WriteScaleTargetValue float64
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks the same as what's in schema_config.go. Why not split these fields into a separate struct type?

Then AutoScalingEquals can become Equals on that object (and maybe even the implementation could be replaced with a call to DeepEquals)

}
}
return true
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lolgo

@aaron7
Copy link
Contributor Author

aaron7 commented Aug 11, 2017

Thanks for the comments, ready for review again.

table.WriteScale.MaxCapacity = cfg.WriteScale.MaxCapacity
table.WriteScale.OutCooldown = cfg.WriteScale.OutCooldown
table.WriteScale.InCooldown = cfg.WriteScale.InCooldown
table.WriteScale.TargetValue = cfg.WriteScale.TargetValue
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just

table.WriteScale = cfg.WriteScale

legacyTable.WriteScale.MaxCapacity = m.cfg.IndexTables.WriteScale.MaxCapacity
legacyTable.WriteScale.OutCooldown = m.cfg.IndexTables.WriteScale.OutCooldown
legacyTable.WriteScale.InCooldown = m.cfg.IndexTables.WriteScale.InCooldown
legacyTable.WriteScale.TargetValue = m.cfg.IndexTables.WriteScale.TargetValue
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants