Scalability Patterns for Platform-As-A-Service

1. 2012 IEEE 5th International Conference on Cloud Computing Scalability Patterns for Platform-As-A-Service Marco Ughetti Telecom Italia, TILab, Italy Claudio A Ardagna, Ernesto Damiani, Fulvio Frate, Davide Rebeccani Universita degli Studi di Milano, Italy 13th November, 2012. Presented By, Chidambara Nadig.

2. Abstract • Platform as a Service is a cloud based approach where enterprises have little to do with the underlying cloud infrastructure. • Installing, configuring and managing the underlying middleware, operating system and hardware is done by the cloud provider. • Thus, Scalability becomes an important factor to decide, • The capabilities of each virtual resource in the cloud. • The number of resources in the cloud. • This paper presents few Scalability Patterns for PAAS infrastructureand a method to automatically manage scalability. Scalability Patterns for Platform-as-a-Service

3. IAAS, PAAS and SAAS • IAAS – Infrastructure as a Service. • PAAS – Platform as a Service. • SAAS – Software as a Service. Scalability Patterns for Platform-as-a-Service

4. Scalability Patterns for Platform-as-a-Service

5. Levels of Abstraction in Cloud Services. Scalability Patterns for Platform-as-a-Service

6. Some examples Scalability Patterns for Platform-as-a-Service

7. Actions on Resource Scaling • Vertical Scaling – Scale Up – Additional Resources are added to a single machine when the load increases. The resources can be either physical resources added to a server, or virtual resources dynamically assigned to a virtual machine or its applications. • Horizontal Scaling – Scale Out – New machines are added to the system providing more software and hardware resources. • Scale Down – Releasing Resources when they are not necessary. Scalability Patterns for Platform-as-a-Service

8. Scalability Patterns • Single Platform Pattern (SPP) • Shared Platform Pattern (ShPP) • Clustered Platform Pattern (CPP) • Multiple Shared Platform Patter (MShPP) • Multiple Clustered Platform Patter (MCPP) Scalability Patterns for Platform-as-a-Service

9. Single Platform Pattern (SPP) • Each customer is given a complete virtual machine with a platform installed on it. SPP is single tenant scenario. • Resource Utilization is scarce. • Scalability is low because the number of virtual machines and platforms is linear in the number of customers. Scalability Patterns for Platform-as-a-Service

10. Shared Platform Pattern (ShPP) • A Multitenant scenario. • One platform is installed on a set of virtual machines and is shared by multiple tenants. • Each tenant has a right to manage a portion of the platform and deploy their services on it independently. • Performance of the platform is maintained by up-scaling and down-scaling the resources assigned to the virtual machine. Scalability Patterns for Platform-as-a-Service

11. Whenever the load increases – degrading the performance metrics of the platform – RAM, CPU, or bandwidth can be increased. • On the other hand, when the load decreases, resources can be freed and made available to other processes in the architecture. • In ShPP resources are shared and therefore need to be managed to ensure security and isolation among tenants. • Provides High utilization. • However, ShPP doesn’t provide linear scalability increase due to increased overheads for resource management. Scalability Patterns for Platform-as-a-Service

12. Clustered Platform Pattern (CPP) • A single platform is deployed supporting clustering and is shared by all tenants. • Multiple instances of the platform components can be deployed in different machines of the cluster. • Similar to ShPP, CPP manages shared resources preserving security and isolation among tenants. • This pattern also implements load balancing, PAAS monitoring, and elastic auto-scaling. Scalability Patterns for Platform-as-a-Service

13. CPP provides high resource utilization, since the machines in the cluster are shared among different tenants. • CPP provides some scalability as system resources can be incrementally extended. • The Clustered Platform Pattern also promises high reliability and availability due to increased redundancy. Scalability Patterns for Platform-as-a-Service

14. Multiple Shared Platform Pattern (MShPP) • MShPP is an extension of ShPP. • Initially a single Shared Platform is deployed. • Upon an increase in the load, additional resources (CPU, RAM or bandwidth) are assigned to maintain the performance metrics. • In case additional resources are not sufficient, a new platform is deployed and a part of the existing tenants are migrated to the new platform along with the resources they own. Scalability Patterns for Platform-as-a-Service

15. When the load decreases, the additional platforms can be removed causing the tenants to migrate back to the available platforms. • MShPP has lower manageability than ShPP owing to the fact that tenants have to be migrated from one platform to another when a new platform is deployed. • MShPP provides high resource utilization. • Its scalability depends on the specific scenario and number of deployed platforms. • In the worst case, when all tenants experienced a traffic peak, a platform is deployed for each tenant and therefore scalability of MShPP is equivalent to the one of SPP. • In the average case, MShPP provides high scalability. Scalability Patterns for Platform-as-a-Service

