Apr 21 2020 04:02 AM
Hi Community,
Can someone help me in understanding that how scalability is handled by APG on app service level. Let's take an example, we have an app service deployed and running with auto-scale enabled and the app service is configured with APG. How APG get to know how many instances of the app service are running considering the auto scale is enabled on the app service level.
Regards,
Tayyab
Apr 21 2020 06:11 AM
Solution@Tayyab Suhail, when you configure App Service as a backend for AppGW, you are providing its URL, not the actual references to the App Service Plan instances. AppGW only knows a Web App URL, as much as any other HTTP client. Therefore, App Service scaling operations are transparent to AppGW, no matter you have 1 or 10 instances.
Apr 21 2020 06:29 AM
Apr 21 2020 07:02 AM
@Tayyab Suhail, Azure App Service honors ARRAffinity, so, even with AppGW in front of it, App Service "load balancer" should keep sending session-affinity-based requests to the same backend instance. However, take into account that App Service may be responding to requests with a different "Location" header, which will break session affinity. Read this article for a description of the problem and possible solutions.
Apr 21 2020 07:06 AM
May 11 2020 01:50 AM - edited May 11 2020 02:36 AM
Thank you once again for sharing the excellent article. The shared article answered my question however i am back again with new question and would like your expertise to get it answered.
Few months back, we transitioned Asp.net web application from IaaS to PaaS mode. Being on PaaS, we used Redis cache to maintain user's session so in case multiple instances are running of the app, we do not lose users's session. This was working fine but when we placed application behind APG, we started facing session issues which was highlighted in the article that you shared.
The issue got resolved through ARRAfinity cookie feature but i am curious that why we faced this issue when placed application behind APG, considering we already used Redis to maintain user's session to avoid this kind of issue.
Could you please share your thoughts on it ?
Let me know if you need more detail.
Many Thanks,
Tayyab
May 11 2020 03:13 PM
Hi, @Tayyab Suhail!
I don't know the details of how ASP.NET implements session management with Redis, but I guess the problem was, again, the Location header. If the Location header isn't rewritten by AppGW to the domain name of who's serving the request, then cookies will be cleared by the browser and you'll have no way of telling ASP.NET how to look for the session in Redis. Does it make sense?
May 13 2020 11:12 AM
Thank you for taking out time to reply my question. Yes, it makes sense what you are saying and i will explore further with respect to Asp.Net and Redis. if i find some useful information, i will definitely share with you and the community.
Once again, thanks.
Regards,
Tayyab
Apr 21 2020 06:11 AM
Solution@Tayyab Suhail, when you configure App Service as a backend for AppGW, you are providing its URL, not the actual references to the App Service Plan instances. AppGW only knows a Web App URL, as much as any other HTTP client. Therefore, App Service scaling operations are transparent to AppGW, no matter you have 1 or 10 instances.