Analytical Evaluation of Resource Estimation in Web Application Services

Cloud computing is the emerging technology for offering infrastructure and applications as SaaS on on-demand and also it is base technology of different fields like artificial intelligence, IoT, Machine Learning etc. [1]. Rapid elasticity is one of the important characteristics of CC, it provides right amount of computing resources among pool of resources according to web application needs. It provision and de-provision the resources depends on the incoming traffic without human intervention. The real time cloud providers like Amazon, Google and IBM are also offering this elasticity service using different names like auto scaling, scalability etc... This property is attracting global market for web customers to move their services into clouds [2]. In terms of cloud computing services the elasticity facing two challenges over-provisioning and under-provisioning, then the over-provisioning leads to excess computing cost for infrastructure wastage, while under-provisioning leads unavailability of resources.

Herbst et al. [3] and Aljahdali et al. [4] have suggested scalability, elasticity, and efficiency are used to calculate performance of web based applications. In this situation dynamic scaling shows solution of elastic cloud computing. It has ability to scale up and scale down the resources when the sudden workload at runtime. Most of the cloud providers are offering SaaS applications due to the e-commerce of global market and the use of multi-tenancy. As per the publications scalability are utility perspective [5-7]. There is necessity to understand the effected system components to understand the scalability nature of the data center. Lorido-Botran et al. [8] have conducted survey on scalability of infrastructure and resource estimation challenges. Estimating computing infrastructure and implementing an efficient auto-scaler for web services are challenging tasks due to various factors. These factors are dynamic workload, infrastructure requirement, and cost estimation.

This will be beneficial for the organization, those who are client of cloud applications. CSP is expected to have advanced scalar measures. However, putting scalar measures onto its edge, which is, its customers' networks will estimate the cost of the web application. Threshold is one of the ideas to measure customer usage on cloud and it ensures that customer bill. These services can be considering cloud computing characteristics. There is a necessity to research to fulfill these gaps.

The objective of this paper is two-fold, one is evaluated the analytical model to predict or estimate the required number of servers for web application depending on the workload, at the same time second one is to validate this analytical model with experimental model. The specific objective is to analyze the challenges in the implementation of an auto-scaler in clouds.

The rest of this paper is structured as following; literature of various works related to this paper have discussed in Section 2. Section 3 depicts analytical evaluation process of cloud datacenter architecture. The validated experimental modeled is presented in Section 4. Section 5 discussed about results of analytical and experimental model and finally section 6 drawn about the conclusions.

1.png

Figure 1. Web application hosting architecture of Amazon Web Services

The web server’s runs simultaneously depending on the incoming traffic, each server have a buffer to execute workload. The scale up and scale down can be varying automatically based on the QoS parameters such as utilization of computing infrastructure among all running instances [25]. When the average utilization of all running instances exceeds an upper threshold, then a trigger will fire to launch a new server that will be added to the pool of resources and configured at the load balancer. Similarly scale down also. The workload can be distributed midst of available application servers. Like most above architecture, a datacenter has a database server to be used for storing configuration information and incoming workload.

Figure 2 depicts queuing model of Figure 1 web application architecture. In this queuing model arrivals are aggregated before entering the datacenter. The architecture can be divided into 3 parts load balancer, computing tire, storage tire. This paper mainly focuses on computing tire. So, the elastic computing tire modeled as parallel queuing models each server follows as M/M/1. In practical scenario each server has a buffer queue that was indicated as M/M/1/k but this paper assumed it as M/M/1 model for our convenience. This approximation is highly reliable to the real-time environment with large finite buffers, such as datacenter, where the buffer loss probability is negligible [26, 27]. The cloud architecture follows each system as open queue M/M/1 model.

2.png

Figure 2. Queuing model of web application hosting architecture

It considers that the request arrival rate and service rate follow a Poisson distribution with where λ arrival rate and µ service time. Where S is represents as total number of running servers and we assumed the queuing-based loss probability is zero. The effective arrival rate ƛ is equals the arrival rate λ/S. The computing tire presented in Figure 2. The load balancer distributes the arrivals midst of available servers. The transition probability will be equal to 1/S for each server. If where All servers have the same computing capacity, μ_i=μ, and the arrival rate of each instance is λ_i = λ/S,

Then the mean utilization of resource U is calculated as follows in Eq. (1):

$\mathrm{U}=\frac{\lambda}{\mathrm{S} \mu}$     (1)

where,

U is the utilization,

λ arrival rate,

S total number of servers,

μ service rate.

The utilization of the resources depends on the arrival rate and services rate followed by number of servers.

The little’s formula is used to calculate throughput of datacenter. Based on the Figure 3 when the arrival rate λ will be distributed among S instances, then each server throughput is λ/S. The total number of required servers can be calculated by using utilization, when upper threshold utilization is 100% then the formula is:

