Scalable workers in Azure Service Fabric

Question

I am trying to migrate to service fabric existing solution. Part of it is the number of workers that listen queues. For example I have some queues:

Task1_Queue, Task2_Queue ... TaskN_Queue

For each queue there is some logic of processing messages of them, let's say workers. They do different tasks like generate huge report files and upload to Azure Storage or do small updates in database.

The question is how to design services in order to have good scalability of workers. My thoughts were:

Option 1 - Each queue will have separate stateless service. No easy way to autoscale single service.

Option 2 - Implement workers as separate actors, and have single stateless service to listen queues and call actors. Pros - autoscaling out of box, as for each message from queue new actor will be created. Cons - actors will be disposable.

Does data need to persist between task runs? If so, actors become much less feasible. — Michael Sharp
No, basically worker get request message process it in some way and returns execution — Vasyl Senko
As for option 1: you can create multiple instances of a service to scale out. So you could have multiple service instances processing the same queue — Peter Bons
The problem with option 1 is no way to create new instances and remove them on fly depending on load — Vasyl Senko
Aren't stateless services generally 1-1 with a cluster node? If this is true in your scenario can you create a nodetype specifically for the service and configure the scale-set to auto re-balance based on desired metrics (cpu usage, mem usage etc) — Alex Zevenbergen

LoekD LoekD · Accepted Answer · 2017-08-18T10:59:38

Consider creating 2 types of stateless services:

Service that monitors the task queue depth. This service will create and remove instances of Service 2 based on the amount of queued tasks.
Service that processes queued jobs.

Scalable workers in Azure Service Fabric

1 Answers