Share via

when you cannot scale out

Player Two 1 Reputation point
2021-12-16T21:40:02.39+00:00

have a web app service that uses environment variables to communicate with a service bus and message queues, so a scale option is not feasible.
my question is how can we set up two or more web app services and load balance between them but maintain IP affinity

Azure App Service
Azure App Service

Azure App Service is a service used to create and deploy scalable, mission-critical web apps.

0 comments No comments

2 answers

Sort by: Most helpful
  1. Ajay Kumar N 28,266 Reputation points Microsoft Employee Moderator
    2021-12-27T07:44:52.937+00:00

    @Player Two , Adding to VidyaNarasimhan-2409 suggestions.

    Just to highlight, stateful or stateless app - If your application is stateful, scaling up would be best, while if your application is stateless, scaling out gives you more flexibility and higher scale potential.

    Depending on your requirement, you could have Application Gateway Infront of the WebApps and 'have override host header in the request'

    The App Service Plan (ASP) is the scale unit of the App Service apps.
    If the plan is configured to run five VM instances, then all apps in the plan run on all five instances.
    If the plan is configured for autoscaling, then all apps in the plan are scaled out together based on the autoscale settings.

    If you are using auto scaling, it makes sense for your apps to be stateless since if the app scales in the user session on that instance will be lost.
    Scaling out shouldn’t matter since the client would be affinitized to one instance that is still present.

    =====
    I wish to add more information to give you more insight on the concepts. So, apologies for the long post.
    I’m sharing all the necessary information you may be interested to know.

    Yes, when the app runs, it runs on all the VM instances configured in the App Service plan.

    If multiple apps are in the same App Service plan, they all share the same VM instances.
    If you have multiple deployment slots for an app, all deployment slots also run on the same VM instances.
    If you enable diagnostic logs, perform backups, or run WebJobs, they also use CPU cycles and memory on these VM instances.

    Azure WebApps by default have ARR Affinity cookie enabled, this cookie pairs a client request to a specific server.
    However, Azure Web Apps is a stateless platform and, in an environment, where we are scaling the Website across multiple instances, the ARR Affinity cookie will be bound to a specific server.
    In case, the server is no longer in rotation, then all the requests corresponding to the ARR Affinity cookie will fail.

    Was this answer helpful?


  2. Vidya Narasimhan 2,126 Reputation points Microsoft Employee
    2021-12-18T06:13:13.997+00:00

    Hi @Player Two

    I have not understood well the first part of your statement on why you cannot scale out. To help you with the second part where you are looking for sticky sessions, App Service uses ARR affinity to ensure requests are passed on to the same instance and this is turned on by default. Please see this link https://azure.github.io/AppService/2016/05/16/Disable-Session-affinity-cookie-(ARR-cookie)-for-Azure-web-apps.html

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.