Evaluating Caching Strategies for Cloud Data Access using an Enterprise Service Bus
•Download as PPTX, PDF•
2 likes•322 views
Nowadays different Cloud services enable enterprises to migrate applications to the Cloud. An application can be partially migrated by replacing some of its components with Cloud services, or by migrating one or multiple of its layers to the Cloud. As a result, accessing application data stored off-premise requires mechanisms to mitigate the negative impact on Quality of Service (QoS), e.g. due to network latency. In this work, we propose and realize an approach for transparently accessing data migrated to the Cloud using a multi-tenant open source Enterprise Service Bus (ESB) as the basis. Furthermore, we enhance the ESB with QoS awareness by integrating it with an open source caching solution. For evaluation purposes we generate a representative application workload using data from the TPC-H benchmark. Based on this workload, we then evaluate the optimal caching strategy among multiple eviction algorithms when accessing relational databases located at different Cloud providers.
Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Similar to Evaluating Caching Strategies for Cloud Data Access using an Enterprise Service Bus
Similar to Evaluating Caching Strategies for Cloud Data Access using an Enterprise Service Bus (20)
Recently uploaded
Recently uploaded (20)
Evaluating Caching Strategies for Cloud Data Access using an Enterprise Service Bus
- 1. University of Stuttgart Universitätsstr. 38 70569 Stuttgart Germany Phone +49-711-685 88337 Fax +49-711-685 88472 Research Santiago Gómez Sáez, Vasilios Andrikopoulos, Frank Leymann, and Steve Strauch Institute of Architecture of Application Systems {gomez-saez, andrikopoulos, leymann, strauch}@iaas.uni-stuttgart.de Evaluating Caching Strategies for Cloud Data Access using an Enterprise Service Bus IEEE IC2E 2014
- 2. Research © Santiago Gómez Sáez 2 Agenda Motivating Scenario CDASMix Architecture & Realization Evaluation Conclusion and Future Work
- 3. 33 Research © Santiago Gómez Sáez Motivating Scenario Presentation Layer Application Business Layer SQL Data Access Layer SQL Data Access LayerCloud-Enabled Data Access Layer SQL Registry Public Cloud Public CloudTraditional Application Layers Deployment Models Assumptions Database layer has already been migrated Focus on Relational Databases
- 4. 44 Research © Santiago Gómez Sáez CDASMix - Architecture Presentation Business Logic Resources Web Service API Configuration Registry Manager Tenant Registry Manager Service Registry Manager JBI Container Manager Service Assembly Manager Service Registry Database Cluster Configuration Registry Database JBI Container Instance Cluster Access Layer Web UI Tenant Registry Database Message Broker (1) Strauch et al.: Transparent Access to Relational Databases in the Cloud Using a Multi-tenant ESB. CLOSER’14 (2) ESBMT Project: www.iaas.uni-stuttgart.de/esbmt/
- 5. 55 Research © Santiago Gómez Sáez CDASMix – Cloud Data Access ESB Instance OSGi Environment JBI Environment Standardized Interfaces for Service Engines Standardized Interfaces for Binding Components Normalized Message Router External Application SMX-Camel -mt MySQL Proxy SMX- Camel Camel cdasmixJDBC Backend Cloud Data Store Provider Legend Message Flow OSGi Component JBI Component NMR API Cache Cluster Instance 1Instance 1Instance 1 • Ehcache 2.6.0 • LRU, LFU & FIFO • Multi-tenancy Awareness
- 6. 66 Research © Santiago Gómez Sáez Evaluation – Methodology & Data Set Measure how caching mitigates the performance degradation when accessing data through CDASMix Analyze the optimal cache eviction algorithm (in tandem with the MySQL instances) Cache Hit rate in % and throughput in Req./s TPC-H 1 GB data distributed in 8 tables Discrete uniform (1/N) generated workload from 5 adapted TPC- H queries -> read intensive (2.5 MB per query) constituted by 100 queries from initial sample of 9 queries Generated Load publicly available at https://santiago.studiforge.informatik.uni- stuttgart.de/svn/publications/IC2E14/queries4Load/generatedLoad 5-100.csv
- 7. 77 Research © Santiago Gómez Sáez Evaluation Setup VM0 (Flexiscale) Apache JMeter 2.9 CDASMix MySQL 5.1 TPC-H Amazon RDS MySQL 5.1 instance VM1 (Amazon EC2) MySQL 5.1 D1D2 D3 E3 E2 E1 Legend Message Flow Measurement Point Throughput and Transfer Rate Built-in Cache E TPC-H TPC-H QueryGen.shload.csv MySQL & Ehcache cache size 16MB
- 8. 88 Research © Santiago Gómez Sáez Evaluation – MySQL in IaaS Flexiscale & AWS EC2 Flexiscale AWS EC2 -51% -14% -10% +17% -39% +21% +30% +16%
- 9. 99 Research © Santiago Gómez Sáez Evaluation – MySQL in IaaS Flexiscale & AWS EC2 Flexiscale AWS EC2 -51% +43% +46% +42% -39% +50% +53% +48%
- 10. 1010 Research © Santiago Gómez Sáez Evaluation – MySQL in AWS RDS -93% -89% -89% -89%
- 11. 1111 Research © Santiago Gómez Sáez Evaluation – MySQL in AWS RDS -93% +37% +37% +37%
- 12. 1212 Research © Santiago Gómez Sáez Evaluation – CDASMix Cache Hit Ratio Flexiscale AWS EC2 AWS RDS
- 13. 1313 Research © Santiago Gómez Sáez Conclusion & Future Work Design and realization of CDASMix, a multi-tenant aware ESB solution that enables transparent data access Caching support for ameliorating the performance Evaluation based on different database deployment scenarios the utilization of different caching eviction algorithms Extend CDASMix towards supporting PostgreSQL CDASMix horizontal scalability & distributed caching Further evaluation + Caching Eviction Algorithms Different workloads
- 14. 14 Thanks for your attention!!
Editor's Notes
- 1- In the last years Cloud computing has become popular among IT organizations aiming to reduce its operational costs 2- Applications can be designed to run in the Cloud, or can be partially or completely migrated to the Cloud. 3- Focusing on the three layered application pattern, in other works we have focused on migrating the application data to the Cloud. Migrating the application data to the Cloud requires adaptations, e.g. rewiring to access the migrated to the Cloud databases. 4- In this work we target how to mitigate the performance degradation due to accessing the migrated to the Cloud data through CDASMix
- Contributions of this work: The design and realization of CDASMix, a multi-tenant aware ESB solution with caching support that enables transparent data access to databases both on-premise and off-premise.Design and realization of CDASMix, a multi-tenant aware ESB solution that enables transparent access to databases hosted on or off-premise A performance evaluation of our proposal, with the dual purpose of showing the impact of introducing CDASMix to the performance of the application, and identifying the optimal caching strategy for CDASMix for different deployment options across Cloud service providers. A set of initial findings stemming from this evaluation, that can be valuable for related efforts
- 1- Focus on the three layered application pattern proposed by Fowler 2- Data layer is subdivided into the data access layer and the database layer 3.1- Consider an application whose stack is completely hosted on-premise. 3.2- Data is partially or completely migrated to the Cloud, e.g. to Amazon RDS 3.3- The data Access layer must be adapted and rewired in order to access the migrated to the Cloud database 3.4- If we assume 3 different scenarios, e.g. data partially hosted between on-premise, and DBaaS or IaaS solutions, the data access layer must be aware of such locations towards retrieving the data from the different backend data sources. 3.5- Therefore, there is a need of a Cloud enabled data access layer able to redirect the data storage and retrieval requests to the different databases. 3.6- For example, being able to redirect SQL requests to data migrated to AWS RDS.
- Presentation layer: Extended to provide a larger amount of operations not only for multi-tenant aware administration and management, but also to enable the registration of the necessary information for routing requests between multiple backend data sources. Business Logic Layer: encapsulates the business logic of the ESBmt administration and management. Have extended to incorporate cloud data access awareness. Access layer: based on role based access control. Tenant and users access the system with an unique tenant id and user id. Tenant Registry Manager, Configuration Registry Manager, and Service Registry Manager: wrap the interaction functionalities with the persistent resources, tenant registry, configuration registry, and service registry. JBI Container Manager and Service Assembly Managers contain the necessary functionalities to interact with the JBI Container Cluster for deployment and undeployment of message adapters and transformers. Resources Layer: encapsulates the persistancy resources, and the resources which are managed and administered through the upper layers. ESB Instance Cluster: multiple ESB instaces which perform the tasks associated with ESB solutions, e.g. message routing and transformation. Each ESB instances can be seen as three main components: Message adapters, message processors, and a normalized message router. Tenant Registry: contains information related to the tenants and users, e.g. id, email, etc. Configuration Registry: contains information related to the configuration of each tenant, e.g. tenant operator permissions, used jbi clusters, quota for message adapters, etc. Service Registry: tenant’s services in the ESB cluster, as well as the configuration of each message adapter deployed to the ESB instance. Message broker is an intermediate component for communicating with the ESB instances based on topic subscription.
- - MySQL Proxy: OSGi and JBI compliant version of Java MySQL Proxy implementing native MySQL communication protocol, providing one endpoint - Caching: EhCache realizing Least Recently Used (LRU) caching policy and deleting cach records when SQL statements involve data modifications - NMR: enables integration of OSGi Proxy and NMR - SMX-Camel-mt: multi-tenancy, integration between JBI and Enterprise Integration Patterns provided by Apache Camel CamelcdasmixJDBC: dynamically connecting to backend data stores via corresponding database communication protocol JNDI: to register database connections in order to reduce latency when creating a database connection per user SMX-Camel: enables loading CamelcedasmixJDBC packages at runtime, e.g. updates for supporting a new backend data store or data service
- MySQL query cache uses the an improved LRU eviction algorithm incorporating a midpoint insertion strategy. Following a temporal storage based on lists, the list is divided into the most recently accessed and the oldest values which are less recently used. With this approach, the list contains blocks which are the most recently used. TPC-H benchmark is a database decision support benchmar which comprises a set of queries with a high degree of complexity that run over a large volume of data. 9 Adapted queries which are distributed among a workload constituted by 100 queries distributed with probability 1/9 Average of 10 Rounds per scenario
- RDS and EC2 m1.xlarge EC2 and a db.m1.xlarge instances Amazon instances in the EU zone.
- Refer the RDS results in the paper First comparison is based on the performance degradation Second comparison is based on how the degraded performance is mitigated by introducing the cache. In previous papers we identified the network latency as approx 3 % of the total throughput.
- Refer the RDS results in the paper First comparison is based on the performance degradation Second comparison is based on how the degraded performance is mitigated by introducing the cache.
- Performs better in Tandem with the Optimized LRU caching strategy implemented in MySQL, as it relies on the LRU. The combination of both provide better performance results.