Application of the Goals Model

We define, hereunder, stability goals and runtime tactics determined above using our runtime goals modelling. Then, we provide an example of a runtime goal instance.

Stability goals Performance and QualityOfAdaptation are dedined as follows.

Goal Achieve [Performance] Informal Definition

For every request received, the request processing should be accom- plished within the performance parameters defined in the SLA of the client issuing the request.

Formal Definition

∀ r:Request, c:Client

ExecuteRequest (r) ⇒ ♦ ≤ c.SLA(ResponseTime)

Node identifier n1:Self-awareArchitectureNode

Weight w = 1.0

Metric ResponseTime: Request → Time

def: the duration of processing request starting from client submit-

ting the request till submitting the response back to the client

Objective

ResponseTime = ResponseTime ≤ c.SLA(ResponseTime)

Tactics T1: VerticalScaling T3: HorizontalScaling T6: Concurrency T7: DynamicScheduling

Goal Achieve [QualityOfAdaptation] Informal Definition

Any quality attribute should not be worse than 20% of the threshold in SLA for more than 300 seconds.

Formal Definition

∀ r:Request, c:Client

QualityAttributes(r) ⇒ ♦5min≤ 20% c.SLA(QualityAttributes)

Node identifier n1:Self-awareArchitectureNode

Weight w = 0.7

Metric QualityAttribute: Request → Time

def: the quality attributes of processing requests should not be worse

than 20% of the threshold in the client SLA for more than 300ms.

Objective

ResponseTime = ResponseTime ♦300sec≤ 20% c.SLA(ResponseTime)

Tactics T1: VerticalScaling T3: HorizontalScaling T6: Concurrency T7: DynamicScheduling

Tactic VerticalScaling Unique identifier T1 Informal Definition

increase the number of VMs or their capacities

Object VMs Pre-condition

T otalCP U capacity of running VMs ≤

T otalCP U capacity of hosts running in the datacenter

Limits max(T otalCP U capacity) of hosts running in the datacenter Functionality

increaseCPUCapacity(vm: VM) ∨ increaseCoresNum(vm: VM) ∨ runNewVM()

Post-condition Waiting Requests are migrated to the new VM Variations T1.1: increase CPU capacity of 1 running VM

T1.2: increase the number of cores of 1 running VM T1.3: add 1 VM to running VMs

Tactic VMsConsolidation Unique identifier T4 Informal Definition

shut down hosts running least number of VMs and migrate their VMs to other hosts

Object Hosts, VMs

Pre-condition number of hosts running in the datacenter ≥ 2 Limits min 1 host running in the datacenter ∧

min 1 VM running

Functionality

migrateVMs(host: Host) ∨ shutdown(host: Host)

Post-condition Requests are migrated to VMs Variations T4.1: shutdown 1 host

An instance of the Runtime Goal Performance is defined as follows.

Goal G1(n1, ti)

Client c:Client Request r:Request

Objective ResponseTimec= ResponseTime(r) ≤ 15ms

AdaptationAction T1.3

SatisfactionDegree v = 14ms

Environment Runtime Goals Ge(ti) = {G1(N2, ti), G1(N3, ti), ...}

Environment Runtime Tactics Te(ti) = {N2.T4.1, N3.T1.3}

6.6

Experimental Evaluation

The main objective of the experimental evaluation to examine the stability goals and assess associated overhead when using the instantiated architecture and goals modelling in comparison with a foundational self-adaptive architecture (described in section 5.4.2.1).

6.6.1

Experiments Setup

To conduct the experimental evaluation, we implemented the instantiated architecture using the widely adopted CloudSim simulation platform for cloud environments [5]. The benchmarks and testbed configuration of these experiments are as described in section 5.5.1.1 and 5.4.2.2 respectively. The initial deployment of the experiments is: 10 hosts running 15 VMs (5 x m4.large, 5 x m4.xlarge, 5 x m4.2xlarge). Initially, the VMs are allocated according to the resource requirements of the VM types. However, VMs utilise fewer resources according to the workload data during runtime, creating opportunities for dynamic consolidation.

We set the runtime goals model with stability attributes from the stability analysis results (section 4.4). Regarding the quality of adaptation, we challenge the experiments with the settling time (the time required by the adaptation system to achieve the adap- tation goal to assure stable provision of attributes) and the accuracy of adaptation (how well the adaptation converges towards adaptation goals) [25]. The stability objectives and weights are hypothetical to stress the architecture, as defined in Table 6.2.

Table 6.2: Settings of Stability Goals

Attribute Description Weight Metric Objective

Performance Response time 0.50 ms 25

Greenability amount of energy consumed for operating hosts

0.20 kWh 25

Operational cost cost of computational resources (CPUs, memory, storage, bandwidth)

0.20 $ 50

Settling time time required by the

adaptation system to achieve stability goals

0.10 ms

Accuracy of adaptation

how close adaptation goals are met within given tolerances

0.10 %

6.6.2

Results of Stability Goals

