Lecture IX: Multi-tenant Architecture CS 4593 Cloud-Oriented Big Data and Software Engineering

Lecture IX: Multi-tenant Architecture

CS 4593Cloud-Oriented Big Data and Software Engineering

Outline Multi-Tenant Architecture

Concepts Practice

Multi-tenant at data layer Multi-tenant database

Multi-tenant at logic layer Multi-tenant at UI layer

SaaS & Multi-Tenancy SaaS (Software-as-a-Service)

Software managed by SaaS vendor, run on SaaS server

Tenancy = client organization ~10 users, small/medium business

Multi-instance separate instance for each tenant

Multi-tenancy single instance of software serving multiple tenants

Why Multi-Tenancy Economy of scale

large number of tenants sharing the cost of single software instance cost saving for each individual user

Examples?

Multi-Tenancy Example

Single vs. Multi

Variant Multi-tenant Architecture

Multi-instance Multi-tenant

Multi-Tenancy in Practice

Complexity of Application

Size

of M

achi

ne

Blade

Big iron

Small Large

10000

Email

100

CRM

10

ERP

1000

Proj Mgmt

1

Banking

10000 100 101000

10000 1001000# tenants per database

• Economy of scale decreases with application complexity• At the sweet spot, compare TCO of 1 versus 100 databases

A Typical Blade Server

IBM HS20 (Wikipedia)

IBM BladeCenter HS12:

• CPU (single, dual, quad-core xeon 2~3 GHz)• Memory (max): 24 GB• Internal storage (max): 293 GB

24G / (10k tenant)= 2.4M/tenant

Multi-Tenancy in Practice

Complexity of Application

Size

of M

achi

ne

Blade

Big iron

Small Large

10000

Email

100

CRM

10

ERP

1000

Proj Mgmt

1

Banking

10000 100 101000

10000 1001000# tenants per database

• Economy of scale decreases with application complexity• At the sweet spot, compare TCO of 1 versus 100 databases

Outline Multi-Tenant Architecture

Concepts Practice

Multi-tenant at data layer Multi-tenant database

Multi-tenant at logic layer Multi-tenant at UI layer

Multi-Tenant Databases (MTD) Consolidating multiple businesses onto same

operational system Consolidation factor dependent on size of the

application and the host machine Support for schema extensibility

Essential for ERP applications

Multi-Tenant Databases (MTD) Support atop of the database layer

Non-intrusive implementation Query transformation engine maps logical tenant-

specific tables to physical tables Various problems, for example:

Various table utilization (“hot spots”)Metadata management when handling lots of tables

Classic Web Application (Basic Layout) Pack multiple tenants into the same tables by adding a tenant

id column

Great consolidation but no extensibility

Account

AcctId

1

2

Name

Acme

Gump

...TenId

17

17

35 1 Ball

42 1 Big

Private Table Each tenant gets his/her own private schema

No sharing SQL transformation: Renaming only

High meta-data/data ratio Lots of tables: linear in # of tenants, each with

own meta-data Low buffer utilization (~8k for index/data for each

table)

Private TableAccount

AcctId

12

Name

AcmeGump

...TenId

1717

35 1 Ball

42 1 Big

CRM Schema

Handling Lots of Tables Simplifying assumption: No extensibility

Experiment setup: CRM schema with 10 tables 10,000 tenants are packed onto one DBMS (DB2,

1G Memory) Data set size remains constant

Handling Lots of Tables Parameter: Schema Variability

Number of tenants per schema instance 0 (least variable): all tenants share one instance

(= 10 tables) 1 (most variable): each tenant has separate

instance (= 100k tables)

Handling Lots of Tables – Results

10 fully shared Tables

100.000 private Tables

Extension Table Split off the extensions into separate tables

Additional join at runtime Row column for reconstructing the row

(discussion: consider Acct17)

Extension Table (Cont’d)

Extension Table (Cont’d) Good: Better consolidation than Private Table

layout common attributes go to same table

Bad: Number of tables still grows in proportion to number of tenants tenants in same domain may often have varied

schema so large # of *extension* tables (such as

Healthcare_account)

Extension Table

Account17(A, N, H, B) =select Ae.A, Ae.N, Ha.H, Ha.Bfrom Account_ext as Ae, Healthcare_account as Ha where Ae.Tenant = Ha.Tenant & Ae.Row = Ha.Row

and Ae.Tenant = 17

Universal Table Generic structure with VARCHAR value columns

n-th column of a logical table is mapped to ColN in an universal table

Extensibility: # of columns may expand as needed Disadvantages

Very wide rows Many NULL values Not type-safe Casting necessary No index support (note column index not very

meaningful)

Universal Table

logical table (private after renaming)

Pivot Table1. Each field of a row in logical table is

given its own row.2. Multiple pivot tables for each type (int,

string, e.g.)

Pivot Table

Row: 0

Int

String

Reconstruct Tenant Table from Pivot Table

Row: 0

Int

String

Account17(H, B) =select Ps.Str, Pi.intfrom Pivot_str as Ps, Pivot_int as Pi where Ps.Tenant = Pi.Tenant &

Ps.Table = Pi.Table &Ps.Row = Pi.Row &Ps.Col = 2 &Ps.Col = 3 &Ps.Tenant = 17 &Ps.Table = 0

align

(Only Hospital & Beds)

