When you have multiple instances running in Azure Web App the load gets distributed in certain manner between the number of Web Apps in the backend. ARR plays an important role in distributing the load between active instances. ARR keeps track of connecting user by giving them a cookie known as affinity cookie, which allows it to know upon subsequent requests, to which server instance they were talking to and they will connect to same instance when they return back.
This is important in case of an application that is session-sensitive or in other words called as statefull application, now you can certainly build this capability within your application too by storing the session information in SQL as example, but i guess the preferred way in most of the cases i guess is to distribute the traffic using session cookie.
let’s try to understand the flow of request & what role ARR plays.
Step 1: Client connects to an Azure Website hosted on Web Apps
Step 2: ARR runs on the front end Azure server and receives the request
Step 3: ARR decides to which of the available instances the request should be forwarded.
Step 4: ARR forwards the request to the selected server, crafts and attaches an ARRAffinity cookie to the request.
Step 5: The response goes back to the client holding ARRAffinity cookie.
Step 6: When the client receives the request it stores the cookie for later use, browser will hold on to it.
Step 7: When client submits a subsequent request, it includes the cookie in it.
Step 8: When ARR receives the request, it sees the cookie and decodes it
Step 9: The decoded cookie holds the name of the instance that was used earlier and so ARR forwards the request to the same instance, rather then choosing one from the pool
Step 10: The same things repeat upon every subsequent request for the same site, untill the user closes the browser at which point the cookie is cleared.
so far we have seen the advantages of ARR but some times the affinity is not desired, for example some user don’t close their browser and remain connected for extended periods of times. Now when this happens, the affinity cookie remains in the browser and this keeps the user attached to server for a period that could last for hours, days or even more.
so use the ARR wisely and ensure the traffic is routed to all the backend instances equally.