Keda: Support message sessions in Azure Service Bus Scaler

[worldspawn]

Use-Case

I have a large workload that is bound to a single session id. As a session can only be processed from a single listener (because it locks the session) scaling according to the number of messages in the queue is not... useful.

I've just added 620 messages to a queue all with the same session id and keda has scaled up the service to whopping 16 instances. But unfortunately 15 instances are doing nothing and 1 is working hard.

I'm not sure if you can interrogate the number of active sessions but if you can then...

Specification

• [ ] Allow to specify the desired number of desired active sessions and scale based on that instead of the number of messages in a queue.

[tomkerkhove]

That's a good scenario to cover. Are you using a specific scaler or more in general?

With Azure Service Bus you'd use sessions indeed, I'm just wondering how KEDA could know when to scale and when not?

[worldspawn]

I'm using the azure-servicebus trigger currently. I can't see any appropriate method on the REST api that would do this but "Service Bus Explorer" has the ability to produce a list of sessions for a queue (somehow).

[worldspawn]

Seems to use this method: https://docs.microsoft.com/en-us/dotnet/api/microsoft.servicebus.messaging.subscriptionclient.getmessagesessions?view=azure-dotnet#Microsoft_ServiceBus_Messaging_SubscriptionClient_GetMessageSessions

[tomkerkhove]

Reasonable ask. So if there would be a useSessions: true opt-in which would scale based on metrics and sessions that would help you?

[worldspawn]

Yeah that would be great. In this particular case I wouldn't be interested in scaling based on the number of messages at all, only the number of sessions. Because of how the .net client manages concurrency I cannot imagine ever needing to scale based on both queue length and session count at the same time. I think its as simple as - if its a session enabled queue i want to scale based on sessions, otherwise queue count.

[tomkerkhove]

Makes sense, thanks for bringing this up!

[davidallyoung]

Hi everyone, just to chime in, we also have a similar use case for sessions. Some context on how we use them:

We utilize the sessions to break up workloads per tenant and help facilitate "fast lanes". It's set up in such a way that some tenants could have more sessions than others, etc. If KEDA could scale based on sessions, it would definitely simplify and make more reliable our scaling strategy.

[MCGPPeters]

Somewhat connected to this issue.... When downscaling, are receiver instances that are locked taken into account? E.g. are these instances kept alive until the session has completed and the lock has been removed?

[tomkerkhove]

No because KEDA is not aware of what instances are doing. It just tells Kubernetes to scale from x to y, and the scheduler will kill the required amount of pods.

[MCGPPeters]

That would be really nice to have, since long running sessions could theoretically span days / months ... Any way you could work around this?

[tomkerkhove]

The only way to achieve this is to change the application that's running so that when a shutdown is initiated it gracefully abandons the session for somebody else to continue later on.

[MCGPPeters]

Thanks. That is the strategy I am following atm indeed. Was hoping I could remove some code :)

[tomkerkhove]

WDYT @ahmelsayed?