Reconstruct Tenant Table (cont’d)

Row: 0

Int

String

Account17(A, N, H, B) =select Pi’.int, Ps’.str, Ps.Str, Pi.intfrom Pivot_int as Pi’, Pivot_str as Ps’,

Pivot_str as Ps, Pivot_int as Pi where Pi’.Tenant = Ps’.Tenant & Ps’.Tenant = Ps.Tenant & Ps.Tenant = Pi.Tenant & Pi’.Table = Ps’.Table &

Ps’.Table = Ps.Table & Ps.Table = Pi.Table & Pi’.Row = Ps’.Row & Ps’.Row = Ps.Row &

Ps.Row = Pi.Row &Pi’.Col = 0 & Ps’.Col = 1 &Ps.Col = 2 & Ps.Col = 3 &Ps.Tenant = 17 & Ps.Table = 0

align: same tenant, table, row

4-way join

Pivot Table: Performance Generic type-safe structure

Eliminates handling many NULL values Performance

Depends on the column selectivity of the query (number of reconstructing joins)

E.g., query on A17(H,B) is more selective than A17(A,N,H,B)

See previous example

Pivot Table Chunk Table

Row: 0 Row: 0

Chunk 0 Chunk 1Field 0 Field 1 Field 2 Field 3

Pivot table Chunk table

one row for each field one row for each chunk

How to Chunk or Fragment Original Rows Many possible fragmentations

One idea: group fields by their “popularity”

Chunk Table

Row: 0

Chunk 0 Chunk 1

Account17(A, N, H, B) =select Cis.Int1, Cis.Str1,

Cis’.Str1, Cis’.Int1from Chunk Cis, Chunk Cis’where Cis.Chunk = 0 &

Cis’.Chunk =1 &Cis.Row = Cis’.Row &Cis.Tenant = Cis’.Tenant &Cis.Table = Cis’.Table

2. merge chunk 1. align rows

3. reconstruct original row

2-way join

Chunk Table vs. Universal Table

Chunk 0 Chunk 1

# of rows (for each original row) = # of chunks

Chunk 0

only one row for each original row

Universal as extreme chunking: only one chunk per row

Chunk Table Performance

Row: 0

Chunk 0 Chunk 1

Querying Chunk Tables Query Transformation

Row reconstruction needs many self- and equi-joins

Can be automatically translated

Querying Chunk Tables Compilation Scheme:

1. Collect all table names and their corresponding columns from the logical source query

2. Obtain table definitions: for each tablea. obtain the Chunk Tables and the meta-data identifiers

representing the used columnsb. generate a query that filters the correct columns (based on

the meta-data identifiers) and aligns the different chunk relations on their ROW column.

3. Extend each table reference in the logical source query by corresponding table definition (obtained in step 2)

Query Example: Step 1

Step 1 result:tables = {Account17}columns = {Account17.Beds, Account17.Hospital}

Query Example: Step 2

Int String

Query Example: Step 3 (Chunk Table)

Chunk 0 Chunk 1

Summary Multi-tenancy database critical to scale SaaS

solution Varied schema layout schemes

different degrees of consolidation & extensibility optimal layout depends on particular data set,

work load, etc. Novel Chunk Table layout

Outline Multi-Tenant Architecture

Concepts Practice

Multi-tenant at data layer Multi-tenant database

Multi-tenant at logic layer Multi-tenant at UI layer

Web-Worker Model

Web role is frontend, Worker Role is backendWeb role is worker role with Web Servers

Design IssuesApplication

Web Roles and Worker RolesStateless design

Easy-to-Scale Fault Tolerance and Recovery

Under-the-cover Multiple instances Each runs in Virtual Machine Handled automatically by hypervisor

Stateless is importantWhy?

Random assignment of tasks to workersNo overhead of reading user profilesEasy Replacement and Recover

Agent and Fabric

Fabric Allocate resources according to

configuration file Detect and restart failed web

roles and workers

AgentExposes the APIMonitors the

failure conditions of the application

Code SamplesQueue

var lowMessages = new List<BrokeredMessage>();

for (int i = 0; i < 10; i++){ var message = new BrokeredMessage() { MessageId = Guid.NewGuid().ToString() }; message.Properties["Priority"] = Priority.Low; lowMessages.Add(message);}

this.queueManager.SendBatchAsync(lowMessages).Wait();

Code SamplesWorker

protected override async Task ProcessMessage(BrokeredMessage message){ // Simulate message processing for High priority messages. await base.ProcessMessage(message); Trace.TraceInformation("High priority message processed by " + RoleEnvironment.CurrentRoleInstance.Id + " MessageId: " + message.MessageId);}

protected virtual async Task ProcessMessage(BrokeredMessage message) { // Simulating processing. await Task.Delay(TimeSpan.FromSeconds(2)); }

Worker Models

Worker Models

Queue Models

Queue Models

Outline Multi-Tenant Architecture

Concepts Practice

Multi-tenant at data layer Multi-tenant database

Multi-tenant at logic layer Multi-tenant at UI layer

Partitioning TenantsWeb role

AuthenticationURL-PathSub-domainsCustom domains

Partitioning TenantsClient Layer

AjaxAndroid client

Summary Multi-Tenant Architecture

Concepts Practice

Multi-tenant at data layer Multi-tenant database

Multi-tenant at logic layer Multi-tenant at UI layer