Analytics of Big Data on Clouds using Auto-scaling frameworks

1. TEMPLATE DESIGN © 2008
www.PosterPresentations.com
Auto-Scaling Frameworks for Big Data Analytics on Clouds
 The primary goal of big data analytics is to help companies make more
informed business decisions.
 Uncover hidden patterns and unknown correlations between data.
 High-performance analytics necessary to determine the relevance of data.
 Gartner states that through 2015, 85% of Fortune 500 organizations will
be unable to exploit big data for competitive advantage. [1]
 Traditional data processing tools cannot handle a large volume of data.
 Google’s MapReduce programming model is able to handle big data.
 MapReduce requires multiple compute resources to process large tasks.
 The demand to process data varies based on the current period.
 A MapReduce model can be used together with Cloud Computing.
 Cloud computing enables companies to consume compute resources as a
utility rather building and maintaining computing infrastructures in-house.
 To handle variable load while processing data, a technique known as
Auto-Scaling is employed.
 An Intermediary enterprise handles user
jobs from a single client enterprise and
executes those jobs on resources acquired
from a public cloud provider to form a
virtual private cloud for the users.
 The broker is hosted in the intermediary
enterprise.
 The public cloud provider charges the
broker c_pub dollars an hour per
resource.
 The broker charges the user c_pvt dollars
per second.
 A novel proactive [3] and a reactive [4] auto-scaling framework which uses
a price model that can lead to an increase in the profit for the broker
(intermediary enterprise) and a reduction in the user cost at the same
time.
 Both frameworks handle SLA-driven advanced reservation requests as
well as well as On-Demand requests.
 A detailed performance analysis focusing on broker profit and user
cost for a prototype subjected to various combinations of system and
workload parameters is performed and key insights into system behavior
is presented.
 System II: A system that can scale up if it can not fit a request on the
resources available.
 Resources are scaled down when they are no longer needed.
 Comparing broker profit and total user cost of System II with System I.
 System III: The users purchase resources directly from Amazon.
 There is no broker present in this system.
 Comparing total user cost of System III with System I and System II.
 Auto-Scaling is the ability to modify the capacity for the user’s cloud
infrastructure based on traffic patterns.
 Benefits of Auto-Scaling:
 Fault tolerant
 Highly available
 No Capacity Planning
 Amazon’s CloudWatch allow users to set thresholds for Auto-Scaling.
 Qubole [2] offer cloud based data analytics services based on the
MapReduce programming Model with Apache’s Hadoop and Hive.
 Qubole uses resources from the Amazon Cloud and allows auto-scaling
based on user’s workload.
 Qubole offers cost savings by optimizing data processing tasks.
 However, these services do not handle deadlines with individual user
jobs which perform the data analytics tasks.
Two types of Auto-Scaling techniques are discussed:
 A proactive framework that scales resources based on predictions from
a machine learning engine (MLE). This system scales independent off the
user demand.
 A reactive framework that scales resources when a request arrives to
the system. This system scales depending on the user demand.
Effect of Load Factor on BP and UC
 Load Factor (f) – is the ratio of the number of requests generated with
an arrival rate of λlow to the total number of requests generated during
the experiment.
Performance metrics:
 Broker profit (BP) - is the profit a broker earns ($/hour )
 Total User cost (UC) - is the amount charged to the user ($/hour)
 The number of resources in the pool used by the user requests need not
be determined a priori and are controlled dynamically thereby reducing
the cost for capacity planning.
 Overall, System I preforms better than System II and System III in terms
of Broker Profit and User Cost.
 The Auto-Scaling frameworks accept a MapReduce workload that
contain jobs to analyze big data. Other types of workloads may also be
handled by the Auto-Scaling system.
 Both frameworks allow users in an enterprise for example, to submit
Advance Reservation as well as On-Demand requests to a private cloud
provided by the intermediary cloud provider.
 The reactive framework provides a minimum grade of service to ensure
