You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/source/serve/advanced-guides/advanced-autoscaling.md
+93Lines changed: 93 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -723,3 +723,96 @@ When your custom autoscaling policy has complex dependencies or you want better
723
723
- **Contribute to Ray Serve**: If your policy is general-purpose and might benefit others, consider contributing it to Ray Serve as a built-in policy by opening a feature request or pull request on the [Ray GitHub repository](https://github.com/ray-project/ray/issues). The recommended location for the implementation is `python/ray/serve/autoscaling_policy.py`.
724
724
- **Ensure dependencies in your environment**: Make sure that the external dependencies are installed in your Docker image or environment.
725
725
:::
726
+
727
+
728
+
(serve-external-scale-api)=
729
+
730
+
### External scaling API
731
+
732
+
:::{warning}
733
+
This API is in alpha and may change before becoming stable.
734
+
:::
735
+
736
+
The external scaling API provides programmatic control over the number of replicas for any deployment in your Ray Serve application. Unlike Ray Serve's built-in autoscaling, which scales based on queue depth and ongoing requests, this API allows you to scale based on any external criteria you define.
737
+
738
+
#### Example: Predictive scaling
739
+
740
+
This example shows how to implement predictive scaling based on historical patterns or forecasts. You can preemptively scale up before anticipated traffic spikes by running an external script that adjusts replica counts based on time of day.
741
+
742
+
##### Define the deployment
743
+
744
+
The following example creates a simple text processing deployment that you can scale externally. Save this code to a file named `external_scaler_predictive.py`:
Before using the external scaling API, enable it in your application configuration by setting `external_scaler_enabled: true`. Save this configuration to a file named `external_scaler_config.yaml`:
External scaling and built-in autoscaling are mutually exclusive. You can't use both for the same application. If you set `external_scaler_enabled: true`, you **must not** configure `autoscaling_config` on any deployment in that application. Attempting to use both results in an error.
764
+
:::
765
+
766
+
##### Implement the scaling logic
767
+
768
+
The following script implements predictive scaling based on time of day and historical traffic patterns. Save this script to a file named `external_scaler_predictive_client.py`:
- **Request body**: `{"target_num_replicas": <number>}` (must conform to the [`ScaleDeploymentRequest`](../api/doc/ray.serve.schema.ScaleDeploymentRequest.rst) schema)
779
+
780
+
The scaling client continuously adjusts the number of replicas based on the time of day:
781
+
- Business hours (9 AM - 5 PM): 10 replicas
782
+
- Off-peak hours: 3 replicas
783
+
784
+
##### Run the example
785
+
786
+
Follow these steps to run the complete example:
787
+
788
+
1. Start the Ray Serve application with the configuration:
789
+
790
+
```bash
791
+
serve run external_scaler_config.yaml
792
+
```
793
+
794
+
2. Run the predictive scaling client in a separate terminal:
795
+
796
+
```bash
797
+
python external_scaler_predictive_client.py
798
+
```
799
+
800
+
The client adjusts replica counts automatically based on the time of day. You can monitor the scaling behavior in the Ray dashboard or by checking the application logs.
801
+
802
+
#### Important considerations
803
+
804
+
Understanding how the external scaler interacts with your deployments helps you build reliable scaling logic:
805
+
806
+
- **Idempotent API calls**: The scaling API is idempotent. You can safely call it multiple times with the same `target_num_replicas` value without side effects. This makes it safe to run your scaling logic on a schedule or in response to repeated metric updates.
807
+
808
+
- **Interaction with serve deploy**: When you upgrade your service with `serve deploy`, the number of replicas you set through the external scaler API stays intact. This behavior matches what you'd expect from Ray Serve's built-in autoscaler—deployment updates don't reset replica counts.
809
+
810
+
- **Query current replica count**: You can get the current number of replicas for any deployment by querying the GET `/applications` API:
811
+
812
+
```bash
813
+
curl -X GET http://localhost:8265/api/serve/applications/ \
814
+
```
815
+
816
+
The response follows the [`ServeInstanceDetails`](../api/doc/ray.serve.schema.ServeInstanceDetails.rst) schema, which includes an `applications` field containing a dictionary with application names as keys. Each application includes detailed information about all its deployments, including current replica counts. Use this information to make informed scaling decisions. For example, you might scale up gradually by adding a percentage of existing replicas rather than jumping to a fixed number.
817
+
818
+
- **Initial replica count**: When you deploy an application for the first time, Ray Serve creates the number of replicas specified in the `num_replicas` field of your deployment configuration. The external scaler can then adjust this count dynamically based on your scaling logic.
Copy file name to clipboardExpand all lines: doc/source/serve/production-guide/config.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,7 +40,8 @@ applications:
40
40
- name: ...
41
41
route_prefix: ...
42
42
import_path: ...
43
-
runtime_env: ...
43
+
runtime_env: ...
44
+
external_scaler_enabled: ...
44
45
deployments:
45
46
- name: ...
46
47
num_replicas: ...
@@ -99,6 +100,7 @@ These are the fields per `application`:
99
100
- **`route_prefix`**: An application can be called via HTTP at the specified route prefix. It defaults to `/`. The route prefix for each application must be unique.
100
101
- **`import_path`**: The path to your top-level Serve deployment (or the same path passed to `serve run`). The most minimal config file consists of only an `import_path`.
101
102
- **`runtime_env`**: Defines the environment that the application runs in. Use this parameter to package application dependencies such as `pip` packages (see {ref}`Runtime Environments <runtime-environments>` for supported fields). The `import_path` must be available _within_ the `runtime_env` if it's specified. The Serve config's `runtime_env` can only use [remote URIs](remote-uris) in its `working_dir` and `py_modules`; it can't use local zip files or directories. [More details on runtime env](serve-runtime-env).
103
+
- **`external_scaler_enabled`**: Enables the external scaling API, which lets you scale deployments from outside the Ray cluster using a REST API. When enabled, you can't use built-in autoscaling (`autoscaling_config`) for any deployment in this application. Defaults to `False`. See [External Scaling API](serve-external-scale-api) for details.
102
104
- **`deployments (optional)`**: A list of deployment options that allows you to override the `@serve.deployment` settings specified in the deployment graph code. Each entry in this list must include the deployment `name`, which must match one in the code. If this section is omitted, Serve launches all deployments in the graph with the parameters specified in the code. See how to [configure serve deployment options](serve-configure-deployment).
103
105
- **`args`**: Arguments that are passed to the [application builder](serve-app-builder-guide).
0 commit comments