Docker Based SaaS Platform - Case Study

1

Docker Based SaaS Platform - Case Study Leveraging Docker Containerization to power a large user base SaaS

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

Requirements• Available 24x7• Across all geographies• Developer Platform (3000+ Developers) • Isolation, Security• Deploy Applications

Docker provides Higher Density

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

Container in detail

Monitoring A

gent

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

Optimized Resource Utilization

1.Container Allocation

2.On-Demand Activation

3.Automated Passivation

4.Snapshot Optimization

Container Lifecycle

Container Allocation8

EC2 m1.largeUsing 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

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 RequestReturning

User

If activation takes longer time due to the size of the snapshot, user experiences delays in app access

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

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

Scaling to large user base12

23 30 33 34 1000

20

40

60

80

100

120

34.323.8 26.8 23.7

7.4

51.878.8

62 7276.3

Response Time (ms)TPS/Virtual Server

No. of Virtual Servers

010203040506070

Sys%CPU%

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

Thank You