Azure Web App ARR Affinity Token Scenarios

0
votes

I have an application run on an Azure Web App that is scaled out across multiple instances. Because we're self-hosting SignalR (I know, I know...), we have to set the ARR Affinity token.

I am unsure of how request routing is done with ARR Affinity set under the following scenarios:

  1. Slot Swap - In a slot swap, will server affinity remain unchanged, and requests will be routed to the same server after the slot swap, or are all ARR sessions trashed and it's a new assignment?
  2. Scale in - if we remove Web App instances, some ARR mappings will no longer be valid. Are these just re-assigned by the NLB?

I would just test this myself, but I can't figure out how to reliably perform a test since to my knowledge, there is not a definitive way to see what server instance you're on. Any answers to these questions or suggestions on how to perform this test are appreciated.

1
azureazure-web-app-service

1 Answers

5
votes

With regards to slot swap, the worker role slots are running on the same instance. Since the AARAffinity cookie has a value to the running instance, your session will still be routed correctly maintaining state.

Scaling out/in is going to be different because the process does introduce a new instance. Once you scale back in, that instance will no longer be valid in the AARAffinity cookie. So that session will be thrown out and new one will start with the remaining instance(s).

That's what SignalR Service, get's you...session state is stored on a Redis backplane to maintain connection resiliency and sticky session isn't required. This may help clear up some questions regarding how SignalR uses state and some workarounds.