An Architecture for Self-Aware and Self-Adaptive Autoscaling in
3.3 Self-Aware Patterns
When faced with the task of designing self-aware computing system, researchers and practitioners need a set of guidelines on how to use the concepts and principle of self-awareness [18]. To this end, we have documented different categories of self-self-awareness capabilities using 8 architectural patterns, which serve as the guidelines on how to design self-aware computing systems in a principled way. The aim of those patterns is to ensure that, when designing self-aware systems, only relevant types of knowledge are included, and their inclusion justified by identified benefits. To better illustrate the self-aware pattern and its origin, we briefly specify one exampled pattern in the following:
The pattern shown in Figure 3.2, is suitable for situations where goals, time and interactions between machines and processes need to be captured. Here, goal awareness enables the representation of changing runtime goals, so a node can share its knowledge with other goal-aware nodes and the system can adapt to the changed goals. Time awareness allows the representation of temporal knowledge about goal and interaction awareness, enabling capabilities such as forecasting. This pattern also adds meta-self-awareness, enabling the system to manage the trade-offs associated with exercising various self-awareness levels and thereby allowing it to modify goals at runtime. An example of this runtime meta-reasoning is the dynamic selection of the most appropriate learning algorithm for a particular context.
Please refer to Appendix A and our handbook [39] for more detailed specifications of the patterns.
Figure 3.2: The Goal Sharing with Time-Awareness Capability Pattern. There are three types of multiplicity operators (Mul Op): * expresses that the number of capability of the same type in the interaction is restricted to at least one. 1 indicates that one and only one capability of the same type is permitted. + indicates that zero, one or many of the type specified is permitted in the interaction.
3.4 Mapping Between Self-Aware Pattern and Au-toscaling Architecture
To apply self-awareness at the architecture level, it is essential to systematically map a selected self-aware pattern to the architecture components of the given problem domain, which in this thesis is autoscaling in the cloud.
Recall that in general term, the ’self’ (or node) can be any conceptual part of the system being considered, e.g., process, component or machine. The cloud autoscaling system is typically composed of numeric physical machines, each of which running services benefiting from virtualization. In this context, ’self’ is simply the autoscaling process on a physical machine. Self-awareness for an autoscaling process is to aware of the knowledge about its own (or the others’) possible impacts on the QoS models of the managed services, the granularity of control and the quality of trade-offs decision for a given runtime scenario.
Based on the knowledge acquired via self-awareness, we promote bidirectional adaptations
Region Controller
QoS Modeller
Decision Maker
Stimulus Awareness
Time Awareness
Interaction Awareness
Goal Awareness
Meta-self-Awareness
Self-expression
Components Self-awareness
Figure 3.3: The Mapping Between Autoscaling Components and The Self-awareness Ca-pabilities.
in an autoscaling process. In one direction, adaptation can be concerned with adapting the configurations for its services and virtual machines. On the other direction, adaptation can consolidate its own autoscaling capabilities. This is concerned with building more accurate QoS models, identifying better granularity of control and making better trade-offs decisions. The bidirectional adaptations, through the principles of self-awareness, aim at improving the effectiveness and self-adaptivity of autoscaling.
With that context in mind, the autoscaling architecture proposed in Section 3.2 is then systemically mapped to the self-awareness capabilities (Figure 3.3) and to a concrete instance of a carefully selected aware pattern (Figure 3.4 left). To select the self-aware pattern, we have followed the systematic mapping guideline, which is a result of our Work Package from the EPiCS project [18]. This systematic mapping guideline, which by itself is standalone contribution, has been thoroughly documented in our handbook [39]; and it has been reviewed and evaluated by different partners of the EPiCS project [18]. Additionally, the application of such mapping guideline in the context of cloud
Sensor Actuator
Figure 3.4: Enriching the Self-aware Autoscaling Architecture.
autoscaling has been illustrated as a case study in the handbook.
As we can see from Figure 3.4, the mapping process has identified Goal Sharing with Time-Awareness Capability Pattern as a suitable pattern for addressing the challenges of autoscaling. The arrows in Figure 3.4 represent either data or control flow . As we can see from the left figure, different levels of awareness require control or data flow to achieve collaborations. This has provided guidance on how to correctly incorporate self-awareness with autoscaling architecture.The autoscaling architecture is then enriched with self-awareness capabilities, shown as the deployment diagram in Figure 3.4 right.
Given that it can be hard to directly achieve self-awareness for a complex autoscaling process, we have modularised the self-awareness capabilities into different internal selves
as encapsulated by three components. Consider the autoscaling system of the cloud, which is composed of self-aware autoscaling processes on different physical machines. Here, each autoscaling process would have different internal selves: these are the processes in QoS Modeller, the Region Controller and the Decision Maker component; in this way, we hope to make these processes more intelligent using self-awareness. The autoscaling system is realised as a decentralised instances, where an instance coordinates the selves to realise self-awareness in autoscaling. The components in our autoscaling system, except QoS Modeller, are triggered when the system detects violations of the requirements, i.e., violations of SLA and utilisation constraints in case of over-provision. In particular, a requirement is said to be violated only if such violation has been observed for more than n sampling intervals, where n is a variable that controls the trade-offs between stability and adaptivity of our system. The sensors on a PM does not only sense data, but also the QoS models from other PMs. This is because a cloud-based service can, in some cases, be functionally dependent on services running on the other PMs, thus creating the chances for objective-dependency.
In the following sections, we further discuss how the self-awareness capabilities, which have been explained in Chapter 2, are mapped in the context of different internal selves.
3.4.1 Mapping Self-Awareness in QoS Modeller
The QoS modelling approach is enriched by self-awareness. At this level, ’self’ refers to the QoS modelling process in autoscaling. Self-awareness is concerned with knowing how the QoS modelling can be affected by:
• Features (e.g. workload) of QoS attributes and their changes - Stimulus-awareness.
• Possible QoS interference and contention - Interaction-awareness.
• Historical modelling errors and data trends - Time-awareness.
• Changes in utility functions of QoS - Goal-awareness.
• Suitability of learning algorithms - Meta-self-awareness.
These levels of knowledge promotes the awareness of QoS sensitivity, i.e., with respect to which, when and how cloud primitives correlate with the QoS. As the knowledge changes, the QoS modelling process can benefit from self-awareness to dynamically self-adapt the selected features and expressions of its QoS models at runtime.
By leveraging on the advances of machine learning algorithms, self-awareness not only able to better handle dynamics and uncertainty, but also eliminates the need for heavy human analysis and prior design time knowledge in the QoS modelling. However, because there is no single learning algorithm which can outperform the others constantly across a range of scenarios, selecting the right algorithm is a challenging task for developers.
Self-awareness can even address this issue by using the notion of meta-self-awareness, which performs reasoning at the meta-level, i.e., the modelling process is aware of what is the best algorithm to enable other self-awareness capabilities. In such way, self-awareness help to achieve more accurate and more effective QoS modelling.
3.4.2 Mapping Self-Awareness in Region Controller
To improve the global benefit with respect to QoS and cost objectives of all cloud-based services, we dynamically identify the right granularity of control building on self-awareness capabilities [18]. By leveraging on the QoS and cost models, self-awareness helps to adaptively cluster objectives into different regions according to objective dependency ,i.e., we put objectives in one region as long as they have common cloud primitives, which are parts of the final autoscaling decision, in their models. The regions can be different in size and this promotes dynamic granularity of control. We then consider the objectives from each regions in separated decision making processes. A self-aware and self-adaptive process is realised in the Region Controller, which maintains different regions. At this
level, ’self’ refers to the region controlling process in the autoscaling. Self-awareness here is concerned with knowing how such process can be affected by:
• QoS and cost models - Goal-awareness.
• objective dependency, i.e., conflicted or harmonic goals - Interaction-awareness.
These levels of knowledge promotes the awareness of the effects of control granularity on the global benefit. Henceforth, the region controlling process can better self-adapt its regions and their content to the dynamic changes in knowledge. As such, self-awareness improves global benefits while reducing overhead.
3.4.3 Mapping Self-Awareness in Decision Maker
Once the QoS models and regions are defined, we are faced with trade-offs when au-toscaling in the cloud. In the Decision Maker, we take a multi-objective representation to model the trade-offs of QoS and cost objectives for different cloud-based services, and the problem is resolved by a self-aware and self-adaptive process. At this level, ’self’ refers to the decision making process in the autoscaling. Self-awareness here is concerned with knowing how the decision making can be affected by :
• QoS and cost models, as well as their requirements - Goal-awareness.
• regions of objectives, which represent the positive, negative or zero interaction be-tween objectives during decision making - Interaction-awareness.
Obtaining these levels of knowledge mean that the decision making process is capable to adapts its behaviour in the search for better trade-offs decisions. Specifically, self-awareness assists the decision making process in extensively reasoning about the effects of autoscaling decisions on goals and the possible trade-offs. By leveraging on modern search based algorithms, the reasoning serves as a strong assurance about the quality of
autoscaling, especially when the search space is incredibly large (i.e., too many combi-nations of software configurations and hardware resource provisions), which cannot be handled by human decision maker. More importantly, the knowledge acquired from self-awareness helps the process to self-adapt its own search behaviour for better optimality and diversity, e.g., exploring more on the decisions that contain high CPU allocations and more beneficial for certain goals. This permits the Decision Maker to handle com-plex trade-offs even without prior preferences, i.e., achieving well-compromised trade-offs, which largely improving majority of the goals while causing relatively small degradations on others. Given that the regions are dependent to each others, we only make decisions for the regions containing the objectives whose requirement violations have been detected.
process is needed.
3.5 Conclusion
As cloud computing continuous to evolve, autoscaling requires novel principles and ap-proaches to seamlessly manage the underlying cloud-based services. Self-awareness pro-vides highly promising avenue for improving self-adaptivity and the effectiveness of au-toscaling in the cloud. In this chapter, we describe the auau-toscaling architecture and its mapping to self-awareness capabilities and the related pattern. We focus on discussing how the principle of self-awareness can be beneficial for various logical aspects in autoscal-ing, including QoS modellautoscal-ing, identifying granularity of control and making trade-offs decisions. In Chapter 4, 5, 6 and 7 we will experimentally evaluate each of these logical aspects in details.
In the next chapter, we will explore the first internal self, namely QoS Modeller, in the self-aware autoscaling architecture. Specifically, in such internal self, we propose a self-aware and self-adaptive QoS modelling approach, which is capable to dynamically correlate QoS attributes to various cloud primitives on-the-fly.