Chapter 3. Service Selection under Stochastic Performance
3.2 An Iterative Compound Approach
This section presents an iterative compound approach to the service selection problem in a dynamic cloud environment where services’ response time varies stochastically due to dynamically changing workload or other uncertainties. The approach aims to minimize the costs of providing a composite cloud service, including the fees for using existing services and potential penalties for QoS violation. To cope with services’ stochastic performance, the approach is based on an iterative process, similar to the structure in [7], consisting of a deterministic optimization step using Integer Linear Programming (ILP) [12], a simulation step for evaluating potential QoS violation, and an adaptation step preparing for service reselection. The three steps are repeated until a good enough solution is found based on some criteria.
At the first step, costs and deterministic response time, i.e. the average response time, of services are used to formulate an optimization problem and then find an optimal solution
using ILP [12]. To prepare the formulation of an ILP optimization problem, we need to derive the expected QoS values of an entire composite cloud service from the attribute values of each constituent service. According to [7] , the following symbols are defined. The set of all tasks within a composite cloud service is labeled with I. The set of services functionally appropriate to execute a certain task i is labeled with Ji, The decision variables xij ∈ {0, 1} indicate whether a service j is selected to conduct task i. Cost is represented by c and response time is indicated by r. Regarding branches, we label the set of paths with L. Referring to the composite cloud service in Figure 3.1, there are two paths within the XOR-block, thus L = {1, 2}. The tasks within a branching are covered by the set IL ⊆ I, whereas Il ⊆ IL represents the set of tasks within path l. We label the set of the remaining tasks which are not located within any branching, the Sequences in a composite cloud service. Therefore, the goal of the service selection problem is to minimize the following formula. To make it amenable to ILP, we formulate the objective function and conditions in Table 3.3 based on the example composite cloud service in Figure 3.1.
min(∑ ∑ c
Table 3.2: Worst-case aggregation functions for response time and costs
Sequence AND-block XOR-block
response time∑ ∑
Table 3.3:
Formulation of ILPThe second step simulates the execution of the entire composite cloud service using the services selected in the first step in a dynamic environment where the response time of each service varies stochastically. To estimate the effects of the selected services’ stochastic performance, the simulation will be conducted for many times and each service’s response time might vary at different runs. The stochastic variation of each service’s response time is determined by one of its QoS attributes: the standard deviation in Table 3.1. Therefore, in some runs the resultant response time of the entire composite cloud service might exceed the requirement of SLA, incurring penalty fees. The total costs of the entire composite cloud service across all the simulation runs, including both service usage costs and penalty fees, will then be used to evaluate the influence of stochastic performance variation.
Based on the simulation results of the second step, the third step makes an adaptation to the previous service selection. In [7], each time only one task within the composite cloud
service is chosen for service reselection. This task is called critical task and is determined as the algorithm shown in Figure 3.2. The benefit value is calculated according to the following equation, representing the difference between the selected service’s standard deviation of response time, σs, and the standard deviation values of the other candidate services of task i, σj. The weight for a task i, ω, is calculated by dividing the number of the simulation runs where task i has been executed and the SLA for response time has been violated by the total number of runs. The task with the highest weighted benefit is chosen as the critical task for the adaptation step.
benefit =m ∈ ( ) for all i ∈ I do
benefit = computeBenefit(i);
ω = computeWeight(i);
if ωbenefit ≥ highestBenefit then highestBenefit = ωbenefit;
criticalTask = i;
end if end for
Figure 3.2
:
Critical Task DeterminationThe adaptation step in [7] , as shown in
Figure 3.3,
tends to reduce SLA violation through excluding services with standard deviation larger than current selected one from next iteration’s ILP optimization. However, choosing services with smaller standard deviation of response time does not always lead to reduced costs since those services might have higher prices.i = criticalTask;
js = getSelectedServiceOf(i);
for all j ∈
Ji doif
≥ then setBanned(j);
end if end for
Figure 3.3: Adaptation step in [7]
In the following, we propose a new adaptation step to further improve the effectiveness of service selection. In contrast to Figure 3.3, our approach, as shown in Figure 3.4, considers both services’ costs and the potential penalty incurred by response time deviation at the adaptation step in order to minimize the total costs of running a composite cloud service.
i = criticalTask;
js = getSelectedServiceOf(i);
for all j ∈
Ji doif 𝑜
+ * 𝑒
>𝑜
+ *penaltythen
setBanned(j);
end if end for
Figure 3.4: Our Adaptation step
The entire service selection approach conducts iterative execution of the above three steps, controlled by two parameters, greed and anneal, as in [7]. The parameter greed determines how often the three steps are repeated as long as new iterations reduce total costs.
Another parameter anneal controls for allowing worse solutions temporarily as starting points for further iterations.