There are many situations where a large number of batch jobs need processing, and where the jobs need to be re-prioritized.
For example, A website offering two level of services for file conversions — one for unpaid users versus other for paid subscribers. When a user uploads a presentation file, the conversion jobs are runs in batches on the system side, and the converted file is published after the conversion. It then becomes necessary to be able to assign a level of priority to the batch processes for each type of users i.e. Subscribers vs Free users.
Explanation of the Cloud Architecture
A queue is used in controlling batch jobs. The queue need only be provided with priority numbers. Job requests are controlled by the queue, and the job requests in the queue are processed by a batch server. In Cloud computing, a highly reliable queue is provided as a service, which you can use to structure a highly reliable batch system with ease. You may prepare multiple queues depending on priority levels, with job requests put into the queues depending on their priority level and to apply prioritization to batch processes. The performance (number) of batch servers corresponding to a queue must be in accordance with the priority level thereof.
Implementation of this Architecture in Amazon Web Services (AWS)
In AWS, the queue service is the Simple Queue Service (SQS). Multiple SQS queues may be prepared to prepare queues for individual priority levels (with a priority queue and a secondary queue). Moreover, you may also use the message Delayed Send function to delay process execution.
- Use SQS to prepare multiple queues for the individual priority levels.
- Place those processes to be executed immediately (job requests) in the high priority queue.
- Prepare numbers of batch servers, for processing the job requests of the queues, depending on the priority levels.
- Queues have a message “Delayed Send” function. You can use this to delay the time for starting a process.
There are several advantages of this Architecture. 1) You can increase or decrease the number of servers for processing jobs to change automatically the processing speeds of the priority queues and secondary queues. 2) You can handle performance and service requirements through merely increasing or decreasing the number of EC2 instances used in job processing. And 3) Even if an EC2 were to fail, the messages (jobs) would remain in the queue service, enabling processing to be continued immediately upon recovery of the EC2 instance, producing a system that is robust to failure.
One needs to be careful though as depending on the balance between the number of EC2 instances for performing the processes and the number of messages that are queued, there may be cases where processing in the secondary queue may be completed first, so you need to monitor the processing speeds in the primary queue and the secondary queue.
