Skip to content

Commit 31420ba

Browse files
committed
updates per craig, pt 1
Signed-off-by: Hannah Hunter <[email protected]>
1 parent 0d009ae commit 31420ba

File tree

1 file changed

+40
-88
lines changed

1 file changed

+40
-88
lines changed

articles/container-apps/dapr-keda-scaling.md

Lines changed: 40 additions & 88 deletions
Original file line numberDiff line numberDiff line change
@@ -5,24 +5,24 @@ author: hhunter-ms
55
ms.author: hannahhunter
66
ms.service: container-apps
77
ms.topic: conceptual
8-
ms.date: 04/11/2023
8+
ms.date: 04/13/2023
99
---
1010

1111
# Scale Dapr applications with KEDA scalers
1212

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.
1414

15-
In the following scenario, we examine the Bicep for:
15+
In this scenario, the application includes the following elements:
1616
1. A `checkout` publisher container app that continuously publishes messages via the Dapr pub/sub API to the `orders` topic in Azure Service Bus.
1717
1. The Dapr Azure Service Bus component.
1818
1. An `order-processor` subscriber container app subscribed to the `orders` topic that receives and processes messages as they arrive.
1919
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.
2020

2121
## Publisher container app
2222

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.
2424

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.
2626

2727
```bicep
2828
resource checkout 'Microsoft.App/containerApps@2022-03-01' = {
@@ -32,45 +32,10 @@ resource checkout 'Microsoft.App/containerApps@2022-03-01' = {
3232
type: 'SystemAssigned'
3333
}
3434
properties: {
35-
managedEnvironmentId: containerAppsEnvironment.id
36-
configuration: {
37-
activeRevisionsMode: 'single'
38-
dapr: {
39-
enabled: true
40-
appId: 'checkout'
41-
appProtocol: 'http'
42-
}
43-
secrets: [
44-
{
45-
name: 'registry-password'
46-
value: containerRegistry.listCredentials().passwords[0].value
47-
}
48-
]
49-
registries: [
50-
{
51-
server: '${containerRegistry.name}.azurecr.io'
52-
username: containerRegistry.name
53-
passwordSecretRef: 'registry-password'
54-
}
55-
]
56-
}
35+
//...
5736
template: {
58-
containers: [
59-
{
60-
image: imageName
61-
name: 'checkoutsvc'
62-
env: [
63-
{
64-
name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
65-
value: appInsights.properties.InstrumentationKey
66-
}
67-
{
68-
name: 'AZURE_KEY_VAULT_ENDPOINT'
69-
value: keyVault.properties.vaultUri
70-
}
71-
]
72-
}
73-
]
37+
//...
38+
// Scale the minReplicas to 1
7439
scale: {
7540
minReplicas: 1
7641
maxReplicas: 1
@@ -113,7 +78,7 @@ resource daprComponent 'daprComponents' = {
11378

11479
## Subscriber container app
11580

116-
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.
11782

11883
```bicep
11984
resource orders 'Microsoft.App/containerApps@2022-03-01' = {
@@ -128,53 +93,18 @@ resource orders 'Microsoft.App/containerApps@2022-03-01' = {
12893
properties: {
12994
managedEnvironmentId: containerAppsEnvironment.id
13095
configuration: {
131-
activeRevisionsMode: 'single'
132-
ingress: {
133-
external: true
134-
targetPort: 5001
135-
transport: 'auto'
136-
}
96+
//...
97+
// Enable Dapr on the container app
13798
dapr: {
13899
enabled: true
139100
appId: 'orders'
140101
appProtocol: 'http'
141102
appPort: 5001
142103
}
143-
secrets: [
144-
{
145-
name: 'registry-password'
146-
value: containerRegistry.listCredentials().passwords[0].value
147-
}
148-
{
149-
name: 'sb-root-connectionstring'
150-
value: '${listKeys('${sb.id}/AuthorizationRules/RootManageSharedAccessKey', sb.apiVersion).primaryConnectionString};EntityPath=orders'
151-
}
152-
]
153-
registries: [
154-
{
155-
server: '${containerRegistry.name}.azurecr.io'
156-
username: containerRegistry.name
157-
passwordSecretRef: 'registry-password'
158-
}
159-
]
104+
//...
160105
}
161106
template: {
162-
containers: [
163-
{
164-
image: imageName
165-
name: 'orderssvc'
166-
env: [
167-
{
168-
name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
169-
value: appInsights.properties.InstrumentationKey
170-
}
171-
{
172-
name: 'AZURE_KEY_VAULT_ENDPOINT'
173-
value: keyVault.properties.vaultUri
174-
}
175-
]
176-
}
177-
]
107+
//...
178108
// Set the scale property on the order-processor resource
179109
scale: {
180110
minReplicas: 0
@@ -187,7 +117,7 @@ resource orders 'Microsoft.App/containerApps@2022-03-01' = {
187117
metadata: {
188118
topicName: 'orders'
189119
subscriptionName: 'membership-orders'
190-
messageCount: '1'
120+
messageCount: '30'
191121
}
192122
auth: [
193123
{
@@ -204,16 +134,38 @@ resource orders 'Microsoft.App/containerApps@2022-03-01' = {
204134
}
205135
```
206136

207-
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:
208140

209141
```bicep
210-
metadata: {
142+
{
211143
//...
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+
}
213163
}
214164
```
215165

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.
217169

218170
## Next steps
219171

0 commit comments

Comments
 (0)