diff --git a/docs/proposals/376-metric-aggregagor/README.md b/docs/proposals/376-metric-aggregagor/README.md new file mode 100644 index 00000000..e7fcd86e --- /dev/null +++ b/docs/proposals/376-metric-aggregagor/README.md @@ -0,0 +1,345 @@ +# Proposal-376: Gateway Metric Aggregator + + + + + + +- [Summary](#summary) +- [Motivation](#motivation) + - [Goals](#goals) + - [Non-Goals](#non-goals) +- [Proposal](#proposal) + - [User Stories (Optional)](#user-stories-optional) + - [Story 1](#story-1) + - [Story 2](#story-2) + - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional) + - [Risks and Mitigations](#risks-and-mitigations) +- [Design Details](#design-details) + - [Test Plan](#test-plan) + - [Prerequisite testing updates](#prerequisite-testing-updates) + - [Unit tests](#unit-tests) + - [Integration tests](#integration-tests) + - [e2e tests](#e2e-tests) + - [Graduation Criteria](#graduation-criteria) +- [Implementation History](#implementation-history) +- [Drawbacks](#drawbacks) +- [Alternatives](#alternatives) + + +## Summary + + + +Metric-based scheduling is common in many systems, including Kubernetes. For GenAI, this becomes more complex because of the heavy computational requirements of models. This proposal outlines a design for a metric aggregator that can efficiently handle the unique challenges posed by GenAI workloads. + +## Motivation + + + +With traditional services, because the final results will be generated in a very short time, common algorithms like round-robin or least-connection are enough. + +However, in inference services, because of the heavy computations of the matrix multiplication, the result generation is often very slow, which is an essential difference with the traditional services. Therefore, we need more advanced algorithms to help us make wise scheduling decisions. For example, based on the inference engine's queue size, kv cache size, or combined metrics. + +All these indicators should be collected from the inference engines for further analysis, that's why a metric aggregator is needed. + +### Goals + + + +- A simple implementation with least-latency scheduling algorithm +- Extensible with different consumers in the cluster, like the Lora autoscaler or the ai gateway +- Metrics visualization support, like Grafana + +### Non-Goals + + + +- Different scheduling algorithm implementations in ai gateway, like prefix-cache aware +- LoRA aware scheduling implementation, will be left to another KEP +- Performance consideration in big clusters should be left to the Beta level + +## Proposal + + + +### User Stories (Optional) + + + +#### Story 1 + +As a user, I hope my LLM request could be routed to the least-latency instance, so that I can get the result as soon as possible. + +#### Story 2 + +As a RAG user, when retrieving documents, sometime they'are the same, so I hope my request could be routed to the instance with the most available kv cache to avoid the repetitive calculation, which is know as the prefix cache aware scheduling. + +### Notes/Constraints/Caveats (Optional) + + + +- Metrics-based routing should meet the baseline requirements: even the metrics are unavailable or outdated, the system should still be able to work, despite the fact that the request response may be slower. For example, metrics-based lora scheduling maybe unfit here because once the metric indicates the wrong instance, we may hit 500 server error, it's unacceptable. Unless the inference engine will fetch the models dynamically. +- Once the gateway picks the Pod for scheduling, it could happen that the Pod suddenly becomes unavailable, we should support fallback mechanism to default service routing. + +### Risks and Mitigations + + + +The metrics might be outdated or even unable to fetch, the router then may make suboptimal decisions, but as mentioned above, the system can still work with a slow response. + +## Design Details + + + +The overall flow looks like: + +![flow](./flow.png) + + +### Steps + +Let's break down the flow into several steps: + +- Step 1: we'll collect the metrics from the inference workloads in metrics aggregator. +- Step 2: the aggregator will parse the metrics and store them in the redis, this is for HA consideration and cache sharing. Once the instance is down, we can still retrieve the metrics from redis. And if we have multiple instances, we can share the metrics with each other via redis. Considering Envoy AI gateway already uses Redis for limit rating, we'll reuse the Redis here. +- Step 3 & 4: Traffic comes, the gateway plugin (we'll call it router later) will retrieve the metrics from Redis and make routing decisions based on different algorithms, like queue size aware scheduling. +- Step 5: The router will send the request to the selected instance, and the instance will return the result to the router, return to the user finally. + +### Additional components introduced: + +- Metrics Aggregator (MA): MA is working as the controller plane to sync the metrics, this is also one of the reason why we want to decouple it from the router, which working as a data plane. MA has several components: + - A Pod controller to manage the Pod lifecycle, for example, once a Pod is ready, it will add it to the internal store, and each Pod will fork a background goroutine to sync the metrics continuously, 50ms interval by default. Once the Pod is deleted, the goroutine will be stopped and removed from the store. + - A internal store to parse the metric results, and store it in the backend storage, like Redis. +- Redis: a Redis instance is necessary for the metrics storage and sharing, we can use the existing Redis instance in the cluster, or deploy a new one if necessary. We should have storage interface to support different backends in the future. +- Router: a new router or [DynamicLoadBalancingBackend](https://github.com/envoyproxy/ai-gateway/blob/be2b479b04bc7a219b0c8239143bfbabebdcd615/filterapi/filterconfig.go#L199-L208) specifically in Envoy AI gateway to pick the best-fit Pod endpoints. However, we may block by the upstream issue [here](https://github.com/envoyproxy/ai-gateway/issues/604), we'll work with the Envoy AI Gateway team to resolve it ASAP. Maybe the final design will impact our implementation a bit but not much I think. + +### Data Structure + +The data structure could be varied based on the metrics we want to collect, let's take the queue size as an example: + +Because redis is a kv store, we'll use the ZSET to store the results, `LeastLatency::ModelName` as the key, Pod name as the member and the (runningQueueSize * 0.3 + waitingQueueSize * 0.7) as the score, the factor of waitingQueueSize is higher because metric is a delayed indicator. RunningQueueSize and WaitingQueueSize are two metrics most of the inference engines support. + +We'll also have another key to record the update timestamp. For example, a Pod named "default/fake-pod" with the score = 0.5, the set commands look like: + +```bash +# set the update timestamp +SET default/fake-pod "2025-05-12T06:16:27Z" + +# set the score +ZADD LeastLatency::ModelName 0.5 default/fake-pod +``` + +When collecting, we'll update the timestamp and score together. Setting the top 5 is enough for us to help reduce the storage pressure since it's a memory-based database. We don't use the expiration key here is just because most of the time, the metrics should be updated at a regular interval. + +When retrieving, we'll first query the ZSET to get the top 5 records, and iterate them one by one to verify that `currentTimestamp - recordTimestamp < 5s`, if not, skipping to the next one. This is to avoid outdated metrics. Once picked the exact endpoint, we'll reset the score with waitingQueueSize + 1 to avoid hotspot issues, especially when metrics update is blocked by some reasons. + +If all metrics are outdated, we'll fallback to the default service. + +Note: the algorithm is not the final one, we'll have more discussions with the community to find the best one. + +### Test Plan + + + +[x] I/we understand the owners of the involved components may require updates to +existing tests to make this code solid enough prior to committing the changes necessary +to implement this enhancement. + +##### Prerequisite testing updates + + + +##### Unit tests + + + + + +- Hard to predict now since it's a new component, but try the best to make sure all the functionalities are covered. + +##### Integration tests + + + + + +- By faking the metrics to make sure the router can pick the right instance. + +##### e2e tests + + + +- Add one e2e test to make sure the whole system can be launched via helm chart. +- For performance, we'll have benchmarks rather than e2e tests. + +### Graduation Criteria + + + +Beta: + +- Other storages rather than KV store who supports only key-value pairs which might be not enough for more complex scenarios, like the prefix-cache aware scenario. +- HA support, once the metrics aggregator is down, the system should still work. +- No performance issues in big clusters, we may use daemonsets to report metrics. +- Once the picked Pod is down after the routing decision, router will fallback to the default service. Fallback mode is already supported in Envoy AI gateway. + +## Implementation History + + + +- 2025-05-08: Proposal initialized and submitted for review + +## Drawbacks + + + +## Alternatives + + + +- When collecting metrics from the inference workloads, `PUSH` mode will put less pressure on the gateway side, or the gateway will have iterate all the Pods which obviously will lead to performance issues. We didn't pick the approach because it will either add additional load to the inference workload and introduces more complexity to the system. The current approach will fork as much goroutines as the number of inference workloads to sync the metrics in parallel, this is feasible because goroutine is lightweight. Once the metrics aggregator becomes the bottleneck, we can consider to use `PUSH` mode at node level. \ No newline at end of file diff --git a/docs/proposals/376-metric-aggregagor/flow.png b/docs/proposals/376-metric-aggregagor/flow.png new file mode 100644 index 00000000..b0b9e83d Binary files /dev/null and b/docs/proposals/376-metric-aggregagor/flow.png differ diff --git a/docs/proposals/376-metric-aggregagor/proposal.yaml b/docs/proposals/376-metric-aggregagor/proposal.yaml new file mode 100644 index 00000000..8bdb5c79 --- /dev/null +++ b/docs/proposals/376-metric-aggregagor/proposal.yaml @@ -0,0 +1,38 @@ +title: Gateway Metric Aggregator +proposal-number: 376 +authors: + - kerthcet +status: implementable +creation-date: 2025-04-25 +reviewers: + - cr7258 + - googs1025 +approvers: + - TBD + +see-also: [] + +replaces: [] + +# The target maturity stage in the current dev cycle for this proposal. +stage: beta + +# The most recent milestone for which work toward delivery of this proposal has been +# done. This can be the current (upcoming) milestone, if it is being actively +# worked on. +latest-milestone: "v0.2" + +# The milestone at which this feature was, or is targeted to be, at each stage. +milestone: + alpha: "v0.2" + beta: TBD + stable: TBD + +# The following PRR answers are required at alpha release +# List the feature gate name and the components for which it must be enabled +feature-gates: [] + +disable-supported: true + +# The following PRR answers are required at beta release +metrics: []