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

[FLINK-36863][autoscaler] Use the maximum parallelism in the past scale-down.interval window when scaling down #922

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

1996fanrui
Copy link
Member

@1996fanrui 1996fanrui commented Dec 9, 2024

What is the purpose of the change

[FLINK-36863][autoscaler] Use the maximum parallelism in the past scale-down.interval window when scaling down instead of in the entire past

See more details from FLINK-36863.

Brief change log

VertexDelayedScaleDownInfo maintain all recommended parallelisms at each time within the past scale-down.interval window period.

  • Evicts the recommended parallelism before the scale-down.interval window.
  • The max parallelism within the window range as the final parallelism.

Note1 : It is a scenario that calculates the max value within a sliding window.

  • It is similar with leetcode 239: Sliding Window Maximum.
  • If latest parallelism is greater than the past parallelism, the past parallelism never be the max value, so we could evict all smaller parallelism in the past.
  • We only need to maintain a list with monotonically decreasing parallelism within the past window.
  • The first parallelism is the final parallelism.

Note2: Check the OutsideUtilizationBound of the final recommended parallelism instead of the OutsideUtilizationBound of latest recommended parallelism

See more details from these 2 comments: #922 (comment) and #922 (comment)

Verifying this change

  • Add some new unit tests in DelayedScaleDownTest
  • Update the ScalingExecutorTest#testUtilizationBoundaries based on the latest logic
  • Introduce the DelayedScaleDownEndToEndTest to test delayed scale down in detail

Does this pull request potentially affect one of the following parts:

  • Dependencies (does it add or upgrade a dependency): no
  • The public API, i.e., is any changes to the CustomResourceDescriptors: no
  • Core observer or reconciler logic that is regularly executed: no

Documentation

  • Does this pull request introduce a new feature? no

@1996fanrui 1996fanrui force-pushed the 36863/user-real-window branch 2 times, most recently from 345af37 to db578c8 Compare December 9, 2024 04:03
Comment on lines +81 to +101
while (!recommendedParallelisms.isEmpty()
&& recommendedParallelisms.peekLast().getParallelism() <= parallelism) {
recommendedParallelisms.pollLast();
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a good optimization 👍

Copy link
Member Author

@1996fanrui 1996fanrui Dec 12, 2024

Choose a reason for hiding this comment

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

Thanks @gyfora for the comment in advance, I'm still adding more tests and comments for this PR.

I have some other works to do this week, so I expect this PR will be ready next week.

@1996fanrui 1996fanrui force-pushed the 36863/user-real-window branch 2 times, most recently from ec694b0 to 4166c97 Compare December 12, 2024 07:17
@1996fanrui 1996fanrui force-pushed the 36863/user-real-window branch 2 times, most recently from 7da57c6 to 20d8552 Compare January 2, 2025 08:22
@1996fanrui 1996fanrui force-pushed the 36863/user-real-window branch from 20d8552 to 49478e4 Compare January 2, 2025 09:51
Comment on lines +215 to +219
List.of(
790, 200, 200, 200, 200, 200, 790, 200, 200, 200, 200, 200, 790, 200, 200,
200, 200, 200, 790, 200, 200, 200, 200, 200, 790, 200, 200, 200, 200, 200,
790),
List.of(790, 200, 790, 200, 790, 200, 790, 200, 790, 200, 790, 200, 790, 200, 790));
Copy link
Member Author

Choose a reason for hiding this comment

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

If the RecommendedParallelism class does not include outsideUtilizationBound, this test will be failed for the last 2 inputs.

The scale down interval is 60 minutes, and metric window is 10 minutes, so the recommended parallelism will be 790 for the last 2 inputs. When we check outsideUtilizationBound, we need to check the outsideUtilizationBound corresponding to the parallelism of 790.

That's why RecommendedParallelism class includes outsideUtilizationBound. If it doesn't include outsideUtilizationBound, the latest outsideUtilizationBound may come from parallelism 200

Comment on lines +223 to +225
if (parallelismChange.isOutsideUtilizationBound()) {
anyVertexOutsideBound.set(true);
}
Copy link
Member Author

Choose a reason for hiding this comment

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

We check the OutsideUtilizationBound of the final recommended parallelism instead of the OutsideUtilizationBound of latest recommended parallelism.

If the Utilization of all tasks is within range, we can skip scaling.

@1996fanrui 1996fanrui marked this pull request as ready for review January 3, 2025 08:34
Copy link
Member Author

@1996fanrui 1996fanrui left a comment

Choose a reason for hiding this comment

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

Happy new year @gyfora @mxm , this PR is ready for review. Please help review in your free time, thank you in advance~

I introduced the DelayedScaleDownEndToEndTest in the last commit to test delayed scale down in detail, so the code changes are more than 1 K lines, but about 80% of code changes are tests.

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