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
Make the algorithm configurable #5
Comments
I've been thinking to change the tag set on the group, and allow people to configure autospotting based on the data contained in that tag. This is how my current idea looks like:
Wrapping up:
The benefit is we don't need any external database(we could create a dynamoDB table if we ever need more, but I doubt it), and we can just use the tags which we already need anyway. The only problem of this approach is the limited size of the value, which is 255 characters, so you can't specify too many things there but hopefully we never need as much to configure. The length of the above example is 60 characters, so with this approach we may be able to give about 10-12 options. One way to mitigate this limit may be to also provide short versions of the parameters, extracting the first letter of the underscore-separated words and making it uppercase, which should compress pretty well:
The length in this case is 22, which should allow us about 30 options in total. Getting forward with the idea, we could also compress the true/false in the same way to T/F, saving a few more bytes, resulting in a length of 16 characters for that example, which can allow around 50 options. We may never reach so many overall, and it is really unlikely to need as many in the same configuration:
I see how this may become quite cryptic for a human, so at some point we may need to create a more user-friendly tool to set these options on the tags of all the AutoScaling groups, perhaps also deploy the software and perform updates, but that will most likely come later if at all. |
A few other ideas that came up recently, thanks my colleague Emil Filipov:
or
|
Another idea, could also be to put a certain price for bidding or a configuration per ASG:
|
@xlr-8 it's kind of missing the entire point of autospotting, you don't want to manage it as the price changing over time, maybe max bid price tag will be useful as the current algorithm takes the on demand price as max. Another idea is how long an instance should be in the ASG before it will be replaced with spot, this is for highly dynamic scale. in this case if scale out of the ASG is just for 30 minutes, the autospotting will replace the instance after 5 minutes in the worst case... and eventually you paid for on demand + spot instance for this "peak" time. |
I don't think it makes sense to specify an absolute bid price, just run spot as long as you have cheaper spot instances than the initial on demand ones, and run on demand when it is getting more expensive. I do see a possible use case for having a customizable ratio, which would allow bidding for say 2x or 0.5x on demand price. But then again you lose money if the price is constantly in between the custom threshold and the base on demand price. |
@roeyazroel Sorry, I might have poorly expressed myself, it is indeed what I meant, having a spot request bid price that would replace the ondemand max price value. @cristim Yes, I am aware of the fragile balance between bid / on-demand price. Which actually brings a question: how does auto-spotting reacts when bid-request prices vary as well? |
@xlr-8 the spot bid price is always the same as the initial instance's on-demand hourly price. Currently AutoSpotting doesn't care about price fluctuations as long as the spot instances are running. The price may go up and down as long as it is below the bid price(when the spot instance would get terminated by AWS), regardless of other instance types that may become cheaper than those that are currently running. AutoSpotting only takes action when there is at least an on-demand instance in the group(resulted from scaling out or spot termination), in which case it will pick an on-demand instance from the group, find the cheapest spot instance available at that time, launch it and swap it with your on-demand instance. That's really all it does. The current logic could be enhanced to do this kind of terminations, but there are some aspects to consider:
So the lower price has to be stable for a relatively long time, enough to make it worth that hour of on-demand price for each change. In addition, a way to switch more often between spot instance types may be to not bid the on-demand price for the new spot instance, but pick a value close enough to its last week's average, in which case larger fluctuations will trigger often the replacement always with the cheapest one. All this could be implemented in a sort of 'saving profile' that would always hunt the cheapest instance types, and it could be enabled once we have autospotting configurable. |
Fixed in #54, other configuration options to be tracked as separate issues. |
This could be achieved using some additional metadata specified in the tag set on the AutoScaling group.
The text was updated successfully, but these errors were encountered: