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

[serve] Add replica placement group support #37830

Merged
merged 35 commits into from
Aug 10, 2023

Conversation

edoakes
Copy link
Contributor

@edoakes edoakes commented Jul 26, 2023

Why are these changes needed?

Adds support for placement_group_strategy and placement_group_policy to the deployment config. This enables creating a placement group per replica of a deployment which is a feature request from users orchestrating multiple actors within a replica (e.g., to perform model-parallel inference).

The replica actor will be created in the bundle with index 0 (following the precedent set in Ray Train and Ray Tune).

TODO before merging:

  • Add necessary docstrings.
  • Better handling of invalid placement groups (deployment scheduler spams forever if there's an exception scheduling a replica).
  • Add test for deploying via config (valid and invalid).
  • Add unit test to test_deployment_scheduler.

Related issue number

Checks

  • I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
  • I've run scripts/format.sh to lint the changes in this PR.
  • I've included any doc changes needed for https://docs.ray.io/en/master/.
    • I've added any new APIs to the API Reference. For example, if I added a
      method in Tune, I've added it in doc/source/tune/api/ under the
      corresponding .rst file.
  • I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
  • Testing Strategy
    • Unit tests
    • Release tests
    • This PR is not tested :(

Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
@ericl
Copy link
Contributor

ericl commented Jul 26, 2023

cc @Yard1

@edoakes edoakes self-assigned this Aug 1, 2023
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
@edoakes edoakes changed the title [WIP][serve] Add replica placement group support [serve] Add replica placement group support Aug 8, 2023
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
@edoakes edoakes requested review from jjyao and a team August 8, 2023 16:13
@edoakes
Copy link
Contributor Author

edoakes commented Aug 8, 2023

@jjyao this is ready for review (note there is a little bit of cleanup pending as noted in the description).

Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Copy link
Contributor

@jjyao jjyao left a comment

Choose a reason for hiding this comment

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

overall lgtm

Comment on lines +46 to +49
# Placement group bundles and strategy *for this replica*.
# These are optional: by default replicas do not have a placement group.
placement_group_bundles: Optional[List[Dict[str, float]]] = None
placement_group_strategy: Optional[str] = None
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can create a PlacementGroupDeploymentSchedulingPolicy that contains placement_group_bundles and placement_group_strategy and register this policy during on_deployment_created.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought more about this and actually I don't think it changes anything related to the DeploymentSchedulingPolicy. The placement group is only relevant to each replica itself. We probably still want to SPREAD the different placement groups among each other like the existing policy (and maintain things like max_replicas_per_node).

Copy link
Contributor

Choose a reason for hiding this comment

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

Yea makes sense. Currently there is no way to spread PGs.

If you think it's a valid case, do you mind filing an enhancement issue so I can track on my side.

python/ray/serve/tests/test_replica_placement_group.py Outdated Show resolved Hide resolved
Copy link
Contributor

@shrekris-anyscale shrekris-anyscale left a comment

Choose a reason for hiding this comment

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

Nice work so far! Most of my suggestions are nits to improve docstrings.

I left a few questions about co-scheduling Serve replicas with Ray actors/tasks using PGs, but based on the unit tests those don't seem as relevant. Feel free to resolve them if they're not.

python/ray/serve/_private/deploy_utils.py Outdated Show resolved Hide resolved
python/ray/serve/_private/deployment_state.py Outdated Show resolved Hide resolved
python/ray/serve/_private/deployment_state.py Outdated Show resolved Hide resolved
python/ray/serve/_private/deployment_state.py Show resolved Hide resolved
python/ray/serve/_private/deployment_state.py Outdated Show resolved Hide resolved
python/ray/serve/_private/utils.py Outdated Show resolved Hide resolved
python/ray/serve/api.py Outdated Show resolved Hide resolved
python/ray/serve/schema.py Outdated Show resolved Hide resolved
python/ray/serve/schema.py Outdated Show resolved Hide resolved
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
@@ -76,9 +82,18 @@ def requires_long_poll_broadcast(self, new_version):
)

def compute_hashes(self):
# If this changes, the controller will directly restart all existing replicas.
# If these change, the controller will rolling upgrade existing replicas.
Copy link
Contributor

Choose a reason for hiding this comment

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

For my knowledge, is it from core requirement or some other considerations we have to do rolling upgrade after the placement group change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You can't modify a placement group in-place, need to remove it and create another (similar to changing the actor resource requirement)

Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
["serve", "status", "-a", "http://localhost:52365/"]
)
status = yaml.safe_load(cli_output)["applications"]
# TODO(zcin): fix error handling in the application state manager for
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@zcin here is the issue I discussed w/ you on slack. Plan to merge this as-is and you can take it as a follow-up.

Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Copy link
Contributor

@shrekris-anyscale shrekris-anyscale left a comment

Choose a reason for hiding this comment

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

Nice work! This change looks good to me.

python/ray/serve/_private/deployment_state.py Show resolved Hide resolved
Copy link
Contributor

@jjyao jjyao left a comment

Choose a reason for hiding this comment

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

lgtm for deployment state and scheduler parts.

Comment on lines +46 to +49
# Placement group bundles and strategy *for this replica*.
# These are optional: by default replicas do not have a placement group.
placement_group_bundles: Optional[List[Dict[str, float]]] = None
placement_group_strategy: Optional[str] = None
Copy link
Contributor

Choose a reason for hiding this comment

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

Yea makes sense. Currently there is no way to spread PGs.

If you think it's a valid case, do you mind filing an enhancement issue so I can track on my side.

python/ray/serve/_private/deployment_state.py Outdated Show resolved Hide resolved
Copy link
Contributor

@sihanwang41 sihanwang41 left a comment

Choose a reason for hiding this comment

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

Nice work! Two question (non-blocker)

  1. Do we add the placement group info from serve status?
  2. Should we add a test spawning a pure ray actor or ray task from serve replica, to make sure they are under the same pg? (If already had, can ignore)

@edoakes
Copy link
Contributor Author

edoakes commented Aug 9, 2023

@sihanwang41 yes we should, I can file a follow-up one for that. And yeah I'm verifying we get spawned in the right PG but not actually spawning a task/actor -- I'll add that.

Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
serve.run(Infeasible.bind())


def test_coschedule_actors_and_tasks(serve_instance):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@sihanwang41 added this test you asked about

Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
Signed-off-by: Edward Oakes <ed.nmi.oakes@gmail.com>
@edoakes edoakes merged commit 6fef803 into ray-project:master Aug 10, 2023
126 of 128 checks passed
shrekris-anyscale pushed a commit to shrekris-anyscale/ray that referenced this pull request Aug 10, 2023
Adds support for `placement_group_strategy` and `placement_group_policy` to the deployment config. This enables creating a placement group _per replica_ of a deployment which is a feature request from users orchestrating multiple actors within a replica (e.g., to perform model-parallel inference).

The replica actor will be created in the bundle with index `0` (following the precedent set in Ray Train and Ray Tune).

Signed-off-by: Shreyas Krishnaswamy <shrekris@anyscale.com>
NripeshN pushed a commit to NripeshN/ray that referenced this pull request Aug 15, 2023
Adds support for `placement_group_strategy` and `placement_group_policy` to the deployment config. This enables creating a placement group _per replica_ of a deployment which is a feature request from users orchestrating multiple actors within a replica (e.g., to perform model-parallel inference).

The replica actor will be created in the bundle with index `0` (following the precedent set in Ray Train and Ray Tune).

Signed-off-by: NripeshN <nn2012@hw.ac.uk>
harborn pushed a commit to harborn/ray that referenced this pull request Aug 17, 2023
Adds support for `placement_group_strategy` and `placement_group_policy` to the deployment config. This enables creating a placement group _per replica_ of a deployment which is a feature request from users orchestrating multiple actors within a replica (e.g., to perform model-parallel inference).

The replica actor will be created in the bundle with index `0` (following the precedent set in Ray Train and Ray Tune).

Signed-off-by: harborn <gangsheng.wu@intel.com>
harborn pushed a commit to harborn/ray that referenced this pull request Aug 17, 2023
Adds support for `placement_group_strategy` and `placement_group_policy` to the deployment config. This enables creating a placement group _per replica_ of a deployment which is a feature request from users orchestrating multiple actors within a replica (e.g., to perform model-parallel inference).

The replica actor will be created in the bundle with index `0` (following the precedent set in Ray Train and Ray Tune).
arvind-chandra pushed a commit to lmco/ray that referenced this pull request Aug 31, 2023
Adds support for `placement_group_strategy` and `placement_group_policy` to the deployment config. This enables creating a placement group _per replica_ of a deployment which is a feature request from users orchestrating multiple actors within a replica (e.g., to perform model-parallel inference).

The replica actor will be created in the bundle with index `0` (following the precedent set in Ray Train and Ray Tune).

Signed-off-by: e428265 <arvind.chandramouli@lmco.com>
vymao pushed a commit to vymao/ray that referenced this pull request Oct 11, 2023
Adds support for `placement_group_strategy` and `placement_group_policy` to the deployment config. This enables creating a placement group _per replica_ of a deployment which is a feature request from users orchestrating multiple actors within a replica (e.g., to perform model-parallel inference).

The replica actor will be created in the bundle with index `0` (following the precedent set in Ray Train and Ray Tune).

Signed-off-by: Victor <vctr.y.m@example.com>
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.

None yet

5 participants