that a certain percentage of user requests are guaranteed to be
executed.
Introduction 1 Contributions 5
The Broker Model
3
Other Systems for Performance Evaluations 7
Conclusions 9
This research is supported by the Natural Sciences and Engineering
Council of Canada (NSERC) and TELUS
----------------------------------------------------------------------------------------------------
[1] Gartner Report, Big Data Management & Analytics, http://www.gartner.com/technology/topics/big-data.jsp.
[2] Qubole, http://www.qubole.com/, Accessed March 2015.
[3] A. Biswas, S. Majumdar, B. Nandy and A. El-Haraki, "Automatic Resource Provisioning: a Machine Learning based Proactive
approach," in Proc. of International Conference on Cloud Computing Technology and Science (CloudCom), Singapore, 12 2014.
[4] A. Biswas, S. Majumdar, B. Nandy and A. El-Haraki, "An Auto-scaling Framework for Controlling Enterprise Resources on Clouds," in
Proc. of the 15th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid), Shenzhen, 05, 2015.
Acknowledgements and References 11
Auto-Scaling 2
Auto-scaling decisions can be made:
Reactively: the system reacts to changes in user workload.
 Scaling conditions based on a target metric reaching some threshold.
 Set a threshold for a metric which triggers an adjustment of resources.
Proactively: the system tries to predict future resource requirements in
order to ensure sufficient resource is available ahead of time.
 Based on time series analysis or control theory.
 Predict the workload based on past demand.
Types of Auto-Scaling 3
http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/
WhatIsAutoScaling.html Section “What is Auto Scaling”
4
Internet
Single Client Enterprise
Broker Virtual Private Cloud
Resources
End Users
Public Cloud
Provider
Intermediary
Cloud Provider
Auto-Scaling frameworks 6
Sample Performance Results (Proactive System) 8
 BP decreases with f. System I earns more profit that System II.
 UC decreases with f. System I charges users a lesser amount that
System II and System III.
 BP increases with increase in Service Time and Laxity Factor and
System I earns more profit that System II.
Effect of Service Time and Laxity on BP
Anshuman Biswas
Systems and Computer Engineering
Carleton University
anshuman@sce.carleton.ca
Supervisors: Shikharesh Majumdar, Biswajit Nandy
Systems and Computer Engineering
Carleton University
{majumdar,bnandy}@sce.carleton.ca
Collaborator:
Ali El-Haraki
TELUS
User requests have Service
Level Agreements (SLAs):
Arrival Time, Earliest start
time , Execution time and
Deadline
RequestHandler
User
Request
MatchMake
Sched
Reactive
Autoscaler
Dynamic
Resouce
Pool
Manager
Decision
Maker
GoS
Decision Maker
Predictive
Autoscaler
Dynamic
Resource
Pool
Manager
RequestHandler
Machine Learning
Engine
MatchMake
Sched
User Request
Reactive Auto-Scaler
Proactive Auto-Scaler
The Reactive Auto-Scaler:
 Request Handler (RH) is responsible for handling user requests.
 RH forwards this request to Decision Maker (DM) which decided whether
to accept or reject the request based on two operations.
DM sends the request to the Matchmaking and scheduling component (MMS)
which is responsible for matchmaking and scheduling the request.
If MMS cannot schedule the request, DM then invokes the reactive auto-scaler.
 A criterion for the reactive Auto-Scaler for acquiring resources is based on
grade of service (GoS).
The GoS is specified by the client enterprise.
The system described uses the blocking ratio (B) as the GoS.
B is the proportion of requests that cannot be completed before the expiry of
their deadlines and are therefore rejected by the system.
 For the reactive Auto-Scaler, DM consults with a GoS.
 Framework provides a minimum Quality of Service (QoS) for the users.
 Acquiring and releasing a resource is based on these three rules:
Rule I: When B > Bspec acquire resource, where Bspec is the desired value of B
(GoS) maintained by the broker.
 Rule II: When (Broker Profit)i > 0, acquire ith resource.
Rule III: When (stopi) = current time, release ith resource, where stopi is the
stop time for the ith resource.
The Proactive Auto-Scaler:
 This broker replaces the GoS module with the Machine Learning Engine
(MLE) Module.
 MLE predicts the requests arriving in the future and then auto-scales.
 Auto-scaling resources is based on Rule II and Rule III from the Reactive broker.
 MLE predicts after a set number of requests have arrived in the system.
The reactive/proactive auto-scaling system is known as System I.
Future Work 10
Detailed performance analysis using reactive auto-scaling technique.
Additional simulation experiments for various other combination of system
and workload parameters are being planned.
Using traces of real workload in simulation can lead to interesting insights
into system behaviour and performance.