Docker Based SaaS Platform - Case Study
Download as PPTX, PDF2 likes833 views
This document discusses how Docker containerization was leveraged to power a large-scale, globally available Software as a Service (SaaS) platform serving over 3000 developers from over 125 countries. Some key points: 1) Docker provided process isolation, CPU/memory partitioning, volume partitioning, and file sharing which optimized resource utilization and allowed high density deployment of containers hosting user applications and data. 2) A container allocation strategy using Docker allowed new users to quickly obtain isolated environments while existing inactive users' containers were passivated to disk for later reactivation, improving efficiency. 3) Automated passivation and reactivation handled inactive users by hibernating their containers and restoring from disk on next request, while
Docker Based SaaS Platform - Case Study
- 1. Docker Based SaaS Platform - Case Study Leveraging Docker Containerization to power a large user base SaaS 1
- 2. WaveMakerOnline.com 2500 DEVELOPERS from 125+ countries Over 4 Million Application Hits Over 25 GB App Data Transferred Over 37,000 Containers Provisioned SaaS Based aPaaS Platform
- 3. Requirements • Available 24x7 • Across all geographies • Developer Platform (3000+ Developers) • Isolation, Security • Deploy Applications
- 4. Docker provides Higher Density
- 5. Leveraging Docker • Process Isolation – LXC namespaces & control groups provides user level separation for processes • CPU/Memory partitioning – Using control groups we can limit the usage of physical resources (eg: 20% max. memory for any given virtual server) • Volume partitioning – AWS EBS volumes are partitioned and attached to individual virtual servers • Sharing of OS-level file resources – ‘aufs’ (filesystem) enables layered read/write directories – Only writes by the user processes are included in the snapshot, reducing the footprint for each user 5
- 6. Container in detail MonitoringAgent OSJ-Stack: Industry standard Open-source Java™ stack Processes reside in their “namespaces” and requires no configuration changes Docker Container provides isolation for an application’s platform stack 80 3306 Network Bridge 8080 23306 Processes within namespaces can be exposed outside the containers for troubleshooting
- 7. Optimized Resource Utilization 1.Container Allocation 2.On-Demand Activation 3.Automated Passivation 4.Snapshot Optimization Container Lifecycle
- 8. Container Allocation8 EC2 m1.large Using Docker, a Container is created for each user or app CPU & Memory resources of underlying instance are shared by Containers Each Container encapsulates the services, configuration and application data New Users • Platform uses LRU based algorithm for allocating and de-provisioning of Containers, to provide multi-tenancy • Containers are lightweight, consumes lesser resources and are faster to bootstrap
- 9. On-Demand Activation9 Platform Load Balancer Restore Container’s state along with application data from Storage (S3) Activation Dispatches request to restored back-end node App Request S3 Intercepts App Request Returning User If activation takes longer time due to the size of the snapshot, user experiences delays in app access
- 10. Automated Passivation10 X CPU & Memory used by Container is reclaimed A snapshot of Container is taken and saved to S3 Hibernation Passivation Activation Restore the Container back to running state User Inactive Passivation saves entire application state and configuration to storage for later usage S3
- 11. Snapshot Optimization11 /var/lib/mysql data_dir /usr/tomcat webapps lib Read-Only directories, resides in Base Image Read-Write directories, only the updated files are copied to rootfs (snapshot location) S3 AUFS (union file system) provides layered read/write directories, enabling copy-on-write at the file-system Tremendous reduction in snapshot size, as only the modified files are included
- 12. Scaling to large user base12 34.3 23.8 26.8 23.7 7.4 51.8 78.8 62 72 76.3 0 20 40 60 80 100 120 23 30 33 34 100 No. of Virtual Servers Response Time (ms) TPS/Virtual Server 0 20 40 60 80 Sys% CPU%
- 13. Virtual Server Recovery Management13 S3 EBS On passivation, snapshots are saved to AWS S3 Virtual Server’s file-system is mounted from EBS volume Application Data and configuration can be restored from the EBS volumes in the event of system crashes. It is application’s responsibility to persist in-memory data to persistence storage. Snapshots of EBS volumes are taken at regular intervals to reduce data losses
- 14. Thank You