Elasticity Requirements Specification
SYBL is a language enabling elasticity requirements description for cloud services.
SYBL can be used by cloud providers, software providers, application developers or even end-users to describe their elasticity requirements concerning the application. The language allows for different levels of specification facilitating finer-grained elasticity specifications and enforcement depending on the actual needs of the users.
SYBL enables different levels at which users can specify elasticity requirements: application, component and programming. Application level allows for elasticity from the perspective of the whole application, while component-level and code-level elasticity requirements define user's elasticity needs for component, and respectively, sequnces of code.
Check the latest video illustrating runtime SYBL (rSYBL) with MELA!
SYBL Backus Naur Form (BNF)
Constraint := constraintName : CONSTRAINT ComplexCondition Monitoring := monitoringName : MONITORING varName=MetricFormula Strategy := strategyName : STRATEGY WHEN ComplexCondition : action(parameterList)| strategyName : STRATEGY WAIT ComplexCondition| strategyName : STRATEGY STOP| strategyName : STRATEGY RESUME
MetricFormula := metric | number | metricFormula MathOperator metric | metricFormula MathOperator number ComplexCondition := Condition | ComplexCondition BitwiseOperator Condition| (ComplexCondition BitwiseOperator Condition) Condition := metric RelationOperator number| number RelationOperator metric | Violated(name)|Fulfilled(name) MathOperator := + | - | * | / BitwiseOperator := OR | AND | XOR | NOT RelationOperator := <|>|>=|<=|==|!=
Examples of using SYBL
Cost-related elasticity requirements
- A cloud customer can specify that when the total cost is higher than 800 euro, there should be a scale-in action for keeping costs in acceptable limits.
@SYBL_ApplicationContext(strategies="St1: STRATEGY CASE total_cost>800 Euro : ScaleIn")
Quality-related elasticity requirements
- A software provider can specify constraints on the response time depending on the number of users currently accessing the provided software.
@SYBL_ComponentContext(constraints= "Co1: CONSTRAINT rt<2ms WHEN nbUsers<1000; Co2: CONSTRAINT rt<4ms WHEN nbUsers>=1000")
- A developer could specify that the result from a data analytics algorithm must reach a certain data accuracy under a cost constraint without caring how many resources should be used for executing the code of that algorithm.
@SYBL_ProgrammingContext(constraints= "Co1: CONSTRAINT dataAccuracy>90%; Co2:CONSTRAINT dataAccuracy>95% WHEN total_cost>400; Co3:CONSTRAINT total_cost<800;" priorities= "Priority(Co2)>Priority(Co1); Priority(Co3)>Priority(Co1);")
Elasticity requirements on the relation between cost and quality
- A cloud provider could specify its pricing schema or price computation policies, for example that when availability is higher than 99% the cost should increase by 10%.
@SYBL_ApplicationContext(strategies="St1: STRATEGY CASE availability>99%: IncreaseCostBy(total_cost/10)")
Multi-level Elasticity Control of Cloud Services
We consider the abstract model for cloud services described in the ICSOC Paper, and describe the cloud service following this structure using XML.
For each part of the application that needs to be controlled, we use can inject SYBL annotations within the XML, within the code or describe them as separate files through XML SYBL for describing the elasticity requirements. Cassandra DB directives state that the cpu usage should be less than 70% due to the fact that cassandra is cpu-driven, and the storage usage should be less than 50%. Cassandra Controller states that the cpu usage should be less than 85%, considering the fact that the controller is also a Cassandra seed and that it is also the one processing YCSB requests.
The SYBL Elasticity Control Runtime Engine (rSYBL) is presented in the following image.
The cloud service used for this experiment is the composed of two service topologies: a data service topology and a data processing topology. The data service topology is based on Cassandra No Sql Database, and contains in its turn a client sending requests, based on YCSB and a Cassandra topology which actually contains the Cassandra cluster.
For evaluating how topology level scale compares to component level scale, we compare the configurations from the table below, each with different number of clusters, each cluster containing a single controller (Cassandra seed). Table 1 shows different configurations, justifying the need for actions at higher level than simple component level (in this case, at cluster level).
Table 2 gives some more examples on the behavior of the Data Serving Topology, showing how 2 clusters can decrease the cost as opposed to single cluster, and more importantly it can avoid errors due to overloading (i.e. for the more intensive and longer workload, workload 2, a single cluster, eventhough it has more than one virtual machines for the slave component, reaches a point where it cannot serve requests anymore).
|Config1||1||3||Workload 1||2648s (44 min)||2.92|
|Config3||2||2||Workload 1||1704s (28.4 min)||1.88||Config1||1||3||Workload 2||>3h + errors||>12|
|Config3||2||2||Workload 2||6165s (102.75 min)||6.88|
Multi-cloud Elasticity Control
The figure below shows an example of how using rSYBL one can control a service distributed among several clouds. It may be the case that sometimes, for improving performance or for decreasing costs, the service provider chooses to deploy only some service topologies on a cloud provider, while others are kept within other premises. For instance, in the figure below, some data access and analysis processes are deployed on the Dubai cloud, where also IoT data resides. The rest of the service, in order to have better performance, is deployed on the Flexiant cloud, and accesses only data analysis information, not the entire IoT data repository.
For this case, following the configurations explained in detail on the rSYBL wiki, the rSYBL user (in this case the M2M DaaS provider) can obtain an application elastically controlled by rSYBL to follow SYBL requirements. Figure below shows a snapshot of MELA with the enforcement of a Flexiant action on the Event Processing Service Topology.As presented in the rSYBL wiki, the SYBL requirements and high level structural information is exactly the same as the information used for single-cloud. What differs is the deployment information, received from the deployment tool (e.g., SALSA, OpenTOSCA), and the effects specification which specifies the provider on which the respective actions have the described effects.
rSYBL prototype, containing local and central controllers GitHub Repository
The Decision Module in CELAR Project, GitHub Repository.
- The schema for XML-based SYBL.
- Georgiana Copil, Daniel Moldovan, Hong-Linh Truong, Schahram Dustdar, "Multi-Level Elasticity Control of Cloud Services" (Submitted PDF), the 11th International Conference on Service Oriented Computing. Berlin, Germany, 2-5 December, 2013. Check the presentation given at ICSOC.
- Georgiana Copil, Daniel Moldovan, Hong-Linh Truong, Schahram Dustdar, "Specifying, Monitoring, and Controlling Elasticity of Cloud Services", the 11th International Conference on Service Oriented Computing. Berlin, Germany, 2-5 December, 2013. Also check the demo video.
- Georgiana Copil, Daniel Moldovan, Hong-Linh Truong, Schahram Dustdar, "SYBL: an Extensible Language for Controlling Elasticity in Cloud Applications", (Submitted PDF) 13th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid), May 14-16, 2013, Delft, the Netherlands. Presentation given at CCGRID
- Schahram Dustdar, Yike Guo, Rui Han, Benjamin Satzger, Hong Linh Truong: Programming Directives for Elastic Computing. IEEE Internet Computing 16(6): 72-77 (2012)
PresentationsPresentations given are available on slideshare:
If you need any further information please contact Georgiana Copil.