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: articles/container-apps/dapr-keda-scaling.md
+40-88Lines changed: 40 additions & 88 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,24 +5,24 @@ author: hhunter-ms
5
5
ms.author: hannahhunter
6
6
ms.service: container-apps
7
7
ms.topic: conceptual
8
-
ms.date: 04/11/2023
8
+
ms.date: 04/13/2023
9
9
---
10
10
11
11
# Scale Dapr applications with KEDA scalers
12
12
13
-
Using [KEDA scalers](https://keda.sh/), you can scale your application and its [Dapr](https://docs.dapr.io/) sidecar when it has scaled to zero with inbound events and messages. In this guide, we demonstrate scaling a Dapr pub/sub application by setting up a KEDA scaler to watch for messages coming into the topic and triggers the app to scale up and down as needed.
13
+
Using [KEDA scalers](https://keda.sh/), you can scale your application and its [Dapr](https://docs.dapr.io/) sidecar when it has scaled to zero with inbound events and messages. This guide demonstrates how to configure the scale rules of a Dapr pub/sub application with a KEDA messaging scaler. The scaler watches for incoming messages and scales the application in and out as needed.
14
14
15
-
In the following scenario, we examine the Bicep for:
15
+
In this scenario, the application includes the following elements:
16
16
1. A `checkout` publisher container app that continuously publishes messages via the Dapr pub/sub API to the `orders` topic in Azure Service Bus.
17
17
1. The Dapr Azure Service Bus component.
18
18
1. An `order-processor` subscriber container app subscribed to the `orders` topic that receives and processes messages as they arrive.
19
19
1. The scale rule for Azure Service Bus, which is responsible for scaling up the `order-processor` service and its Dapr sidecar when messages start to arrive to the `orders` topic.
20
20
21
21
## Publisher container app
22
22
23
-
The `checkout` publisher is a headless service that runs indefinitely and never scales down to zero.
23
+
The `checkout` publisher is a headless service that runs indefinitely and never scales out to zero.
24
24
25
-
By default, [Container Apps assigns an http-based scale rule to applications](./scale-app.md), scaling apps based on the number of incoming HTTP requests. Below, we've set the`minReplicas` to "1", which ensures the container app doesn't follow the default behavior of scaling to zero with no incoming HTTP traffic.
25
+
By default, [the Container Apps runtime assigns an HTTP-based scale rule to applications](./scale-app.md) which drives scaling based on the number of incoming HTTP requests. In the following example,`minReplicas`is set to `1`. This configuration ensures the container app doesn't follow the default behavior of scaling to zero when there is no incoming HTTP traffic.
In the `order-processor` subscriber, we've added a custom scale rule on the resource for the type `azure-servicebus`. With this scale rule, KEDA can scale up the container app and its Dapr sidecar, allowing incoming messages to be processed.
81
+
The `order-processor` subscriber includes a custom scale rule on the resource for the type `azure-servicebus`. With this scale rule, KEDA scales out the container app and its Dapr sidecar. This scale behavior allows incoming messages to process as they arrive.
Behind the scenes, KEDA scales our `order-processor` appropriately (even down to zero). Notice the `messageCount` property on the scaler's configuration:
137
+
Behind the scenes, KEDA scales the `order-processor` in or out to meet demand.
138
+
139
+
Notice the `messageCount` property on the scaler's configuration:
208
140
209
141
```bicep
210
-
metadata: {
142
+
{
211
143
//...
212
-
messageCount: '1'
144
+
properties: {
145
+
//...
146
+
template: {
147
+
//...
148
+
scale: {
149
+
//...
150
+
rules: [
151
+
//...
152
+
custom: {
153
+
//...
154
+
metadata: {
155
+
//...
156
+
messageCount: '30'
157
+
}
158
+
}
159
+
]
160
+
}
161
+
}
162
+
}
213
163
}
214
164
```
215
165
216
-
This property tells KEDA how many messages each instance of our application can process at the same time. Since the application is single-threaded, we set this value to 1, resulting in KEDA scaling up our application to match the number of messages waiting in the queue. For example, if five messages are waiting, KEDA scales our app up to five instances. In our scenario, we set a `maxReplicas` value of 10, so KEDA scales up the `order-processor` container app to a max of 10 replicas.
166
+
This property tells KEDA how many messages each instance of the application to process at the same time. In this example, the value is set to `30`, making KEDA scale out the application to match the number of messages waiting in the queue.
167
+
168
+
For example, if five messages are waiting, KEDA scales the app out to five instances. In this scenario, `maxReplicas` is set to `10`, so KEDA scales up the `order-processor` container app to a max of 10 replicas.
0 commit comments