2014 IEEE 6th International Conference on Cloud Computing Technology and Science
Broker as a Service (BaaS) Pricing and Resource Estimation Model Mohammad Aazam Computer Engineering Department Kyung Hee University, Suwon South Korea
[email protected]
Eui-Nam Huh Computer Engineering Department Kyung Hee University, Suwon South Korea
[email protected] vastly manageable and scalable virtual servers, computing resources storage resources, virtual networks, and network bandwidth, according to the requisite and affordability of customer. Therefore, it can provide solution package for the media revolution, if designed wisely. In cloud datacenters, virtual machines consume a lot of memory, which makes it even more important to have an enhanced and efficient resource management mechanism. It is required to deploy and integrate cloud computing with the advanced technologies on media processing, transmission, and storage, keeping in view the industrial and commercial trends and models. With the trend going on, an average user generally generates content very quickly, until runs out of storage space [2]. Users tend to use and communicate content very frequently, which requires to be accessed conveniently. Since cloud makes it possible to store, manage, and share large amounts of digital media, one of its key aspects is media management. Cloud computing provides handy solution for processing content in distributed environments. Moreover, data can be accessed far and wide devoid of the trouble of keeping large storage and computing devices. Cloud computing also provides ease of sharing large amount of media content. Cloud computing provides added features of collaboration and editing of content. Besides, if content is to be shared, downloading individual files one by one is not easy, as in social media. Cloud computing caters this issue by allowing contents to be retrieved at once by other parties, with whom the content is being shared.
Abstract—Rapidly increasing digital media has triggered the importance of cloud computing. Cloud computing provides ease of management and ubiquitous access facility to the growing digital content. The ratio with which digital content has been increasing, it now requires multiple clouds to interoperate for the purpose of scalability, efficient service provisioning, and better management. This scenario is known as inter-cloud computing or cloud federation. One of the key entities in inter-cloud computing is cloud broker. Cloud broker is a match-maker between the service provider and the customer. Broker plays its role to reserve resources and perform pricing and billing. Service providers experience customers having different traits and characteristics. Some tend to utilize all of the resources, while others may quit in between, due to various reasons. Based on the characteristics of customers, their resources are predicted and pricing is performed. We have proposed a model which addresses this issue by determining resources and prices, on the basis of historical record of each customer. We have implemented our model using Java / NetBeans 8.0 and tested on CloudSim 3.0.3 toolkit. The results presented here justify and endorse our model. Index Terms—Cloud broker; media cloud; inter-cloud computing; cloud federation; resource management; broker as a service (BaaS).
I. INTRODUCTION The rapidly increasing digital media content has convincingly outdone the traditional media; in consequence of which, longstanding and vast changes are required for the contents shared over the Internet. Video traffic over the Internet had surpassed global peer-to-peer (P2P) traffic in 2010 [1]. Apart from the amount of video exchanged through P2P file sharing, since 2012, Internet video has become over 50 percent and will reach 62 percent by the end of 2015. Including all forms of videos, the number will be approximately 90 percent by 2015 [2]. Although there are a lot of opportunities coming along with this media revolution, but at the same time, there are some challenges as well which have to be met. To address those challenges, sophisticated technologies, much better infrastructure, and powerful capabilities are required to be incorporated.
To manage the vastly increasing content and meeting users’ requirements, cloud resources now to be federated. This scenario is known as inter-cloud computing or cloud federation. A single cloud cannot handle content or users’ requests, as a result, two or more clouds have to interoperate and federate their resources. Interoperability is performed through an arbitrator, known as “cloud broker” or simply “broker”. Cloud federation involves transcoding and interoperability related issues, which also impact the overall process of multimedia content delivery. Cloud brokerage plays an important role in this regard. It allocates resources for the customers and performs negotiation between the involved parties. Based on the services consumed by the customer, broker performs billing and pricing as well. In this
Cloud computing has lately been advancing as a favorable and inevitable technology. Cloud computing platform provides 978-1-4799-4093-6/14 $31.00 © 2014 IEEE DOI 10.1109/CloudCom.2014.57
463
Amazon S3. Shadi Ibrahim et al. present [11] the concept of fairness in pricing in respect of micro-economics, not discussing how pricing should be done for different types of services. Nikolay Grozev et al. present basic taxonomies for inter-cloud architecture [12]. Buyya et al. present architectural fundamentals of inter-cloud computing in [13].
paper, we present a framework for advanced resource allocation by cloud broker in cloud federation environment. We also discuss the method of pricing and billing, according to different traits and characteristics of customers. The paper is further arranged in this way that section II discusses already done studies on this topic. Inter-cloud broker and our proposed model are discussed in section III. Section IV presents performance evaluation of our model. We conclude our paper in section V. II.
III.
CLOUD FEDERATION BROKER
Two or more clouds are federated to increase resources pool and create extended portfolio of resources through cloud broker. Broker performs the interoperability and arbitration related tasks to federate the resources. It then advertises and makes those resources available to the customers. Without broker, interoperability becomes an issue and both the parties involved, the service provider and the consumer, have to handle such things on their own, which may not be possible at times, specially in the case of customer, due to lack of such resources. Furthermore, handling heterogeneous customers with different types and scales of requests is not easy for service provider. Managing resources in prior and managing customers according to their requests, attributes, and characteristic becomes very important, for which broker is a vital entity.
RELATED WORK
Cloud federation is still an emerging paradigm, due to which, it lacks standard architecture for data communication, media storage, compression, and media delivery. Former studies mainly focus on presenting architectural blueprints for this purpose. Intel-HP viewpoint paper [3] presents industrial overview of the media cloud. It is stated that media cloud is the solution to be sufficient for radically increasing trends of media content and media consumption. For media content delivery, Quality of Service (QoS) is going to be the main concern. In our work presented in [4], we discuss it in detail by presenting end to end QoS provisioning mechanism using Flow Label of IPv6 and Multi-Protocol Label Switching (MPLS). To reduce delay and jitter of media streaming, better QoS is required, for which Z. Wenwu et al. [5] propose media-edge cloud (MEC) architecture. The authors present the MEC as a cloudlet, located at the edge of the cloud. MEC consists of storage space, central processing unit (CPU), and graphics processing unit (GPU) clusters. The MEC stores, processes, and transmits media content at the edge, thus incurring a shorter delay. In turn, the media cloud is composed of MECs, which can be managed in a centralized or peer-to-peer (P2P) way.
Cloud broker provides a single interface through which multiple clouds can be managed and their resources are shared [14]. Cloud broker operates outside of the clouds and controls and monitors the federated clouds. Broker’s prime purpose is to assist the customer in finding the most suitable provider and the service, according to customer’s needs, in accordance with the specified SLA. It provides its customers with a uniform interface to monitor and manage deployed services. Cloud broker uses a variety of methods, such as a repository for data sharing and integration across data sharing services to develop a commendable service environment and achieve the best possible deal and SLA between two parties, i.e., Cloud Service Provider (CSP) and Cloud Service Customer (CSC) [13]. Broker typically makes profit either by taking remuneration from the completed deal or by varying the broker’s spread, or some combination of both. The spread is the difference between the price at which a broker buys from seller (provider) and the price at which it sells to the buyer (customer) [15]. To handle commercial services, broker has a cost management system. A relatively narrow focused form is presented in [9]. Shown in figure 1, Cloud Broker includes application programming interfaces (APIs) and a standard abstract API, which is used to manage cloud resources from different cloud providers. Broker holds another abstract API for the negotiation of cloud service facilities with the customer. Different modules perform a specific task in broker’s architecture, e.g., registration of new services is handled by Service Registration Manager. Deployment of services and making them available is done by Deployment Manager. Similarly, each module has its own specific utility.
Park Ki-Woong et al. [6] present a billing system with some security features. To resolve different types of disputes in future, a mutually verifiable billing system is presented. Their work only focuses on the reliability of transactions made in purchasing and consuming resources. They do not focus on the overall resource management, pricing, refunding, or similar important features of cloud broker. Rogers Owen et al. present a resource allocation mechanism, but resource prediction and detailed billing, along with refunding issue is not considered [7]. Wang Wei et al. [8] propose a brokerage service for reservation of instances. The authors propose a brokerage service for on-demand reservation of resources, for IaaS clouds. Their work is limited to only ondemand jobs and they do not present anything beyond that. Jrad Foued et al. present a generic architecture of broker [9], which lacks resource management feature of brokerage. They present how broker handles service level agreement (SLA) management and interoperability of resources. Deelman Ewa et al. present performance tradeoffs of different resource provisioning plans [10]. They also present tradeoffs in terms of storage fee of
464
Inter-cloud Gateways are responsible for interoperability and transcoding related tasks. Inter-cloud Exchanges (ICX) are responsible for introducing attributes of cloud environment for inter-cloud computing. Inter-cloud Root contains services like, Naming Authority, Directory Services, Trust Authority, etc. CSC can directly access CSP(s) as well. But in that case, transcoding related tasks, SLA negotiation, and match-making is done by CSC itself.
depend upon customer’s behavior and its probability of using those resources in future. In this section, we present resource prediction and pricing model, extending our prior works [16], [17]. We formulate the estimation of required resources as: ᴪ ∗ (1 − x¯ ( ( | ) ) − ∗ (1 − ) (1) ℝ=∑ 0 ℝ ∊ { , , !"} Where ℝ represents required resources, ᴪ is the basic price of the requested service. In most of the cases, ᴪ is decided at the time contract is being negotiated. x¯ ( ( | ) ) is the average of service oriented relinquish probabilities (SOP) of a particular customer of giving up (relinquish) the same resource which it has currently requested. In case the customer is requesting this service for the first time, the default value set for x¯ ( ( | ) ) is 0.3. Because, the average of low relinquish probability (0.1 to 0.5, from complete range of 0.1 to 0.9) is 0.3. For simplicity, we have categorized customers into two types for this purpose, one having low ( ) relinquish probability and the other having high ( ) relinquish probability. Where, 0 < ≤ 0.5 , 0.5 < ≤ 1
(2)
x¯ (x¯ (∑& ( | )& )), ( | )'*+ ) -/ 2 > 0, (3) "$ ( ) = % 0.3 -/ 2 = 0 is the variance of SOPs. Customer can have a very fluctuating behavior in utilizing resources, which may lead to deception, while making decision about resource allocation. That is why, in our model, we have taken into account variance of relinquish probabilities, which helps determine the actual behavior of each customer. is a constant decision variable value, which is assigned by the broker to each user, according to its history of average overall relinquish probabilities (AOP). Here, it should be noted that
( | ) determines probability of the same service, which customer is requesting currently, while is overall probability, including all activities a particular customer has been doing. Last activity of the customer in this regard tells about its most recent probability. That is why, it has been given more importance and the average is taken again by adding last relinquish probability. In case of a new customer, when there is no historical data available, this value is set at low relinquish probability 0.3. "$() is Signum function, which represents case. With this formulation, cloud broker can determine future resource requirements. It is important for cloud broker to rightly decide while reserving resources and prevent precious resources
Figure 1. Broker’s architecture and communication scenarios.
A. Resource estimation and pricing model Cloud computing comes with pay-as-you-go billing model, allowing the customers to scale their capacity dynamically, according to their changing requirements and pay for the consumed resources. CSCs contact cloud broker to acquire the required service(s) at best price. Broker performs the negotiation and SLA tasks with CSP [15]. After the settlement of contract, the service is provided to the customer. In this regard, broker not only provides services on ad hoc basis, but also, it has to predict consumption of resources, so that they can be allocated in advance. Resource prediction allows more efficiency and fairness at the time of consumption. Prediction and pre-allocation of resources also
465
go waste. It will also help power consumption management, which is becoming a point of concern for cloud datacenters.
Implementation language Simulator Operating System (OS)
After predicting the future resource requirement, next step is price allocation and billing. We formulate generic pricing method as under: +
ρ67(8) = ∫ (ᴪ + ;? + ∗ @)
TABLE 2: KEY PARAMETERS’ SETTING FOR EVALUATION Parameters Range AOP 0.9 ~ 0.1 SOP 0.9 ~ 0.1 Service Price (ρ ) 100,150, 200,250,…,1000 Broker’s ratio (@ ) 10% Total services 10 Service duration( I ) in 1,2,3,4,5,6 months
(4)
+
ρ67(A) = ∫ (ᴪ + ;B + ∗ @)
(5)
B. Resource prediction for a new customer When different CSCs are requesting for a particular service, the broker has to analyze what number of resources have to be allocated for that service, based on the type of customer. For CSCs having low relinquish probability, priority in resource allocation is given. For those customers, who are absolutely new and broker has no past record for them, default probability is used. In other words, it is assumed that this new customer will be ‘somewhat’ loyal. That is why, relinquish probability is set to 0.3. While perfectly loyal customer would be having a probability of 0.1. Since cloud resources are precious and it is not advisable to take risk, thence, instead of assigning 0.1 probability value, we have assigned 0.3, which is the average probability of low relinquish. Figure 2 shows the unit of resources being predicted for new customers, for different types of registered services. This unit is then mapped to actual resources (memory, CPU, storage space, etc.), according to the type of service being offered and policies of a particular CSP. For example, a USD 100 cloud storage collaboration service is more I/O intensive. It requires more CPU as well as storage space. The CSP will map 9 to level one of its resource allocation actual mappings. In case the USD 100 service is related to database queries, then only I/O is intensive, not storage, because it requires read-only process. The CSP will perform mappings accordingly. This is how different units of resources are mapped to actual resources, based on the type of service. Similarly, for a USD 500 service, 45 units of resources are reserved.
Where ρ67(8) is the price for service C, which has been requested by a customer having relinquish probability ? . Similarly, ρ67(A) is the price determined for the customers having relinquish probability B . ;? is the decision variable for user ? , calculated through equation 6. ;B is the decision variable for user B , calculated through equation 7. @ is the ratio (e.g., 10% of the total amount) set the by broker, based on business contract and condition. More is the average overall probability and/or user characteristic ;, more would be the final price. ;? = ;B =
ᴪD ∗E8 F ᴪD ∗EA F
(6) (7)
Where G denotes the total of the profit earned so far by the service provider from the current customer. In case the customer is new, the average of profit earned is set as the profit to be earned by the service provider from the currently requested service. We represent this current profit as GH . More is the average profit, less would be the value of ;, which in turn, adds lesser amount in the final price. IV.
Java using NetBeans 8.0 CloudSim 3.0.3 Window 7 Home Premium
VALIDITY AND PERFORMANCE EVALUATION
In this section, we present evaluation of our proposed service model. We defined our service model through algorithm to evaluate the effectiveness in cloud computing business. Our main objective is to observe the influence of performance factors on the systems and test the feasibility of our method. A. Simulation Setup Table 1 shows the simulation environment while Table 2 shows basic parameters’ setting. System Memory
TABLE 1: SIMULATION SETUP Intel(R) Core(TM) i5-M430, 2.27 GHz 4 GB
Figure 2. Resource prediction for new CSCs, for different requested services.
466
C. Resource prediction for an existing customer
or existing and requested for service S before as well. The third scenario is discussed in subsection E. In case of scenario 1, since broker does not have any previous record of service utilization, it treats the CSC as somewhat reliable and determines pricing on the basis of low relinquish probability. In case of scenario 2, broker has the general record of CSC’s previous activities and its AOP can be determined. But CSC has requested for current service S for the first time, therefore SOP cannot be obtained. On the basis of AOP, pricing is done, categorizing CSC in either for Price-L (for low relinquish probability CSC) or Price-H (for high relinquish probability CSC). As shown in figure 4, if CSP has set basic price as USD 100, Price-L for that service would be USD 103.3 (because CSC would get different added services, like refunding, etc.), while USD 107.3 for Price-H. Therefore, CSC is treated accordingly, which in the end creates fairness. This strategy makes sure that if there is enough risk that a particular CSC would relinquish the service, the broker should have earned enough profit, such that when the resources are relinquished, broker does not have to bear loss.
For the returning/existing customers, CSP already has a historical record of its past activities and probabilities (AOP and SOP) with which CSC has been consuming resources. When characteristic of a particular customer is known, it is more reasonable and rational to determine and allocate resources accordingly. In this way, broker and CSP will be able to reserve right amount of resources and would be having least number of chances to lose profit. Figure 3 shows five different types of CSCs, having different SOPs and AOPs, requesting a particular service S. In this example, the result is presented for service price USD 100. The unit is greater for L customers, while it is smaller for H customers, because of their behavior. Since there are more chances of an H customer to relinquish the service(s), hence, more priority and quality is provided to the more loyal customer, having L probability. In case of CSC 1, having SOP = 0.47 (bold font in the figure) and AOP = 0.4, 22 units of resources are reserved for USD 100 service. In case of CSC 2, SOP = 0.27 and AOP = 0.4, 43 unit of resources are reserved. CSC 2 gets more resources as compared to CSC 1, because of its lower SOP. This shows that both these types of probabilities have their impact and final decision is made accordingly, which makes it sure that a CSC who has generally been loyal, but not so in case of some particular service, or vice versa, gets treated in view of that. CSC 5 gets most number of resources (65), because of being loyal not only generally (0.1), but also on the basis of currently requested service S (0.27).
Figure 4. Price estimation, for new customers.
E. Pricing for existing customer according to its characteristic In scenario 3, when a CSC has been requesting this service S before as well, price determination is on the basis of profit earned as well, other than relinquish probabilities. The idea is to give more incentive to a CSC from whom CSP has earned more profit. This encourages CSC to utilize more and more service(s) and be more loyal to the CSP. In figure 5, horizontal axis shows different instances of CSCs, while vertical axis shows price in USD. In case of CSC 1, the relinquish probability is high, 70%, and profit earned so far is low, USD 12. Therefore, for a USD 100 service, this CSC has to pay USD 112. Since CSP has the historical data of this CSC, the price is determined in a more realistic and fair way. If we compare this CSC 1 with CSC 1of subsection D (figure 4), it shows that when a CSC is new, it has to pay lesser amount, even if it lies in the category of Price-H. But in the case presented here, we know more chronological details about CSC 1, therefore, the pricing is more convincing, based on CSC’s characteristic. In case of CSC 2, having relatively lower relinquish probability, 42%, with CSP earned
Figure 3. Resource prediction for different types of CSCs, for USD 100 service.
D. Price estimation for a new customer Pricing is an important element in resource management. Due to heterogeneity in the types of CSCs and the services offered, pricing has to be dynamic. Pricing cannot be too generic, because it will create unfairness. Based on characteristics of a CSC and type of service requested, prices are determined. CSC can be altogether new, existing but requested service S for the first time,
467
ACKNOWLEDGMENT
relatively more profit, USD 25, the payable price is USD 105.8. In case of CSC 3, relinquish probability is 70%, but profit earned so far is USD 30, higher than the previous two cases. In this case, CSC 3 has to pay USD 109.3. CSC 4 is the best case in the presented result; having comparatively lowest relinquish probability and highest earned profit for CSP, has to pay USD 103.6.
This research was supported by the MSIP (Ministry of Science, ICT&Future Planning), Korea, under the ITRC (Information Technology Research Center) support program (NIPA-2014(H0301-14-1020)) supervised by the NIPA (National IT Industry Promotion Agency). The corresponding author is Prof. Eui-Nam Huh. REFERENCES [1]
[2] [3] [4]
[5] [6] Figure 5. Price estimation according to customer characteristic, for USD 100 service.
V.
[7]
CONCLUSION AND FUTURE WORK
[8]
Digital content is rapidly increasing in the cloud, due to which, its management has become an issue. Many of the services are extended from already existing services, for which clouds have to interoperate with other clouds and amalgamate their resources. Amalgamating resources of different clouds creates inter-cloud environment, also known as cloud federation. Cloud broker works as a mediator to perform interoperability between different clouds and introduce resources to the customers. Cloud federation and brokerage are in their start; therefore cloud arena still lacks standard architecture. Broker has to perform different tasks, ranging from match-making, resource allocation, pricing, billing, up to refunding. Due to diversity in the types of services and traits of customers, CSPs experience different customers. CSPs have to handle customers according to their needs and characteristics. For this purpose, it is very important to have a model that takes into account customer's characteristics and allocates resources as well as prices accordingly. In this paper, we focused on this issue and present resource prediction and pricing mechanism, on the basis of characteristics of customers. This model will help CSPs and broker to have a more realistic and fair mechanism in this regard. It will also help attract more customers, since this model is based on giving incentive to more reliable and loyal customer. In future, we intend to extend our model for more varied parameters, specially in terms of QoS and the types of devices.
[9] [10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
468
Mingfeng Tan, Xiao Su, "Media Cloud: When Media Revolution Meets Rise of Cloud Computing", Proceedings of The 6th IEEE International Symposium on Service Oriented System Engineering, 12-14 Dec., 2011. Cisco-White-Paper, "Cisco Visual Networking Index – Forecast and Methodology, 2010–2015," June 1, 2011 "Moving to the Media Cloud", Viewpoint paper, Intel-HP, Nov. 2010. Mohammad Aazam, Adeel M. Syed, Eui-Nam Huh, "Redefining Flow Label in IPv6 and MPLS Headers for End to End QoS in Virtual Networking for Thin Client", in the proceedings of 19th IEEE APCC, Bali, Indonesia, 29-31 August, 2013. Z. Wenwu, L. Chong, W. Jianfeng, and L. Shipeng, "Multimedia Cloud Computing," Signal Processing Magazine, IEEE, vol. 28, pp. 59-69, 2011. Park, Ki-Woong, et al. "THEMIS: A Mutually verifiable billing system for the cloud computing environment." Services Computing, IEEE Transactions on 6.3, 300-313, 2013. Rogers, Owen, and Dave Cliff. "A financial brokerage model for cloud computing." Journal of Cloud Computing 1.1, 1-12, 2012. Wang, Wei, et al. "Dynamic cloud resource reservation via cloud brokerage”, 33rd IEEE ICDCS 2013. Jrad, Foued,et al. "SLA based Service Brokering in Intercloud Environments." CLOSER. 2012. Deelman, Ewa, et al. "The cost of doing science on the cloud: the montage example." Proceedings of the 2008 ACM/IEEE conference on Supercomputing, 2008. Shadi Ibrahim, Bingsheng He, Hai Jin, “Towards Pay-As-You-Consume Cloud Computing”, IEEE International Conference on Services Computing, Washington, USA, July 4-9, 2011. Nikolay Grozev and Rajkumar Buyya, “Inter-Cloud Architectures and Application Brokering: Taxonomy and Survey”, Wiley Software: Practice and Experience, 2012. Buyya, Rajkumar et al., "Intercloud: Utility-oriented federation of cloud computing environments for scaling of application services." Algorithms and architectures for parallel processing. 13-31, 2010. Mohammad Aazam, Eui-Nam Huh, “Inter-Cloud Architecture and Media Cloud Storage Design Considerations” in the proceedings of 7th IEEE CLOUD, Anchorage, Alaska, USA, 27 June – 02 July, 2014. Al-Amin Hossain, Eui-Nam Huh, “Refundable Service through Cloud Brokerage”, in the proceedings of 6th IEEE CLOUD, California, USA, 28 June – 03 July, 2013. Mohammad Aazam, Eui-Nam Huh “Advanced Resource Reservation and QoS Based Refunding in Cloud Federation”, in the proceedings of 33rd IEEE GLOBECOM, Austin, Texas, USA, 8-12 December, 2014. Mohammad Aazam, Eui-Nam Huh “Framework of Resource Management for Intercloud Computing”, Mathematical Problems in Engineering, vol. 2014, 1-9, 2014.
