Re: Workload and Resource Aware, Proactive Autoscaling with Apache Stratos

[Tharindu Munasinghe <th...@cse.mrt.ac.lk>]

Hi all,

Here I am presenting the initial component architecture of the suggested
autoscaler. This design was based on the high level understanding of the
existing Stratos architecture. Following diagram shows how the 3 major
components in our suggested system will connect with the existing
components:

​
*Components colored in Yellow would be the suggesting components in our
design.*


*Work Load predictor ( Predictive Manager)*

Our main goal would be to improve the autoscaler with an internal workload
predictor capable of working with a pluggable set of prediction algorithms
(e.g. time series analysis, machine learning techniques), which can be made
to dominate over the existing policy-based decision maker via user
configurations. With this component, future value of a given metric (CPU,
memory usage, request count) will be forecast in advance. Since some
prediction algorithms might not perform well with some workload patterns,
we decided to implement several algorithms that will be executed
concurrently, and dynamically choose the algorithm with the minimum error


*Resource Optimizer*

Forecast values will be fed into a resource optimizer module which would
compute the optimal (or  sub-optimal) action for handling the suggested
workload. Since different IaaS providers provide different types of VM
pools and different pricing models, this component will analyse the current
workload requirement and identify the more cost effective VM type (CPU
intensive, memory intensive, etc) to spin up an instance. Basically this
component tries to take more cost effective actions in the scaling process.



*Persistence Engine *
As our autoscaler would need to access historical data for executing
workload prediction algorithms such as time series analysis, it would
require a metrics persistence engine as an external dependency.Currently
the persistence engine feature is not available in Stratos 4.1.0 but there
is an ongoing project for that. It would be subscribed to the topology and
health metrics topics, and would hence receive and persist all
corresponding updates received via the message broker during run time. The
persistence engine would be queried by both the workload predictor of the
autoscaler and by the visualization module (described below).



*Visualization Manger*
This is the back end component for visualization tasks. Basically we
thought that this component can process (clean, summarize and identify the
patterns in) both real time and offline data. As far as we understood, this
is not a concern of an autoscaler, so we decided to place it outside the
autoscaler. For historical data, the module will query the persistence
engine, whereas for real-time metrics it would subscribe under the message
broker. In either case, data summarization and other visualization-related
processing steps would take place inside the module, and the output data
will be available either to the web UI directly managed by the Stratos
manager, or to external parties via its REST API. For workload or resource
prediction visualization scenarios, the visualization module will directly
query the autoscaler with relevant data, which would then process the data
and return either the workload prediction or the resource topology
directly, without publishing them to the cloud controller.

Visualization scenarios:

   - Actual resource usage against resource allocation
   - Predicted workloads under different techniques vs actual workload
   - Real-time resource usage curves in VMs
   - Monthly cost predictions



Overall approach is to minimize the changes to existing architecture. So we
basically tried to place our components inside the existing components
based on the separation of concerns among the existing components.However
If we can place our work as separate components, we would have bit more
flexibility and a loosely-coupled system.

Highly appreciate your feedback and suggestions on this .

Thanks!
Best Regards

On 28 May 2015 at 00:00, Supun Bhathiya <bh...@cse.mrt.ac.lk> wrote:

