SOLVED

Azure Application Gateway with App Service

Copper Contributor

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

7 Replies
best response confirmed by hspinto (Microsoft)
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.

@hspinto, Thanks for taking out time and adding details to it. It makes sense what you are saying so i am wondering that APG provides session affinity feature that routes request coming from same client to the same instance of the application. In case there are 10 app service instance running how this session affinity thing is taken care considering the APG does not about how many instances are running and simply direct the traffic to the Web APP URL.

I hope i was able to communicate properly what i wanted to ask.

Many Thanks,
Tayyab Suhail

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

Thank you very much @hspinto, i will go through this link and get back to you in case of any questions. Appreciate your help!

@hspinto 

 

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

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?

@hspinto 

 

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

1 best response

Accepted Solutions
best response confirmed by hspinto (Microsoft)
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.

View solution in original post