$S=\frac{\lambda}{\mu}+1$      (2)

In Eq. (2) the required number of servers is impacted based on arrival rate and server power capacity. The scalability allows servers to be scale up or down based on the QoS metrics. Here the threshold value plays important role to generate trigger when utilization of the datacenter exceeds or decreased. When the server threshold exceeds pre-defined value for example 80% then it generates trigger to scale up resource similarly the server threshold below pre-defined value for example 30% then it generates trigger to scale down resources. Finally, the total required number of servers calculated using this procedure depending on the workload.

3.png

Figure 3. Elastic computing of application servers

The scalability depending on the CPU utilization, it can measure using upper and lower threshold, the upper threshold exceeds servers should be scale up depending on network in. Similarly, when it is in lower threshold, the instances should be decreased. The threshold value is depending on the time of request throughput. For example, when we consider adding or removing instances by 10% of the running instances at the time of the threshold triggering, the provisioning can be expressed as follows:

When

U > U_T, S_req = [S +| 0.1 × S|]

U < L_T, S_req = [S − | 0.1 × S |]

The required number of servers calculates process depending on the $\lambda$ and utilization of the datacenter. These are the rules to scale and descale virtual servers.

$\frac{\lambda}{\mathrm{S\mu}} \leq \mathrm{U}_{-} \mathrm{T}$      (3)

Thus,

S = U_T −1 × λ/μ + 1     (4)

where, U_T indicates upper threshold, if we assume 80%, then the required servers calculated as follows:

S = 1.25 × λ/μ + 1     (5)

Similarly, lower threshold also calculated as follows above procedure. Thus, number of servers required to be added to depending on the workload of λ is:

S_res = 1.25 × λ/μ + 1 − Srun_res      (6)

where, 1.25 indicates the 80% threshold value followed by total datacenter utilization and Srun_res is running instances, these are committed with load balancer.

This paper considers analytical model and experimental model to estimate the computing resources on web application datacenter. Based on the present cloud environment, the analytical model assumed no loss probability of the traffic due to the elasticity property, thus it can handle enough resources when the high traffic occurs. Finally results of the experimental model have been validated to the analytical model. The experimental test bed was hosted on Amazon AWS and it was same structure of the analytical queuing model presented in Figure 1. The network in and out has been taken from two different sources. The input http traffic flow has been following the Poisson distribution. The incoming traffic or arrival rate fixed 400 requests per second and varied up to 20000 requests per second.

The experiment initially started with 5 running instances. Each instance was configured as a web server, and hosted the web application on it, web page size was adjusted to achieve 100% CPU utilization where the 100 requests per second for each instance, which is the target capacity of instance. Initially the experiment will handle 500 requests per second, and it will close to 100% average CPU utilization of auto scaling group. Based on average resource CPU utilization add more instances when high load spike occurs. This experiment used 80% average CPU utilization to add instances and the scaling size to be 2 instances in the default period of auto scaling in Amazon. The incoming traffic varied from 400 to 20000 requests per second.

Figure 5 depicts throughput of cloud datacenter. X-axis indicates different traffic rates. There is significant difference between analytical and experimental model. In the analytical evaluation assumes there is no loss probability of the incoming traffic but in the real time scenario based on the bandwidth or network there may be loss probability occur. For example, from Table 1 when 16500 packets entered in the network based on the bandwidth this experiment allows 15205 requests only.

5.png

 

Figure 5. In relation between incoming traffic and throughput

Figure 6 shows that required number of instances allocated during the experimental testbed run and analytical model. When load of 4000 Req/sec entered in the data center, results show that 51 instances is the minimum number of instances required to ensure that the average utilization is below 80%. According to the number of required instances can be calculated analytically as: S = 1.25 × 4000/100 + 1 = 51, which comes in line with the experimental results. In the experimental results there is no significant difference due to the elasticity and throughput of the datacenter. When the incoming traffic increases required servers also increased.

From the Figure 7 results the CPU utilization significantly impacted when the high load spike occurs, such that the workload increases the corresponding utilization also increases. As per our assumptions the results show that the average utilization does not exceed the upper threshold in both analytical and experimental models. In the experimental model throughput significantly varies when compare to the analytical, but utilization do not have significant difference.

6.png

Figure 6. In relation between incoming traffic and number of required servers

7.png

Figure 7. In relation between incoming traffic and CPU utilization

Table 1 shows that comparison between analytical and experimental results performance metrics. These are throughput, required number of servers and utilization of the computing resources. When the incoming traffic increases required number of servers also increases. Based on this sever optimization the cloud customer will gain knowledge on required number of the servers to maintain datacenter.

Table 1. Comparison of analytical results and experimental results