Fuzzy Control meets Software Engineering
2 likes1,034 views
The document discusses the intersection of fuzzy control and software engineering, particularly focusing on auto-scaling and self-adaptive systems to reduce wasted capacity and manage demand effectively. It highlights the complexities associated with user input for scaling actions, the challenges of enactment latency across different cloud platforms, and the need for robust decision-making strategies using fuzzy logic. The insights provided indicate future directions for improving runtime assistance and managing multi-cloud environments.
Fuzzy Control meets Software Engineering
- 1. Fuzzy Control meets Software Engineering Pooyan Jamshidi IC4-Irish Centre for Cloud Computing and Commerce School of Computing,Dublin City University [email protected] DagstuhlSeminar Control Theory meets Software Engineering September, 2014
- 2. Naeem Esfahani and Sam Malek, “Uncertainty in Self-Adaptive Software Systems” Knowledge Specification Uncertainty 2
- 3. 3
- 5. ~50% = wasted hardwareActual trafficTypical weekly traffic to Web-based applications (e.g., Amazon.com) 5
- 6. Problem 1: ~75% wasted capacityActual demandProblem 2: customer lostTraffic in an unexpected burst in requests (e.g. end of year traffic to Amazon.com) 6
- 7. Really like this?? Auto-scaling enables you to realize this ideal on-demand provisioning Time Demand ? Enacting change in the Cloud resources are notreal-time 7
- 8. Capacity we can provision with Auto-ScalingA realistic figure of dynamic provisioning 8
- 9. 9
- 10. 0 50 100 0 500 1000 1500 0 50 100 100 200 300 400 500 0 50 100 0 1000 2000 0 50 100 0 200 400 600 10
- 11. 11
- 12. These quantitative values are required to be determined by the user requires deep knowledge of application (CPU, memory, thresholds) requires performance modeling expertise (when and how to scale) A unified opinion of user(s) is required Amazon auto scaling Microsoft Azure Watch 12 Microsoft Azure Auto- scaling Application Block 12
- 13. 13
- 14. Uncertainty related to enactment latency: The same scaling action (adding/removing a VM with precisely the same size) took different time to be enacted on the cloud platform (here is Microsoft Azure) at different points and this difference were significant (up to couple of minutes). The enactment latency would be also different on different cloud platforms. 14
- 15. Offline benchmarking Trial-and-error Expert knowledge Costly and not systematic A. Gandhi, P. Dube, A. Karve, A. Kochut, L. Zhang, Adaptive, “Model-driven Autoscalingfor Cloud Applications”, ICAC’14 arrival rate (req/s) 95% Resp. time (ms) 400 ms 60 req/s 15
- 16. RobusT2Scale Initial setting + elasticity rules + response-time SLA environment monitoring application monitoring scaling actions Fuzzy Reasoning Users Prediction/ Smoothing 16
- 17. 0 0.5 1 1.5 2 2.5 3 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Region of definite satisfaction Region of definite Region of dissatisfaction uncertain satisfaction Performance Index Possibility Performance Index Possibility words can mean different things to different people Different users often recommend different elasticity policies 0 0.5 1 1.5 2 2.5 3 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Type-2 MF Type-1 MF 17
- 18. 18
- 19. Workload Response time 0 10 20 30 40 50 60 70 80 90 100 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 x 2 Membershuip grade 0 10 20 30 40 50 60 70 80 90 100 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Membersuhip grade => => mean sd 19
- 20. Rule (풍) Antecedents Consequent 풄풂풗품 풍 Workload Response-time Normal (-2) Effort (-1) Medium Effort (0) High Effort (+1) Maximum Effort (+2) 1 Very low Instantaneous 7 2 1 0 0 -1.6 2 Very low Fast 5 4 1 0 0 -1.4 3 Very low Medium 0 2 6 2 0 0 4 Very low Slow 0 0 4 6 0 0.6 5 Very low Very slow 0 0 0 6 4 1.4 6 Low Instantaneous 5 3 2 0 0 -1.3 7 Low Fast 2 7 1 0 0 -1.1 8 Low Medium 0 1 5 3 1 0.4 9 Low Slow 0 0 1 8 1 1 10 Low Very slow 0 0 0 4 6 1.6 11 Medium Instantaneous 6 4 0 0 0 -1.6 12 Medium Fast 2 5 3 0 0 -0.9 13 Medium Medium 0 0 5 4 1 0.6 14 Medium Slow 0 0 1 7 2 1.1 15 Medium Very slow 0 0 1 3 6 1.5 16 High Instantaneous 8 2 0 0 0 -1.8 17 High Fast 4 6 0 0 0 -1.4 18 High Medium 0 1 5 3 1 0.4 19 High Slow 0 0 1 7 2 1.1 20 High Very slow 0 0 0 6 4 1.4 21 Very high Instantaneous 9 1 0 0 0 -1.9 22 Very high Fast 3 6 1 0 0 -1.2 23 Very high Medium 0 1 4 4 1 0.5 24 Very high Slow 0 0 1 8 1 1 25 Very high Very slow 0 0 0 4 6 1.6 Rule (퐥) Antecedents Consequent 풄풂풗품 Work 풍 load Response -time -2 -1 0 +1 +2 12 Medium Fast 2 5 3 0 0 -0.9 10 experts’ responses 푅푙 : IF (the workload (푥1) is 퐹 푖1, AND the response-time (푥2) is 퐺 푖2), THEN (add/remove 푐푎푣푔 푙 instances). 푐푎푣푔 푙 = 푢=1 푁푙 푤푢푙 × 퐶 푢=1 푁푙 푤푢푙 Goal: pre-computations of costly calculations to make a runtime efficient elasticity reasoning based on fuzzy inference 20
- 21. Liang, Q., Mendel, J. M. (2000). Interval type-2 fuzzy logic systems: theory and design. Fuzzy Systems, IEEE Transactions on, 8(5), 535-550. Scaling Actions Monitoring Data 21
- 22. 0 10 20 30 40 50 60 70 80 90 100 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.5954 0.3797 푀 0 10 20 30 40 50 60 70 80 90 100 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.2212 0.0000 0 10 20 30 40 50 60 70 80 90 100 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 x 2 u 0 10 20 30 40 50 60 70 80 90 100 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 x 2 u Monitoring data Workload Response time 22
- 24. 24
- 25. 푦푙 , 푦푟 25
- 26. 26
- 27. 050100050010001500050100100200300400500 0501000100020000501000200400600 0501000500100005010005001000 27
- 28. 28
- 29. 0 10 20 30 40 50 60 70 80 90 100 -500 0 500 1000 1500 2000 Time (seconds) Number of hits Original data betta=0.10, gamma=0.94, rmse=308.1565, rrse=0.79703 betta=0.27, gamma=0.94, rmse=209.7852, rrse=0.54504 betta=0.80, gamma=0.94, rmse=272.6285, rrse=0.70858 0 0.2 0.4 0.6 0.8 1 1.2 1.4 Big spike Dual phase Large variations Quickly varying Slowly varying Steep tri phase 0 50 100 0 500 1000 1500 0 50 100 100 200 300 400 500 0 50 100 0 1000 2000 0 50 100 0 200 400 600 0 50 100 0 500 1000 0 50 100 0 500 1000 Root Relative Squared Error 29
- 30. SUT Criteria Big spike Dual phase Large variations Quickly varying Slowly varying Steep tri phase RobusT2Scale 푟푡95% 973ms 537ms 509ms 451ms 423ms 498ms 푣푚 3.2 3.8 5.1 5.3 3.7 3.9 Overprovisioning 푟푡95% 354ms 411ms 395ms 446ms 371ms 491ms 푣푚 6 6 6 6 6 6 Under provisioning 푟푡95% 1465ms 1832ms 1789ms 1594ms 1898ms 2194ms 푣푚 2 2 2 2 2 2 SLA: 풓풕ퟗퟓ≤ퟔퟎퟎ풎풔 For every 10s control interval•RobusT2Scale is superior to under-provisioning in terms of guaranteeing the SLA and does not require excessive resources•RobusT2Scale is superior to over-provisioning in terms of guaranteeing required resources while guaranteeing the SLA 30
- 31. 0 0.02 0.04 0.06 0.08 0.1 alpha=0.1 alpha=0.5 alpha=0.9 alpha=1.0 Root Mean Square Error Noise level: 10% 31
- 32. Application #2: Self-Adaptive Software Connectors
- 33. ⊭푅 Environment=D Environment=D’ Environment=D’ ⊨푅 ⊨푅 Adapted to satisfy requirements while it is running Reliable RuntimeEfficient 33
- 34. 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 1.5 2 2.5 3 3.5 4 output1 34
- 35. 35
- 36. 0 1 2 3 4 5 x 10 -3 1 2 3 4 5 6 7 8 0 0.05 0.1 0.15 0.2 0.25 1 2 3 4 5 36
- 37. 0.05 0.1 0.15 0.2 0.25 0.3 0.35 Type-1 FLS Type-2 FLS RMSE • The rule reduction reduced the rules quite considerably. • IT2 FLCs are more robust due to less mean error and less variation in the estimation error. • T1 FLCs in some realization drop more rules in comparison with the IT2 FLCs. • IT2 FLC original designs can be designed with less rules. 37
- 38. 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 0 0.2 0.4 0.6 0.8 1 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% Noise Amplitude (α=0.5) RMSE α=0.7 α=0.95 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% IT2 FLC T1 FLC 38
- 40. Current Solution (my PhD Thesis + IC4 work on auto-scaling) Future Plan Updating K in MAPE-K Design-time @ Runtime Assistance Multi-cloud
- 41. 41
- 42. 42
- 43. Challenge 1: ~75% wasted capacity Actual demand Challenge 2: customer lost ⊭ 푅 Environment=D Environment=D’ Environment=D’ ⊨ 푅 ⊨ 푅 Adapted to satisfy requirements while it is running Reliable Run-time Efficient Current Solution (my PhD Thesis + IC4 work on auto-scaling) Future Plan Updating K in MAPE-K Design-time @ Runtime Assistance Multi-cloud RobusT2Scale Initial setting + elasticity rules + response-time SLA environment monitoring application monitoring scaling actions Fuzzy Reasoning Users Prediction/ Smoothing 43
- 44. http://computing.dcu.ie/~pjamshidi/PDF/SEAMS2014.pdf More Details? => http://www.slideshare.net/pooyanjamshidi/ Slides? => 44 Thank you! => Aakash Ahmad Claus Pahl SoodehFarokhi
- 46. Requirement: R 0 50 100 0 500 1000 1500 0 50 100 100 200 300 400 500 0 50 100 0 1000 2000 0 50 100 0 200 400 600 0 50 100 0 500 1000 0 50 100 0 500 1000 Environment: D Model: S Implementation Monitoring Execution Runtime Design-time Reasoning Self-adaptation Specification S,D⊨R S,D⊭R 46
- 47. Looking for references? http://computing.dcu.ie/~pjamshidi/PDF/SEAMS2014.pdf 47
- 48. 48
- 49. 49
- 50. 50
- 51. 푦푟 − 푦푙 51
- 52. 52