16. Multiple Clustered Platform Pattern (MCPP) • MCPP is an extension of CPP. • At initialization time, a single, shared, multi-tenant platform supporting clustering is deployed. • Upon an increase in the load, additional resources (i.e., machines in the cluster) are added to maintain the performance level. • In case the extended cluster is not sufficient to manage the new load, a new platform supporting clustering is deployed, and a part of the existing tenants are migrated to the new clustered platform together with the services they own. Scalability Patterns for Platform-as-a-Service

17. When the load decreases, the additional platforms can be removed causing the tenants to migrate back to the available platforms. • MCPP has the lowest manageability among patterns. • MCPP usually provides high utilization of resources, although utilization may decrease in case of multiple platform deployments. • Promises • High Scalability. • High Availability. • High Reliability. Scalability Patterns for Platform-as-a-Service

18. Overview Scalability Patterns for Platform-as-a-Service

19. Performance Measurement • Performance Metrics at the Platform Level • Total Count (TC) – Number of messages forwarded to a given end point. If the metrics exceeds a known threshold, the performance could be affected and an alarm is raised. • Fault Count (FC) – Number of messages that resulted in a fault while being forwarded to the end point. • Minimum Time (MinT) • Maximum Time (MaxT) • Average Time (AveT) Time Taken to send a request to an end point and receive a response. Scalability Patterns for Platform-as-a-Service

20. Performance Metrics at the Host Level • CPU Load (CL) – CPU Utilization on host and guest systems. High values of CL in a Virtual Machine signifies a problem in the fulfillment of request messages backlog. • Memory Occupancy (MO) – Memory Utilization on host and guest systems. Services that require a huge amount of data may require substantial portions of memory at the detriment of other services. • Network Utilization (NU) – Utilization of the network bandwidth. High values of NU may suggest re-allocation of external resources to manage a peak of requests. • Host Availability (HA) – Number of virtual machines available and accessible through the network. The falling of the HA under a pre-defined threshold indicates the new for new machines. Scalability Patterns for Platform-as-a-Service

21. Performance Monitoring • Based on the certain measurements of the Performance metrics, certain alarms are raised. • Two Categories of Alarms: • Message Alarm – A message alarm is raised when: • System is not able to manage the message queue efficiently. • Average message delivery time is above a preset threshold. • The difference between the maximum and minimum message time is above a preset threshold. • Processing Alarm – A process alarm is raised when service execution may involve high execution time or a lot of resources. Scalability Patterns for Platform-as-a-Service

22. Alarm Rules HIGH and LOW thresholds in the above table can be defined on the basis of previous experimental tests and/or expert knowledge. Scalability Patterns for Platform-as-a-Service

23. Alarm-driven selection of scalability patterns The initial node ∗ represents the basic installation scenario in which different tenants share the same platform with default configurations. Scalability Patterns for Platform-as-a-Service

24. The two-fold Monitoring Approach • Upon an increase in the load that raises a message alarm, the algorithm moves to node ShPP and applies a ShPP pattern • If a processing alarm is raised, the algorithm moves to node CPP and applies a CPP pattern. • When the ShPP pattern is not sufficient to solve further alarms, it moves to node MShPP in case of message alarms or to node CPP in case of processing alarms. • The algorithm moves from CPP to MCPP for both types of alarms, while it moves from MShPP to MCCP in case of processing alarms. Scalability Patterns for Platform-as-a-Service

25. Experimental Setting • WSO2 Platform is a cloud-deployable, Java-based service-oriented platform. • A WSO2 platform with default configurations is used as the experimental environment. • A realistic scenario is simulated where concurrent requests come from different clients. • Each test case starts with 20 active clients sending SOAP (Simple Object Access Protocol) requests, which ramp up to a maximum of 100 clients. • All test cases have a duration of 60 seconds. • Load Varying is done by increasing the requests per second (rps) from 10rps to 500 rps. Scalability Patterns for Platform-as-a-Service

26. Baseline Measurement without security RT – Response Time (in a logarithmic scale) TPS – Transactions per Second rps – Requests per second Scalability Patterns for Platform-as-a-Service

27. Baseline Measurement with security RT – Response Time (in a logarithmic scale) TPS – Transactions per Second rps – Requests per second Scalability Patterns for Platform-as-a-Service

28. Performance of ShPP without security Scalability Patterns for Platform-as-a-Service

29. Performance of ShPP with security Scalability Patterns for Platform-as-a-Service

30. Performance of CPP without security Scalability Patterns for Platform-as-a-Service

31. Performance of CPP with security Scalability Patterns for Platform-as-a-Service

32. Comment.. • Result 1 – Security causes a substantial decrease in the performance of a SOA deployed on the cloud. • Result 2 – ShPP results in a performance gain both on TPS and RT with respect to the baseline. • Result 3 – CPP provides a further improvement with respect to ShPP. Scalability Patterns for Platform-as-a-Service

33. THANK YOU! Scalability Patterns for Platform-as-a-Service