On the Elasticity of Social Compute Units
This page provides supplementary material for the paper:
We have witnessed emerging collective adaptive systems which are formed from heterogeneous types of computing units to solve complex problems. The recently introduced Social Compute Units (SCU), present one type of these systems, which have human-based services as their core fundamental compute units. While there is related work on forming SCUs and optimizing their performance with adaptation techniques, most work is focused on static structures of SCUs. To provide better performance and more flexibility at runtime, in this work we investigate the need for elasticity, we model and provide elastic operations for Social Compute Units, with which e.g, external nodes can be included on demand and performance and quality parameters can fluctuate to best fit the customer demands at runtime, of course within the customer-set constraints.
What makes an SCU elastic is its characteristics of being scalable in ICU number, type and their properties(e.g.,price), capabilities(e.g.,skill) and performance(e.g., timeliness,quality). For this, the important part within the SCU life-cycle is the execution part. In this sense, investigating mechanisms for monitoring and flexible runtime adaptation is crucial. Thus, our focus is modeling the execution stage of SCUs and techniques for provisioning SCUs with elastic capabilities, considering performance metrics. Our attention is not on initial SCU formation, but giving already formed SCUs the possibility to be elastic, by extending/reducing in size and modifying capabilities in response to events such as overloaded ICUs(resources), time-threshold violations, budget limitations, lessened performance and ICU misbehaviors.
An Example Algorithm
Elasticity based on the use of willingness req/ack messages during unexpected task generation
The ICU feedback based algorithm that we presented in the paper is one example of providing an SCU elastic scalability technique, which is based on ICU based availability guarantees. It came as a result of investigating questions such as: How to give ICUs more flexibility in chosing tasks and include them in SCU adaptation decision-making, with the aim of getting a certain level of guarantee and higher reliability in task execution? Which task needs to be reassigned, when and to whom? Do we need to add and/or remove workers/s in the SCU. If yes, whom and how many?
The algorithm presented in the paper is illustrated with the following diagram:
We set up a Java based experiment built on top of the GridSim(http://www.buyya.com/gridsim/) simulator, so as to make a more realistic scenario where we consider that ICUs utilize a certain network infrastructure to conduct their tasks. We modeled tasks with single cost and skill requirements (for simplicity) using a few different types of skills (e.g., design, development, database-management, tester). We modeled ICUs with having single skills as well from the same set that we used for the task skill requirements, and also assigned them random values for their price. Tasks were then initially assigned to ICUS based on matching skill and price requirements. New tasks were generated at runtime randomly, and instead of a time threshold for tasks as basis for reassignment we randomly set ICUs to an idle state to indicate failure, and reassigned tasks as in the algorithm presented in the paper. From the dateof our simulation we noticed that SCU productivity raises with the number of ICUs and the same effort for tasks, while it declines if the effort is high for a low number of tasks and a low number of ICUs (see graphs bellow).
We are developing the API further and work on utilizing it to build a runtime elasticity management engine where human-based parameters can be configured to be fetched from an external database, so as to enable analysis with real data. We aim to enable different types of strategies so that depending on the event, different elasticity-focused algorithms can be utilized at runtime to optimize performance complying to the constraints.
Discussion on further metrics and elasticity implications
Trust plays an important role when making resource selection decisions. In the modeling of the SCU execution mode, we consider a trust model which is a level higher of a social trust model, and includes in it a social trust metric as one of its components. Thus, we utilize a basic model of trust,which is the trust that the system has on the future behavior of a specific ICU. More specifically, this is a score that a system supporting ICUs and their collaborations caluclates as an aggreagate performance indicator for an SCU based on logs. Thus, our notion of trust is one that the system has about an ICU for which it has performance related information. The freedom of choosing to work on additional tasks that our example algorithm provides to ICUs, depends largely on trust. If tasks are scheduled using reassignments then monitoring of resources gives knowledge about their performance considering the “reassigned tasks” as well. Hence, we include this knowledge and the one about resource willingness in our model of trust computation. Thus, we model the global trust of an ICU along four dimensions: success rate (SR), timeliness(T), quality (Q), social trust (ST) and add the willingness confidentiality value - CW as another dimension or metric in trust calculation, then the total trust of an ICU is calculated as: Trust_r=w(SR)* SR + w(T)*T+ w(Q)*Q + w(ST)*ST +w(CW)*CW. Thus our model of trust includes also the identification of those ICUs, that are more interactive and responsive to the system by checking and acknowledging notifications for task executions. We plan to extend and detail this model more as our future work. The discussed model is used in our preliminary experiments. For example in our experiments we assign social trust score for ICUs randomly (and also we use only one element for quality and success rate. However, in a real setup it can be calculated in different ways, one of which is that, ICUs are aksed to rate other SCU members and rates for specific ICUS are aggregated. There are many social trust and reputation models and we plan to investigate this topic in relation to elasticity in our upcoming work.
Elasticity influencing parameters
As the discussion in the paper implies, the basic parameters that influence SCU elasticity are customer/user requirements and ICU properties (see figure below). Thus, SCU elasticity is a function of: the total available budget, the deadline of the end-task, the number of unexpected tasks generated, the total number of tasks in the task queue of a worker (belonging to the SCU in consideration or not), workers skill and performance profile, and on the willingness of human resources. We are working on extending and detailing this list.
If you need any further information please contact Mirela Riveni.