1. 1 SLA Enforcement in the Service Cloud Anja Grünheid Fakultät für Informatik Lehrstuhl III - Datenbanksysteme

2. 2 Agenda Introduction Quality of Service (QoS) Approach Request Scheduling (RS) Approach Priority Mechanisms (PM) Approach Conclusion

3. 3 Introduction: Background Increase in the deployment of service-oriented architecture (SOA) Different quality of service requirements for each customer Limited hardware and software resources

4. 4 Introduction: Service Level Agreements Defined for services invoked by the customer Formal contract between provider and customer to prevent customers from bad performance Violations of one SLA are punished with pre- defined penalties The complete penalty sum is dependent on the severity and number of overall violations

5. 5 QoS Approach: Introduction Developed by a research team of the Technical University of Munich, Germany Main ideas: Specific service model Control in the Large, static and dynamic resource management Control in the Small, adaptive SLA enforcement

6. 6 QoS Approach: Service Model Differentiation between Dynamic and static services Scale-out capable and non scale-out capable services

7. 7 QoS Approach: Static Resource Management

8. 7

9. 8 QoS Approach: Dynamic Resource Management

10. 8

11. 9 QoS Approach: Adaptive SLA Enforcement I

12. 9

13. 10 QoS Approach: Adaptive SLA Enforcement II Conformance c as measurement of service level agreement Definition of stepwise SLAs: Percentile constraints Deadline constraints

14. 11 QoS Approach: Adaptive SLA Enforcement III Lower service levels correspond to higher penalties Maximum of opportunity costs and marginal costs defines the current penalty value

15. 12 QoS Approach: Adaptive SLA Enforcement IV SLA as external component, penalty information is piggybacked in SQL The external database scheduler Normalizes the SQL query to confirm service classes Knows the execution times of service classes through execution monitoring plus a small overhead Gives either admission to access the database directly or queues the request according to a specified algorithm

16. 13 QoS Approach: Adaptive SLA Enforcement V

17. 13 QoS Approach: Adaptive SLA Enforcement V

18. 14 RS Approach: Introduction Developed by a research team consisting of researchers at the EPFL Lausanne, Switzerland, and IBM researchers at New York, USA Main ideas: Gatekeeper proxy as black box intercepting service requests to schedule them more efficiently Developed for three-tier architectures, like e- commerce web sites

19. 15 RS Approach: Admission Control Important factors: Knowledge of the system capacity Service load knowledge Admission is granted if the capacity is not exceeded, else the transaction is queued in a FIFO queue until admission can be granted

20. 16 RS Approach: Request Scheduling Schedules the SQL requests according to a pre- defined algorithm Gatekeeper uses the request scheduling policy shortest-job first (SJF) To avoid starvation an aging algorithm is implemented

21. 17 RS Approach: Example

22. 17 RS Approach: Example

23. 17 RS Approach: Example

24. 17 RS Approach: Example

25. 17 RS Approach: Example

26. 18 RS Approach: Locks Blocking the resource for other services Two different options where to lock: In the database, the DBMS controls the locking itself Controlled by the application servlet, which improves the performance for example by using Java synchronization mechanisms

27. 19 PM Approach: Introduction Developed by a research team at the Carnegie Mellon University, Pittsburgh, USA Main ideas: DBMS internal scheduling policies instead of external methods like the admission control Step 1: Detection of the bottleneck resource Step 2: Implementation of specific algorithms improving the bottleneck

28. 20 PM Approach: Bottleneck Resource I Transaction time T is split into three components: CPU I/0 Lock Monitoring of their behavior while using three different database systems: IBM DB2, Shore and PostgreSQL

29. 21 PM Approach: Bottleneck Resource II TPC-C benchmark, 10 clients per database warehouse Picture 1: IBM DB2 Picture 2: PostgreSQL differences in bottleneck resources

30. 22 PM Approach: Scheduling the Bottleneck Lock scheduling policies Non-preemptive Preemptive CPU scheduling policies All processors use generalized processor sharing (GPS) and are therefore preemptive

31. 23 Conclusion I All systems have found ways to improve the service execution for the customer Difficulties and levels of implementation differ, depending on the approach The database as bottleneck is approached differently

32. 24 Conclusion II - Comparison QoS approachRS approachPM approach used forSOA systemsMultiply-tiered web sites OLTP and transactional web applications componentexternal internal bottleneckdatabase CPU, I/O, locking content - Control in the large - Control in the small - Adaptive SLA management - Gatekeeper proxy - Bottleneck identification - Algorithm implementation

33. 25 Literature D. Gmach, S. Krompass, A. Scholz, M. Wimmer and A. Kemper: Adaptive Quality of Service Managament, ACM 2006 S. Krompass, D. Gmach, A. Scholz, S. Seltzsam and A. Kemper: Quality of Service Enabled Database Applications S. Elnikety, J. Tracey, E. Nahum, W. Zwaenepol: A Method for Transparent Admission Control and Request Scheduling in E-Commerce Web Sites D. McWherter, B. Schroeder, A. Ailamaki, M. Harchol- Balter: Priority Mechanisms for OLTP and Transactional Web Applications

34. 26 Thank you for your attention!

35. QoS Approach: Static Resource Management I Service load analysis for different resources, e.g. CPU Three steps: Preprocessing phase, Analysis phase, Classification phase

36. QoS Approach: Static Resource Management II Static allocation of services according to previously derived load patterns Implementation of a greedy heuristics Give resources to static and non scale-out capable services first because of their inflexibility Find for non scale-out capable services best-match servers Scale-out capable services are distributed following a specified, self-defined allocation strategy

37. QoS Approach: Dynamic Resource Management I Dynamic adaptations during runtime Two general approaches Queuing models, high development and maintenance costs Feedback control systems, e.g. event condition action (ECA) systems or fuzzy controller Decision in favor of the fuzzy controller, because of low administration efforts and low costs

38. QoS Approach: Dynamic Resource Management II Four main components: Monitor and advisor modules monitoring system fuzzy controller archive

39. QoS Approach: Dynamic Resource Management III

40. QoS Approach: Dynamic Resource Management IV Another method of dynamic resource management: short-term load forecasting Take statistical knowledge derived from load patterns into consideration to allocate resources

41. QoS Approach: Performance Analysis – Control in the Large 80% of CPU use as overload limit 15% more users than the system has been originally designed for Snapshots before and after implementing the control in the large significant improvement

42. QoS Approach: Performance Analysis – Control in the Small Combination of high, medium and low priority SLAs with matching penalties Snapshots before and after implementing the control in the small significant improvement

43. RS Approach: Performance Analysis Locking is done in the application server, top picture, and the database (MySQL) improvement using FIFO and SJF improvement when locking is done in the application server

44. PM Approach: Performance Analysis TPC-C benchmark, high- priority transactions Picture 1: Shore Picture 2: PostgreSQL lock scheduling more effective for Shore, CPU scheduling more effective for PostgreSQL

45. PM Approach: Performance Analysis II Preemptive lock scheduling was proven to be insufficient through experimental results Possible reasons: Overhead due to abortion of service transactions Low-priority transactions suffer because they are again queued at the end after an abortion