We report, first, on the average of stability goals at each time interval. The average response time results for service types 1 and 2 are depicted in Figure 6.5. As shown in the figure, the self-aware architecture was able to result in more stable response time compared with the self-adaptive architecture in both service types, while the latter caused violation in response time in early time intervals when the peak workload started. At the same time, the self-aware architecture was also capable of stabilising the operational cost for longer time intervals than the self-adaptive architecture. It is worth noting that stabilising response time with energy consumption and cost at the same time is very challenging in case of peak workload, that is why the self-aware architecture had some violations during the highest peak load.

Next, we report the results of stability goals on average 30 runs of the experiments total results in Table 6.3. The average response time of all requests for each service type

Figure 6.5: Average Response Time of Service Types 1 and 2 during Time Intervals is much better achieved by the self-aware architecture (average 62.85 ms compared to 20.02 ms). This came with the price of higher operational cost (168.94 $ vs. 205.84 $) and adaptation overhead (as shown below). In such case, the self-aware architecture considered keeping the response time without violations while not fully stabilising the cost within the constraint, as the response time weight is higher. Meanwhile, the difference in response time is much bigger than the difference in cost and energy. While the energy consumption in self-adaptive architecture was less (24.96 kWh), the self-aware architecture was capable of keeping it within the stability goal (28.52 khW).

Table 6.3: Average Results of Stability Attributes

Stability Attributes S# Architecture Pattern

Self-adaptive Self-aware Response time (ms) 1 73.73 16.00 2 63.49 22.92 3 58.41 18.56 4 58.90 21.10 5 59.74 21.54 avg. 62.85 20.02 Energy consumption (kWh) 1 23.80 28.52 2 25.33 28.52 3 25.02 28.52 4 25.33 28.52 5 25.33 28.52 avg. 24.96 28.52 Operational cost ($) 1 137.18 193.44 2 184.08 230.88 3 159.02 199.38 4 180.66 199.68 avg. 168.94 205.84

6.6.3

Results of Adaptation Properties and Overhead

Table 6.4 shows the average results of adaptation properties. The accuracy of adaptation is shown in terms of the violation percentage in response time for all service types, and the settling time is shown as total time periods where the response time was violated. As shown in the table, the percentage of violations in response time is slightly higher in the case of self-aware architecture in all service types. But regarding the total periods of time where the response time was violated, the self-aware architecture was capable of keeping it much less than the self-adaptive architecture. For instance, response time violation in the case of service type 1 was 12.96% and 14.23% for the self-adaptive and self-aware architectures respectively, while the total time of violations was 11232 sec compared to 4320 sec. Meanwhile, the self-aware architecture violations were less for service types 2 and 4, with better settling time. This reflects the higher quality of adaptations and tactics selection.

With respect to the associated adaptation overhead (calculated by the time spent in the adaptation process), the average overhead of self-aware architecture is 251.62 sec on average of all service types, compared to 164.90 sec of the self-adaptive architecture. Yet, the difference in response time is much bigger than the difference in overhead (compared with Table 6.3).

Table 6.4: Average Results of Adaptation Properties

Adaptation Property S# Architecture Pattern

Self-adaptive Self-aware Accuracy of adaptation (%) 1 12.96 14.23 2 26.44 24.40 3 15.78 17.19 4 20.90 20.91 5 27.51 28.31 avg. 20.72 21.01 Settling time (ms) 1 11232 4320 2 24192 9504 3 13824 5184 4 19872 6048 5 19008 8640 avg. 72921.60 6739.20

Adaptation overhead (sec) 1 157.80 247.40

2 168.50 260.60 3 162.70 249.00 4 167.40 249.60 5 168.10 251.50 avg. 164.90 251.62

6.6.4

Discussion

The proposed architecture with its generic components to embed runtime tactics have successfully instantiated many tactics for different quality and stability attributes and

enriched the self-aware patterns with self-management quality capabilities to meet the changing workload and stabilise quality requirements during runtime. Applied to the evaluation case, the hypothetical case has shown the potential to deliver values on the following attributes:

• Efficiency. The ability to incorporate a range of tactics for different stability at- tributes into the patterns diversify the catalogue space from which the adaptation actions could be selected and implemented during runtime to meet stability require- ments under a dynamic workload.

• Ease of application and use. The structure of the tactics for different quality at- tributes was embedded efficiently within the generic components of the reference architecture. Their interaction specification also took place within the process flow while taking advantage of the self-awareness knowledge available from different self- awareness levels.

• Multiple uses. The generic approach for instantiating the architecture allowed fea- turing different combinations of self-awareness capabilities. Thus, incorporating tac- tics approach could be used in any of these patterns according to the requirements of the system, without unnecessary overhead caused by self-awareness components. Generally, the proposed architecture and goals modelling for stability have proven feasibility when embedding tactics for different stability attributes. The proposed archi- tecture tends to diversify the possible adaptation actions to be taken during runtime. The quantitative evaluation has proven the ability of the architecture and goals model to efficiently realise stability and enhance the quality of adaptation.

6.7

Related Work

In this section, we discuss related work in the context of architecture patterns and goals modelling.