Deployment Patterns and Capacity Planning

Chintana WilamunaSolutions Architectchintana@wso2.com

Deployment patterns

● General reusable solution to a common recurring problem

● Production scenarios● Recommendations

Carbon component architecture

Carbon feature distributions

Carbon adaptability

Deployment patterns - Standalone

Separate runtimes

Deployment patterns - Standalone

Shared runtimes

Symbols used

Deployment patterns - Shared Registry - JDBC

Deployment patterns - Shared Registry - WS

Deployment patterns - Cluster - HA

● Carbon clustering○ Multicasting○ WKA○ AWS (Write to S3)

● Isolated instances○ Rely on load balancer

Deployment patterns - Cluster - Scalability

● Static○ Use any load balancer

Deployment patterns - Cluster with DepSync

Deployment synchronizer - SVN

Deployment architecture - things to note

● Infrastructure○ Physical / Virtual / Cloud / Hybrid

● Infrastructure policies● Non functional requirements (NFRs)

○ Performance○ Security○ High availability○ Disaster recovery

Deployment architecture - things to note

● Simplicity● Manageable - automation● Governance● Making future proof● Unexpected business demand● Change control / config management

Deployment - Reference architecture 1

Deployment - Reference architecture 2

Deployment - Reference architecture 3

Deployment - Reference architecture 4

Deployment - Reference architecture 5

Capacity planning

● Plan scaling● Size the deployment

Capacity planning - Gather data

● Monitoring systems● Business / Marketing stats● Current available data● Future / projected data

Capacity planning - Gather data

● Expected maximum throughput● Expected latency● Size of messages● Work done per transaction

Expected maximum TPS / peak load

● Need to know TPS / TPM (transactions per second and per minute) - TPD (per day) not that useful

● If you don’t know the exact number - try to get a rough idea 10s, 100s, 1000s etc...

Size of messages

● Try classifying○ Small (< 50k)○ Medium (< 1M)○ Large (< 5M)○ Extra large (> 5M)

● If larger than 1M, trial run - performance characteristics may vary

Apply for each tier

● Example - for API ManagerComponent Capacity Planning Guidelines

API Gateway Peak load of API calls

Auth Server Peak load of API calls

API Store Peak load of subscriptions and browsing

API Publisher Peak load of API publishing and LCM tasks

Analytics System load of API calls

Refer available perf. numbers

● ESB 4.8.1Average TPS across 500b - 10k msg size

DirectProxy 4,490

CBRProxy 3,703

CBRSOAPHeaderProxy 4,327

CBRTransportHeaderProxy 5,017

XSLTProxy 3,113

SecureProxy 483

http://wso2.com/library/articles/2014/02/esb-performance-round-7.5/

Apply for each tier

● Example - for API ManagerComponent Capacity Planning Guidelines

API Gateway Peak load of API calls

Auth Server Peak load of API calls

API Store Peak load of subscriptions and browsing

API Publisher Peak load of API publishing and LCM tasks

Analytics System load of API calls

Compute number of instances

Pattern With Analytics (WSO2 DAS)

Minimum - distributed (HA), internal store

5 = 2 GW + 2 KeyMgr + 1 Store & Publisher

API Mgr 5 + [minimum DAS HA] 2

Minimum - distributed (HA), external store

6 = 2 GW + 2 KeyMgr + 1 Store + 1 Publisher

6 API Mgr + [fully distributed DAS HA] 2 Recv + 2 Indexer + 2 Spark + 2 Dashboard

Note: API Manager + DAS deployment

Perf. test on your deployment

Note: API Manager + DAS deployment

● Actual use case● Message size● Infrastructure components● Tools (Jmeter, SOAP UI, Load UI etc…)

Work with a WSO2 consultant

● Fill the capacity planning sizing parameter doc

● Get help from a WSO2 consultant

Things to consider

● Keep a 30% buffer● Allocate 2 GB max heap per JVM● Keep 2 GB minimum for OS● Use system load for data / log growth● Keep perf. test and long running test as part

of user acceptance test

Harden/extend the deployment

● Secure vault● Headless worker nodes● Connect to existing LDAP/AD/RDBMS● OS tuning, JVM tuning● Connect to SDLC, change control

mechanisms

Thank You