Table of Contents Développement logiciel pour le Cloud (TLC) 2. PaaS: the example of ConPaaS Guillaume Pierre 1 Introduction 2 ConPaaS usage 3 ConPaaS architecture Université de Rennes 1 Fall 2012 http://www.globule.org/~gpierre/ 4 Performance control 5 Conclusion Développement logiciel pour le Cloud (TLC) 1 / 38 Développement logiciel pour le Cloud (TLC) 2 / 38 Table of Contents Typical Cloud Applications (according to AWS) 1 Introduction 2 ConPaaS usage 3 ConPaaS architecture 4 Performance control 5 Conclusion Application Hosting Backup and Storage Content Delivery E-Commerce High Performance Computing Media Hosting On-Demand Workforce Search Engines Web Hosting Développement logiciel pour le Cloud (TLC) Introduction 1 / 38 Développement logiciel pour le Cloud (TLC) Introduction 2 / 38
Applications running at Amazon Web Services Many Cloud applications are alike Web servers Application servers Database servers High-performance frameworks (MapReduce, MPI, Workows)... and a few percents of miscellaneous programs Cloud application developers often rebuild the same types of frameworks again and again and again... Sample: 50 applications from the AWS Customer App Catalog. Développement logiciel pour le Cloud (TLC) Introduction 3 / 38 Développement logiciel pour le Cloud (TLC) Introduction 4 / 38 Can the Cloud help support common types of applications? Main PaaS environments Infrastructure-as-a-Service provides basic computing resources Absolute exibility: you can build anything you want But it can be very complex and time consuming Deployment Software upgrades Fault-tolerance Performance monitoring Resource provisioning Dynamic reconguration orchestration etc. Platform-as-a-Service provides high-level services Each PaaS service targets a specic family of applications Provide a simple deployment environment for applications Provide high-level guarantees for applications using these services Google AppEngine Microsoft Azure Amazon Beanstalk RightScale OpenShift ConPaaS etc. Dierent PaaS environments address dierent types of applications Développement logiciel pour le Cloud (TLC) Introduction 5 / 38 Développement logiciel pour le Cloud (TLC) Introduction 6 / 38
ConPaaS in a nutshell Broad range of functionalities Application servers, databases, high-performance computing, other Fully integrated Applications can compose any set of services together Easy to use but also very powerful Simple Web GUI + powerful command-line tool Services are highly customizable Cutting-edge SLA enforcement technologies Elasticity and resource provisioning techniques to guarantee performance at the lowest possible cost Runs over Amazon EC2 and OpenNebula Open-source Table of Contents 1 Introduction 2 ConPaaS usage 3 ConPaaS architecture 4 Performance control 5 Conclusion http://www.conpaas.eu Développement logiciel pour le Cloud (TLC) Introduction 7 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS usage 8 / 38 ConPaaS Applications A ConPaaS application is dened as a composition of multiple service instances For example: web hosting service + MySQL database + logging service (to store access logs) End user ConPaaS Services Web hosting (PHP, Java) Databases (MySQL, Scalarix) File system (XtreemFS) PHP service (using 1 or more machine instances) High-performance computations (MapReduce, TaskFarming) Functional testing (Selenium) Logging service (using 1 or more machine instances) SQL data service (using 1 or more machine instances) Développement logiciel pour le Cloud (TLC) ConPaaS usage 9 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS usage 10 / 38
ConPaaS Operation The ConPaaS Front-End Users access ConPaaS thanks to a Web interface Login Start new services (i.e., start a standard VM image with the service implementation) Manage existing services (i.e., communicate with the service's manager to issue commands) Stop services (i.e., stop all service instances except the service manager) Terminate services (i.e., destroy a service completely) An extended set of functionalities is available through a command-line interface All commands from the Web interface are available (except starting a new service) Additional commands may be implemented for expert users The command-line interface makes it easy to script service management Développement logiciel pour le Cloud (TLC) ConPaaS usage 11 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS usage 12 / 38 The ConPaaS Front-End The ConPaaS Front-End Développement logiciel pour le Cloud (TLC) ConPaaS usage 12 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS usage 12 / 38
The ConPaaS Front-End The ConPaaS Front-End Développement logiciel pour le Cloud (TLC) ConPaaS usage 12 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS usage 12 / 38 The ConPaaS Front-End The ConPaaS Front-End Développement logiciel pour le Cloud (TLC) ConPaaS usage 12 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS usage 12 / 38
The ConPaaS Front-End Uploading new application versions Développement logiciel pour le Cloud (TLC) ConPaaS usage 12 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS usage 13 / 38 Uploading new application versions Uploading new application versions Développement logiciel pour le Cloud (TLC) ConPaaS usage 13 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS usage 13 / 38
Scaling a service Scaling a service Développement logiciel pour le Cloud (TLC) ConPaaS usage 14 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS usage 14 / 38 The ConPaaS command-line interface The ConPaaS command-line interface Développement logiciel pour le Cloud (TLC) ConPaaS usage 15 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS usage 15 / 38
The ConPaaS command-line interface Table of Contents 1 Introduction 2 ConPaaS usage 3 ConPaaS architecture 4 Performance control 5 Conclusion Développement logiciel pour le Cloud (TLC) ConPaaS usage 15 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS architecture 16 / 38 Architecture of a ConPaaS service ConPaaS Organization Legend End users Virtual machine A ConPaaS service is implemented as one or more virtual machine instances dedicated to a single user Single-tenant: each VM belongs to a single user No VM sharing between services (even for the same user) ConPaaS services are elastic: we can grow/shrink their capacity at runtime with no service disruption Horizontal provisioning: add/remove virtual machines ConPaaS services will support dynamic resource provisioning: automatic capacity adjustment to support performance guarantees at minimum cost Service admin Management traffic Application trafic Frontend GUI Frontend Logic PHP service Manager MySQL service Manager Web servers (static pages) MySQL master Load Balancer Load Balancer PHP servers (dynamic pages) MySQL slaves PHP service MySQL service Control plane Data plane Développement logiciel pour le Cloud (TLC) ConPaaS architecture 17 / 38 conpaas Développement logiciel pour le Cloud (TLC) ConPaaS architecture 18 / 38
ConPaaS Organization Lifecycle of a ConPaaS service Legend End users Virtual machine Service admin Management traffic Application trafic Frontenend Front- GUI Logic PHP service Manager Web servers (static pages) Load Balancer PHP servers (dynamic pages) PHP service No service Create Terminate Service created (1 manager VM) Start Stop Service started (1 manager VM + N agent VMs) Scale up/down MySQL service Manager Load Balancer MySQL service MySQL master MySQL slaves Service specific operations Control plane Data plane Each manager VM contains a manager process Each agent VM contains an agent process Développement logiciel pour le Cloud (TLC) ConPaaS architecture 19 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS architecture 20 / 38 The Web hosting service The service exists in two versions: PHP and Java Initially the service has 2 VMs 1 VM running the manager 1 VM running a load balancer, a web server and a PHP backend When adding VMs each VM becomes specialized (load balancer VMs, web server VMs, PHP backend VMs) Manager Proxy Web PHP +1 PHP +1 PHP Manager Proxy Web Web +1 Web Manager Proxy Session handling in the PHP service PHP has built-in support for sessions Normally stored in main memory of the PHP server We must share session state between multiple PHP backends (otherwise users would logout at each request) We use the Scalaris key-value store for that One Scalaris server inside the manager VM Making use of the Scalaris session storage is totally transparent to the applications Manager Proxy PHP +1 PHP Web PHP PHP Développement logiciel pour le Cloud (TLC) ConPaaS architecture 21 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS architecture 22 / 38
What we want to avoid Service reconguration When the user scales the service up: 1 The front-end sends a request to the service manager to scale up 2 The service manager creates a new VM with proper contextualization information, then starts polling 3 The agent VM boots, then starts its manager process 4 When the manager establishes a connection with the agent, it requests it to start one or more roles 5 The manager uploads code/data as necessary 6 The manager recongures other VMs as necessary When scaling down: Same story in opposite order Développement logiciel pour le Cloud (TLC) ConPaaS architecture 23 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS architecture 24 / 38 Building new ConPaaS services Structure of a service implementation Building new ConPaaS services from scratch was HARD Build a proper VM image with contextualization Develop new manager and agent deamons Implement a standardized protocol between the front-end and the agents All communication goes over SSL with custom security checks Solution: the service core All ConPaaS services use a single VM image All ConPaaS services use the same manager and agent deamons The service core implements shared functionality between all services Start/stop/contextualize virtual machines Secure communication primitives Performance monitoring mechanisms Each service can specialize the service core Implement the service-specic parts Building a new ConPaaS service from the service core is now EASY: (optional) Provide shell scripts to be executed when VMs start and stop Write a manager and an agent class in Python Extend one Python le to register the new service Extend the front-end with one service-specic page in PHP Adding functionality to all services is quite easy as well Secure internal communication Support for new clouds Performance monitoring Développement logiciel pour le Cloud (TLC) ConPaaS architecture 25 / 38 Développement logiciel pour le Cloud (TLC) ConPaaS architecture 26 / 38
Table of Contents The varying capacity problem 1400 1 Introduction 1200 2 ConPaaS usage 3 ConPaaS architecture 4 Performance control 5 Conclusion Requests/second 1000 800 600 400 200 0 Mon 09/17/07 Wed 09/19/07 Fri 09/21/07 Sun 09/23/07 Tue 09/25/07 Time Thu 09/27/07 Sat 09/29/07 Mon 10/01/07 Wed 10/03/07 Développement logiciel pour le Cloud (TLC) Performance control 27 / 38 Développement logiciel pour le Cloud (TLC) Performance control 28 / 38 The varying capacity problem The varying capacity problem 1400 1200 Static provisioning 1400 1200 Dynamic provisioning 1000 1000 Requests/second 800 600 Requests/second 800 600 400 400 200 200 0 Mon 09/17/07 Wed 09/19/07 Fri 09/21/07 Sun 09/23/07 Tue 09/25/07 Time Thu 09/27/07 Sat 09/29/07 Mon 10/01/07 Wed 10/03/07 0 Mon 09/17/07 Wed 09/19/07 Fri 09/21/07 Sun 09/23/07 Tue 09/25/07 Time Thu 09/27/07 Sat 09/29/07 Mon 10/01/07 Wed 10/03/07 Développement logiciel pour le Cloud (TLC) Performance control 28 / 38 Développement logiciel pour le Cloud (TLC) Performance control 28 / 38
Dynamic resource provisioning Dynamic resource provisioning Response time Response time SLO SLO Time Time Développement logiciel pour le Cloud (TLC) Performance control 29 / 38 Développement logiciel pour le Cloud (TLC) Performance control 29 / 38 Dynamic resource provisioning Dynamic resource provisioning Response time Response time Add new resource SLO Add new resource Traffic decreases SLO Time Time Développement logiciel pour le Cloud (TLC) Performance control 29 / 38 Développement logiciel pour le Cloud (TLC) Performance control 29 / 38
Dynamic resource provisioning Web applications in the textbooks Response time Add new resource Traffic decreases Release resource without violating the SLO SLO Time Développement logiciel pour le Cloud (TLC) Performance control 29 / 38 Développement logiciel pour le Cloud (TLC) Performance control 30 / 38 Web applications in the real world Web applications in the real world Customer service Advertisement service Real time promotion service More than 100 services are called to collect data and construct the Amazon.com gateway page. Werner Vogels, Amazon CTO. Développement logiciel pour le Cloud (TLC) Performance control 31 / 38 Développement logiciel pour le Cloud (TLC) Performance control 31 / 38
Provisioning in a multi-service Web application Provisioning in a multi-service Web application When the application needs more capacity, where should I place extra resources? Développement logiciel pour le Cloud (TLC) Performance control 32 / 38 Possible solutions Développement logiciel pour le Cloud (TLC) Performance control 33 / 38 Collaborative resource provisioning Observed response time: 510 ms Classical solution: impose an SLO to each service individually 1 2 Each service can be scaled in isolation Which SLO should we set for backend services? Overall performance is suboptimal Our solution: impose an SLO to the front-end service only I I No particular performance constraint for the other services All services collaborate to maintain the front-end's performance at minimum cost Développement logiciel pour le Cloud (TLC) Performance control 34 / 38 3 Développement logiciel pour le Cloud (TLC) 4 Performance control 35 / 38
Collaborative resource provisioning Collaborative resource provisioning Observed response time: 510 ms Predicted: 505 ms Observed response time: 510 ms Predicted: 480 ms 1 +1 extra machine 1 2 2 +1 extra machine 3 4 3 4 Développement logiciel pour le Cloud (TLC) Performance control 35 / 38 Développement logiciel pour le Cloud (TLC) Performance control 35 / 38 Collaborative resource provisioning Collaborative resource provisioning Observed response time: 510 ms Predicted: 410 ms Observed response time: 510 ms Predicted: 450 ms 1 1 2 2 +1 extra machine 3 4 3 4 +1 extra machine Best choice: add a machine at service 3 Développement logiciel pour le Cloud (TLC) Performance control 35 / 38 Développement logiciel pour le Cloud (TLC) Performance control 35 / 38
Table of Contents Conclusion 1 Introduction 2 ConPaaS usage 3 ConPaaS architecture 4 Performance control 5 Conclusion ConPaaS is a platform-as-a-service environment Designed to facilitate elastic application hosting in the cloud Designed to be easily extensible ConPaaS addresses two major classes of applications: Web applications Scientic applications Combinations of both We will use ConPaaS for practical assignments www.conpaas.eu Développement logiciel pour le Cloud (TLC) Conclusion 36 / 38 Développement logiciel pour le Cloud (TLC) Conclusion 37 / 38 Credits Ismail El Helw (server side) Adriana Szekeres (server side) Emanuele Rocca (server side) Claudiu Gheorghe (Web GUI) Développement logiciel pour le Cloud (TLC) Conclusion 38 / 38