4

I'm looking into restructuring the application that I'm working on to find a way that will cut costs and give us a lot more room for scalability. In essence, the application is currently hosted on Azure as one large web app which users can log into, do some computationally expensive work on data stored in memory on the web app, and then eventually log off.

When looking into another way to scale this, one idea was to use Worker Roles. Instead of doing the processing on the web app, which currently requires us to use a fairly expensive pricing tier, we could use Service Bus to pass messages with the relevant data to a Worker Role instance, which would do this processing and send back the results.

The most cost-effective way to do this it seems, would be to create a small instance of a Worker Role for each user that logs on, which would deal exclusively with their requests (using, for example, a queue named after the user's ID) and then be destroyed when the user's session ends.

I have the code to determine when to spin up an instance, how to pass these messages back and forth and when to shut an instance down, but I'm having difficulty finding documentation for any methods or API calls that would allow me to do this easily. The closest I can find for deleting an instance is described here, but I can't find anything for creating them.

What is the best way to spin instances up and down on Azure? What alternatives are available to me? I'm also happy to hear alternative proposals on how to architect this.

Cœur
  • 37,241
  • 25
  • 195
  • 267
Dan McElroy
  • 426
  • 4
  • 19

2 Answers2

4

The most cost-effective way to do this it seems, would be to create a small instance of a Worker Role for each user that logs on, which would deal exclusively with their requests (using, for example, a queue named after the user's ID) and then be destroyed when the user's session ends.

I would not recommend this approach. Here are my reasons:

  • The number of Virtual Machine cores are limited in a subscription. Imagine a scenario that you get 1000s of users logged in into your application. Creating 1000s of Worker Role instances would not be allowed by Azure. You would need to take special permission from Microsoft to do that.
  • Spinning up a VM takes time. When you create a new Worker Role deployment for your user, it is not instantaneous. Depending on the complexity of your role, it may take anywhere from 5 - 10 minutes to start a new Worker Role instance.
  • It's not an effective approach. Your basic idea is to create a new Worker Role instance when a user logs in is based on the assumption that user will do some compute intensive task. What if the user doesn't want to perform this intensive task (I may be wrong here because I don't know much about your application). Then in that case, you have created a VM instance which is of no use. Again your assumption is that user will always log out. What if the user simply closes the browser? How will you detect that user has left your application and you would need to terminate the worker role instance you created for that user.
  • It's not an efficient approach. The whole premise of Cloud Computing is built around shared resources. Having a VM dedicated for a user does not sound like an efficient approach.

Possible Solution

Instead of spinning of new worker role instances, may I suggest you take a look at scaling options. Basically the idea is to start with a shared pool of Worker Role instances. When a user logs in and start a task, web role writes a message in Service Bus queue which gets dequeued by a worker role instance which does the work and return the result. Set a maximum number of tasks a worker role could process. If you exceed that count, spin off a new instance of worker role. You can take a look at auto-scaling feature available in Azure Management Portal or look at some 3rd party services which can do this scaling for you.

Gaurav Mantri
  • 128,066
  • 12
  • 206
  • 241
  • Thanks for this very comprehensive answer. I had suspicions that this might not work for a few reasons, thanks for clearing this up. So my issue with having a limited number of worker roles is that these jobs need to start immediately, and the duration of these jobs can vary from milliseconds to minutes. My worry is that with a limited number of single-core worker roles (trying to keep costs down), if several long-running jobs were ran at the same time, other users would be effectively blocked. Apologies for not being more specific about the application. – Dan McElroy Apr 22 '15 at 10:49
  • Dan, that's why recommended using scaling approach. As more clients push the work that needs to be done by your worker role instances, there will be more messages in the queue. Autoscaling can be triggered based on the number of messages. If there are more messages than a threshold (which you decide), that would be an indication that you will need more worker role instances and can then scale your instances accordingly. You may want to look into XS instances instead of small ones if your task is not process intensive. Last I checked, you can have 6 XS instances for price of 1 Small instance. – Gaurav Mantri Apr 22 '15 at 10:56
  • By XS nodes, are you referencing the A0 nodes detailed here? http://azure.microsoft.com/en-us/pricing/details/cloud-services/ If so, I think I would require at least one dedicated core per worker role, though preferably more (some jobs would benefit from multi-threading, and all are quite process intensive). Does the following sound like a viable approach: 2 queues, one for sending jobs and the other for sending results. Worker roles take the jobs off the queue, start a Task (that is not awaited) and mark the message as complete, then through an event handler send a message back on completion? – Dan McElroy Apr 22 '15 at 11:23
  • `By XS nodes, are you referencing the A0 nodes detailed here? azure.microsoft.com/en-us/pricing/details/cloud-services` - Yes. Regarding your approach, I think it makes sense. Marking messages as complete at the time of dequeuing could be tricky because you may encounter an error in between processing and that message will never picked up by another worker role. If I were using Storage Queues, I would hide the message for sufficiently long time (time it takes to process the job) and then delete the message once job is finished. – Gaurav Mantri Apr 22 '15 at 11:28
1

Using dedicated instances for each user is not a good idea. Utilization will be low, costs will be high and each subscription has a cap of 20 CPU cores by default, so you'll have to first ask support to increase the quota.

A better approach would be to combine the web and worker role into one - once more load comes in you just scale it out. You can still use whatever is convenient for you to store the user requests - a queue or whatever else. So IIS of the role will be pushing data there and the "infinite loop" part (role enrty point Run()) will be processing the data and storing the results and then the web server will fetch the results and feed them back to users.

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979