Presentation given in 6'th International Conference on Cloud Computing, CloudCom, IEEE, Singapore, 15-18 December, 2014 With the increasing cloud popularity, substantial effort has been paid for the development of emerging elastic cloud services, consisting of different units distributed among virtual machines/containers in different clouds. Due to the software stack and deployment complexity in single and multi-cloud scenarios, developing and managing such services is impeded by a lack of tools and techniques for understanding the elasticity relationships among individual service units, which influence the service's overall elasticity. In this paper we characterize the elasticity relationships, and develop mechanisms for analyzing them, based on service monitoring information and elasticity requirements. From collected monitoring information we abstract the elasticity behavior of the whole cloud service and individual units, over which we design a customizable algorithm for relationships analysis. We illustrate our approach via several experiments with an elastic data service for M2M platforms, highlighting the importance of determining elasticity relationships for the development and operation of elastic services.

1. Daniel Moldovan, Georgiana Copil,
Hong-Linh Truong, Schahram Dustdar
On Analyzing Elasticity Relationships
of
Cloud Services
Distributed Systems Group (http://dsg.tuwien.ac.at/)
Vienna University of Technology (http://www.tuwien.ac.at/)
d.moldovan@dsg.tuwien.ac.at
http://www.infosys.tuwien.ac.at/staff/dmoldovan/
CloudCom 2014

2. CloudCom 2014
Motivation
Elasticity
2
Start with an initial lighter configuration
NOTE:

3. CloudCom 2014
Motivation
Elasticity
3
Scale/reconfigure service unit when load increases
NOTE:

4. CloudCom 2014
Motivation
Elasticity
4
Scale back service unit when load decreases
NOTE:

5. CloudCom 2014
Motivation
Elasticity
5
Scale/reconfigure different service units if situation
demands it
NOTE:

6. CloudCom 2014
Motivation
Developing intelligent controller: a little prediction
6
Enforce Elasticity Capability
(scale in/out, reconfigure)
Effect/Impact w.r.t.
requirements on ALL UNITS ?
Change in Load
Understand how the elasticity of a service unit is influenced by another unit
i.e. if one unit “moves” towards violating its requirements, what happens with the
other units of the service
NOTE:

7. CloudCom 2014
Communication
dependencies
Elasticity control
processes
Elasticity Relationships
Causes and Importance
7
e.g., when adding a Data Node instance, the Data
Controller must be informed, to execute data balancing
tasks
e.g., if Event Processing is bottleneck, and thus is
scaled out, the bottleneck might transfer to the Data
end

8. CloudCom 2014
Elasticity Relationships
Types
8
Direct
relationships
Indirect
relationships
e.g., throughput on Event Processing is dependent on
response time
e.g., CPU usage on Data End is dependent on
throughput on Event Processing which is dependent
on response time

9. CloudCom 2014
Elasticity Relationships
Definition
9
𝑬𝒍𝑹𝒆𝒍𝒂𝒕𝒊𝒐𝒏𝒔𝒉𝒊𝒑:
𝑪𝒉𝒂𝒏𝒈𝒆𝑭𝒄𝒕, 𝑫𝒆𝒍𝒂𝒚𝑭𝒄𝒕, 𝑨𝒕𝒕𝒆𝒏𝒖𝒂𝒕𝒊𝒐𝒏𝑭𝒄𝒕
Behavior i
Behavior j

10. CloudCom 2014
Elasticity Relationships
Stakeholders
10
Different users might care about different types of relationships
NOTE:

11. CloudCom 2014
Aim
Objective
• Determine relationships influencing the service’s elasticity
11
Approach
• Abstract and analyze service behavior w.r.t. elasticity requirements
Challenges
• How to abstract service behavior
• Lack of complete requirements
• Inadequate monitoring information
Scale IN/OUT Reconfigure
Elasticity Controller Elasticity Behavior Analysis MonitoringElastic Cloud Service Elasticity Relationships Analysis

12. CloudCom 201412
Background
Elastic cloud service

13. CloudCom 2014
Abstracting Service Behavior
Elasticity Energy
13
El. Boundary
u
El. Boundary
l
If we determine relationships between concrete values, in case of elastic
services which scale in/out at run-time, those absolute values might not hold
after such elasticity capabilities are enforced
Thus, we abstract service behavior with respect to its requirements, which
give us for each metric collected from the service a lower and upper boundary
NOTE:
NOTE:

14. CloudCom 2014
Abstracting Service Behavior
Elasticity Energy
14
El. Boundary
u
El. Boundary
l
Initial El Energy =
𝐸𝑙𝐵𝑜𝑢𝑛𝑑𝑎𝑟𝑦 𝑢
− 𝐸𝑙𝐵𝑜𝑢𝑑𝑎𝑟𝑦 𝑙
ElWork=
𝑥∗𝐿𝑜𝑎𝑑𝑈𝑛𝑖𝑡(%)
𝐼𝐸𝑙𝐸𝑛𝑒𝑟𝑔𝑦
ElEnergy = 100− 𝐸𝑙𝑊𝑜𝑟𝑘 𝑙𝑜𝑎𝑑
− 𝐸𝑙𝑊𝑜𝑟𝑘 𝑖𝑑𝑙𝑒

15. CloudCom 2014
Background
Structuring monitoring information
15
Daniel Moldovan, Georgiana Copil, Hong-Linh Truong, Schahram Dustdar, MELA: Monitoring and Analyzing Elasticity of Cloud Services, 5'th International
Conference on Cloud Computing, CloudCom. Bristol, UK, 2-5 December, 2013, http://dx.doi.org/10.1109/CloudCom.2013.18
VM 10.0.0.i
mi
VM 10.0.0.j
mi mj mk…
VM 10.0.0.k
mi mj mk…
…
Data Node Unit
Data Controller
Unit
Data End
Topology
…
Event Processing
Topology
Elastic
DaaS
…
VM 10.0.0.i
mi mj mk…
VM 10.0.0.j
mi
Service Unit Instance
Service Unit Instance
mi
mi
Custom aggregation
<rule> := operation "=>" metric
<operation>:= operator "(" operand { "," operand } ")"
<operator> := "+"|"-"|"*"|"/"|"AVG"|"MAX"|"MIN“
|"CONCAT"|"FIRST"|"LAST"|"SET"
<operand> := metric | number | string
Collect only relevant monitoring information,
and logically associate it to the service structure
NOTE:

16. CloudCom 2014
Background
Determining complete requirements
16
Daniel Moldovan, Georgiana Copil, Hong-Linh Truong, Schahram Dustdar, MELA: Monitoring and Analyzing Elasticity of Cloud Services, 5'th International
Conference on Cloud Computing, CloudCom. Bristol, UK, 2-5 December, 2013, http://dx.doi.org/10.1109/CloudCom.2013.18
Data Node Unit
Data Controller
Unit
Data End
Topology
…
Event Processing
Topology
Elastic
DaaS
mt1
ms
mi
mj
mk
…
ml
mp
…
mt2
User-Defined Elasticity Requirements
ms <= x mt1 > y
for each metric
when REQUIREMENTS are fulfilled
record Upper and Lower encountered values
…
Upper Boundary
Lower Boundary
Upper Boundary
Lower Boundary
? ?
?
?
?
?
Starting from a reduced set of initially known requirements, bridge requirements
knowledge gap by determining requirements for all service metrics
NOTE:

17. CloudCom 2014
Elasticity Relationships Analysis
Single relationship analysis
17
Depending on the Elasticity
Capability to be enforced,
determine relationships between
the metrics influenced by the
capability and other service
metrics
NOTE:

18. CloudCom 2014
Elasticity Relationships Analysis
Complete service relationships analysis
18
Traverse structure tree and analyze relationships between:
• El. Metrics from same Elastic Element with same Level in same Sub-Tree
• El. Metrics from different Elastic Elements with same Level in same Sub-Tree
• El. Metrics from different Elastic Elements with same Level in different Sub-Tree
• El. Metrics from different Elastic Elements with different Level and same/different Sub-Tree

19. CloudCom 2014
Elasticity Relationships Analysis
Complete service relationships analysis
19
Traverse structure tree and analyze relationships between:
• El. Metrics from same Elastic Element with same Level in same Sub-Tree
• El. Metrics from different Elastic Elements with same Level in same Sub-Tree
• El. Metrics from different Elastic Elements with same Level in different Sub-Tree
• El. Metrics from different Elastic Elements with different Level and same/different Sub-Tree

20. CloudCom 2014
Elasticity Relationships Analysis
Complete service relationships analysis
20
Traverse structure tree and analyze relationships between:
• El. Metrics from same Elastic Element with same Level in same Sub-Tree
• El. Metrics from different Elastic Elements with same Level in same Sub-Tree
• El. Metrics from different Elastic Elements with same Level in different Sub-Tree
• El. Metrics from different Elastic Elements with different Level and same/different Sub-Tree

21. CloudCom 2014
Elasticity Relationships Analysis
Complete service relationships analysis
21
Traverse structure tree and analyze relationships between:
• El. Metrics from same Elastic Element with same Level in same Sub-Tree
• El. Metrics from different Elastic Elements with same Level in same Sub-Tree
• El. Metrics from different Elastic Elements with same Level in different Sub-Tree
• El. Metrics from different Elastic Elements with different Level and same/different Sub-Tree

22. CloudCom 2014
Elasticity Relationships Analysis
Complete service relationships analysis
22
Traverse structure tree and analyze relationships between:
• El. Metrics from same Elastic Element with same Level in same Sub-Tree
• El. Metrics from different Elastic Elements with same Level in same Sub-Tree
• El. Metrics from different Elastic Elements with same Level in different Sub-Tree
• El. Metrics from different Elastic Elements with different Level and same/different Sub-Tree

23. CloudCom 2014
Elasticity Relationships Analysis
Framework
23

24. CloudCom 2014
Elasticity Relationships Analysis
Prototype
• Elasticity Relationships Analysis R-based Prototype
• Change Function
• Linear dependency function
• Delay Function
• Lag between time series
24
𝑚𝑒𝑡𝑟𝑖𝑐(𝑡) ∶ 𝑒𝑙𝑒𝑚𝑒𝑛𝑡 = 𝑐𝑜𝑛𝑠𝑡𝑎𝑛𝑡 + 𝑐𝑜𝑒𝑓𝑓𝑖 ∗ 𝑚𝑒𝑡𝑟𝑖𝑐𝑖 (𝑡) ∶ 𝑒𝑙𝑒𝑚𝑒𝑛𝑡 𝑥 + …

25. CloudCom 2014
Elasticity Relationships Analysis
Scenario
• Elastic Data-as-a-Service
• Runs in private cloud
• Bursts in public cloud
25
Event Processing Topology Data End Topology

26. CloudCom 201426
User-Defined Elasticity Requirements
responseTime:EventProcessing ≤ 100 ms cpuUsage:DataNode ≤ 90 %
Elasticity Relationships Analysis
4 Experimental scenarios

27. CloudCom 201427
Elasticity Relationships Analysis
Scenario 1: DaaS on private cloud

28. CloudCom 201428
Elasticity Relationships Analysis
Scenario 1: DaaS on private cloud
A user would look at monitoring information and select what relationships s/he
would like to analyze
NOTE:

29. CloudCom 201429
Elasticity Relationships Analysis
Scenario 1: DaaS on private cloud

30. CloudCom 201430
Elasticity Relationships Analysis
Scenario 1: DaaS on private cloud
From the determined relationship,
one can estimate what is the
maximum throughput achievable
before CPU usage on data end
becomes a bottleneck (e.g, 80-
90%), and design a predictive
controller accordingly
NOTE:

31. CloudCom 201431
Elasticity Relationships Analysis
Scenario 2: DaaS on public cloud
Almost identical relationship also
discovered on the public cloud,
meaning the relationship is due to the
service implementation
NOTE:

32. CloudCom 201432
Elasticity Relationships Analysis
Scenario 3: DaaS on multiple clouds
In the multi-cloud scenario, the
relationship is attenuated (i.e., 0.18 as
multiplicative constant instead of 0.29),
indicating that CPU usage is less of a
bottleneck (increases more slowly with
throughput)
NOTE:

33. CloudCom 201433
Elasticity Relationships Analysis
Scenario 4: DaaS with elasticity controller
User-Defined Elasticity Requirements
responseTime:EventProcessing ≤ 100 ms
cpuUsage:DataNode ≤ 90 %
+

34. CloudCom 201434
Elasticity Relationships Analysis
Scenario 4: DaaS with elasticity controller
User-Defined Elasticity Requirements
responseTime:EventProcessing ≤ 100 ms
cpuUsage:DataNode ≤ 90 %
+
Depending on individual goals, a user might be interested in other determined
relationships, such as that when a particular elasticity controller is used, the achieved
throughput is only half the connection rate in 0.54% of the cases (Adjusted r),
indicating a potential bottleneck in the service
NOTE:

35. CloudCom 2014
Conclusions
• Concepts
• Elasticity Relationship
• Elasticity Energy/ Work
• Mechanisms
• Abstracting behavior of elastic cloud services w.r.t. requirements
• Analyzing elasticity relationships
• Framework/Tools
• MELA: Monitoring and analyzing elasticity of cloud services
(http://tuwiendsg.github.io/MELA/)
Work partially supported by the European Commission in terms of the CELAR FP7 project
(http://www.celarcloud.eu/)
Distributed Systems Group (http://dsg.tuwien.ac.at/)
Vienna University of Technology (http://www.tuwien.ac.at/)
35