> Hi Lakmal, Amitabha, devs,
>
> @Amitabha
> Great to hear your interest!
>
> We are currently working on a more detailed documenting of our plan with
> architectural diagrams. Looking forward to share them and discuss it soon.
>
> Thanks
> -Bhathiya
>
>
> On 27 May 2015 at 09:47, Amitabha Karmakar <am...@gmail.com> wrote:
>
>> Hi Team,
>>
>>  Please count me in, I would love to be hands on, on the effort. Here's
>> my linkedin profile:
>>
>> https://www.linkedin.com/profile/view?id=26872767&trk=hp-identity-photo
>>
>> Thanks,
>> Amitabha Karmakar.
>>
>> On Wed, May 27, 2015 at 12:09 AM, Lakmal Warusawithana <la...@wso2.com>
>> wrote:
>>
>>> Hi Bhathiya and all,
>>>
>>> Your proposal will definitely add value to Stratos. I strongly
>>> recommending keep working with the community after you folks are started
>>> working on design and implementation phases.
>>>
>>> Good luck! and looking forward to working with you folks.
>>>
>>> thanks
>>>
>>> On Tue, May 26, 2015 at 11:52 PM, Supun Bhathiya <
>>> bhathiya.11@cse.mrt.ac.lk> wrote:
>>>
>>>> Hi Imesh,
>>>>
>>>> Here [1]  is our final year project proposal. We would share the
>>>> design diagrams soon.
>>>>
>>>> [1] -
>>>> https://docs.google.com/document/d/1q_S7pv6UWUAAM0isWZdlt-c953SImmg2Dfev4g5WzJc/edit
>>>>
>>>> Thanks
>>>> -Bhathiya
>>>>
>>>> On 26 May 2015 at 23:42, Supun Bhathiya <bh...@cse.mrt.ac.lk>
>>>> wrote:
>>>>
>>>>> Hi Imesh,
>>>>>
>>>>> Here[1]  is our proposal. We would share the design diagrams of our
>>>>> project soon.
>>>>>
>>>>> On 26 May 2015 at 23:38, Supun Bhathiya <bh...@cse.mrt.ac.lk>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> cc'ing to Dr. Dilum Bandara and  Dr. Srinath Perera who would act as
>>>>>> internal and external mentors for our project respectively.
>>>>>>
>>>>>>
>>>>>> On 26 May 2015 at 23:23, Supun Bhathiya <bh...@cse.mrt.ac.lk>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 26 May 2015 at 09:35, Imesh Gunaratne <im...@apache.org> wrote:
>>>>>>>
>>>>>>>> Hi Bhathiya,
>>>>>>>>
>>>>>>>> It's good to see your proposal on improving current Autoscaling
>>>>>>>> functionality. This would definitely add value to Stratos. We could plan
>>>>>>>> and deliver this functionality in a future version.
>>>>>>>>
>>>>>>>> It would be great if you could prepare a implementation design for
>>>>>>>> your project proposal and discuss it in detail.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> On Mon, May 25, 2015 at 10:35 PM, Supun Bhathiya <
>>>>>>>> bhathiya.11@cse.mrt.ac.lk> wrote:
>>>>>>>>
>>>>>>>>> Hi Imesh,Lakmal, Lahiru, Devs,
>>>>>>>>>
>>>>>>>>> This is intended to formalize the discussion we had on $subject,
>>>>>>>>> on behalf of our final year project, " *Workload and Resource
>>>>>>>>> Aware, Proactive Auto-scaling for PaaS Sytems* ".
>>>>>>>>>
>>>>>>>>> Our project is aimed at adding the following features and
>>>>>>>>> improvements to Apache Stratos.
>>>>>>>>>
>>>>>>>>> 1 - Improved  Workload Prediction
>>>>>>>>>
>>>>>>>>> Currently Stratos autoscaler predict *immediate future load*
>>>>>>>>> based on current (in memory) health statistic.
>>>>>>>>>
>>>>>>>>> We propose to improve the auto-scaling  mechanism to *predict
>>>>>>>>> workload for larger period of time by persisting and analyzing past
>>>>>>>>> statistics.*
>>>>>>>>>
>>>>>>>>> 2 - Smart resource allocation and deallocation
>>>>>>>>>
>>>>>>>>> Currently Stratos is not fully aware of all the resources provided
>>>>>>>>> by various IaaS and its pricing models. Therefore when scaling up, Stratos
>>>>>>>>> always spin-up an instance of same type. On the other hand kill a randomly
>>>>>>>>> selected instance when scaling down.
>>>>>>>>>
>>>>>>>>> We propose to improve this mechanism by selecting resources based
>>>>>>>>> on application workload patterns, available resource types and pricing of
>>>>>>>>> resources. For example allocating memory optimized instance would be cost
>>>>>>>>> effective for some application while some other application require high
>>>>>>>>> CPU but less memory. Also scale down mechanism can be improved by
>>>>>>>>> introducing  features like "smart killing".
>>>>>>>>>
>>>>>>>>> 3 - Visualizing
>>>>>>>>>
>>>>>>>>> We propose to implement graph base view of
>>>>>>>>>
>>>>>>>>>    -  Predicted vs actual workloads
>>>>>>>>>    -  Optimized vs normal resource usage
>>>>>>>>>    -  Cost prediction
>>>>>>>>>
>>>>>>>>> We are glad to share our preliminary design concerns with the
>>>>>>>>> community and value your feedback and suggestions on our attempt.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> -Bhathiya
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Imesh Gunaratne
>>>>>>>>
>>>>>>>> Senior Technical Lead, WSO2
>>>>>>>> Committer & PMC Member, Apache Stratos
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Vice President, Apache Stratos
>>> Director - Cloud Architecture; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>


-- 
*Th**a**rindu Munasin**ghe.*
*Undergraduate ,Department of Computer **S**cience and Engineering*
*University of Moratuwa.*
*Contact no. +94770460887*