44
Salesforce’s Multitenant Architecture Doug Merrett Principal Enterprise Architect – Asia Pacic [email protected] How we do the magic we do…

Understanding the Salesforce Architecture: How We Do the Magic We Do

Embed Size (px)

Citation preview

Page 1: Understanding the Salesforce Architecture: How We Do the Magic We Do

Salesforce’s Multitenant Architecture

 Doug Merrett  Principal Enterprise Architect – Asia Pacific  [email protected]

How we do the magic we do…

Page 2: Understanding the Salesforce Architecture: How We Do the Magic We Do

Safe harbor statement under the Private Securities Litigation Reform Act of 1995:

This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.

The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.

Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.

Safe Harbor

Page 3: Understanding the Salesforce Architecture: How We Do the Magic We Do

Shared services across applications The Customer Success Platform

API

s

2,700+ Partner Apps

Open Ecosystem

Workflow Data & Objects Identity

Fast App Dev & Customization

Analytics Collaboration Mobile UI

Scalable Metadata Platform

Complete CRM

Trusted Multitenant Cloud

Analytics Community Marketing Service Sales Apps

Page 4: Understanding the Salesforce Architecture: How We Do the Magic We Do

Multitenancy

Page 5: Understanding the Salesforce Architecture: How We Do the Magic We Do

One Cloud with Many Customers

Shared Elastic Services One Primary Data Store per Production Instance 8K+ Customers per Instance 50+ Production Instances

All data segregated by customer All operations include Org ID Disaster Recovery Per Org encryption keys

Page 6: Understanding the Salesforce Architecture: How We Do the Magic We Do

What is in an Instance

Pivot tables

Data tables

Metadata tables

Shared Database Metadata Cache

Bulk data processing

Multitenant aware Query optimizer

Runtime App Generator

Full text search engine

Virtual Application Components

Common Application Screens

Tenant Specific Screens

Objects (Tables)

Page 7: Understanding the Salesforce Architecture: How We Do the Magic We Do

What Multitenancy means for Salesforce R&D

No Legacy Teams Bugs fixed for everyone

One Version

Page 8: Understanding the Salesforce Architecture: How We Do the Magic We Do

What Multitenancy means for Salesforce R&D

No Legacy Teams Bugs fixed for everyone

One Version 260K+ of our Tests Run your tests as well

Automation

Page 9: Understanding the Salesforce Architecture: How We Do the Magic We Do

What Multitenancy means for Salesforce R&D

No Legacy Teams Bugs fixed for everyone

One Version

Instance Architecture

260K+ of our Tests Run your tests as well

Automation

Staggered Releases Scalability across all sizes

Page 10: Understanding the Salesforce Architecture: How We Do the Magic We Do

What Multitenancy means for Salesforce R&D

Three major releases per year Bug fixes every week

Predictability

No Legacy Teams Bugs fixed for everyone

One Version

Instance Architecture

260K+ of our Tests Run your tests as well

Automation

Staggered Releases Scalability across all sizes

Page 11: Understanding the Salesforce Architecture: How We Do the Magic We Do

What Multitenancy means for Salesforce R&D

Three major releases per year Bug fixes every week

Predictability

No Legacy Teams Bugs fixed for everyone

One Version

Instance Architecture

260K+ of our Tests Run your tests as well

Automation

Staggered Releases Scalability across all sizes

Page 12: Understanding the Salesforce Architecture: How We Do the Magic We Do

 Stateless Appservers

 Database system of record

 No Database Definition Language (DDL) at Runtime

 All tables partitioned by OrgId

 Smart Primary Keys, Polymorphic Foreign Keys

 Creative de-normalization and pivoting

 Use every RDBMS feature & optimization

Key Architectural Principles

Page 13: Understanding the Salesforce Architecture: How We Do the Magic We Do

Metadata, data, and pivot table structures store data corresponding to virtual data structures

Page 14: Understanding the Salesforce Architecture: How We Do the Magic We Do

The Objects table stores metadata about custom objects (tables)‏

Page 15: Understanding the Salesforce Architecture: How We Do the Magic We Do

The Fields table stores metadata about custom fields (columns)‏

Page 16: Understanding the Salesforce Architecture: How We Do the Magic We Do

The Data heap table stores all structured data corresponding to custom objects

Page 17: Understanding the Salesforce Architecture: How We Do the Magic We Do

A single slot can store various types of data that originate from different objects

Page 18: Understanding the Salesforce Architecture: How We Do the Magic We Do

The Indexes pivot table manages tenant-specific selective indexes

Page 19: Understanding the Salesforce Architecture: How We Do the Magic We Do

The UniqueFields pivot table facilitates uniqueness for custom fields

Page 20: Understanding the Salesforce Architecture: How We Do the Magic We Do

The Relationships pivot table facilitates referential integrity and optimizes joins

Page 21: Understanding the Salesforce Architecture: How We Do the Magic We Do

 Tables hash partitioned by OrgId

 Separate connection pools point to physical hosts

 App tier is also dynamically partitioned by OrgId

 Distributed metadata cache with transactional invalidation

All data & metadata structures are partitioned to improve performance and manageability

Page 22: Understanding the Salesforce Architecture: How We Do the Magic We Do

§  Native Declarative features

§  Bulk Processing

§  The Recycle Bin

§  Full Text Search

§  Smart Bulk Data Manipulation Language (DML)

§  Web Services APIs

Application Framework: a whole lot for free

Page 23: Understanding the Salesforce Architecture: How We Do the Magic We Do

Force.com’s native Application Framework provides declarative development, no coding

Page 24: Understanding the Salesforce Architecture: How We Do the Magic We Do

Validation rules and simple formulas: Business analysts can “code” these

Page 25: Understanding the Salesforce Architecture: How We Do the Magic We Do

Not so simple: Rollup-summary fields provide for easy cross-object summaries

Page 26: Understanding the Salesforce Architecture: How We Do the Magic We Do

Force.com’s bulk processing optimizations reduce overhead for data loads

Page 27: Understanding the Salesforce Architecture: How We Do the Magic We Do

 Examples:

§  Sort all records by primary key before attempting DML

§  Operate on tables in deterministic order

§  Slot reallocation for field datatype change

§  Deferred calculation for new rollup-summary field

§  Background processing of mass changes

Data definition processing is optimized to avoid performance hits or concurrency limits

Page 28: Understanding the Salesforce Architecture: How We Do the Magic We Do

The Recycle Bin: Smart Undeletes

Restore

§  Individual object instances (records)

§  Related object instances (parent/child records)

§  Entire fields and objects (dropped columns and tables)

Page 29: Understanding the Salesforce Architecture: How We Do the Magic We Do

Secondary Instance

Multitenant Search, anything but simple

Index Backup

Replication

Primary Instance

Page 30: Understanding the Salesforce Architecture: How We Do the Magic We Do

Multitenancy delivers Blazing Performance

Transactions Per Quarter 234B Transactions in Q2FY16

79% YoY Growth

Average Page Time 208ms Latency in Q2FY16 4% YoY Improvement

API

Web

Page 31: Understanding the Salesforce Architecture: How We Do the Magic We Do

 Consistent SQL generation across the application

 Deep awareness of pivot table structure

•  Flex schema does impose a cost

 Tenant, user, object, fields statistics are crucial

 No runaway queries allowed

 Deep integration with the sharing model

Multitenant Query Optimization Principles

Page 32: Understanding the Salesforce Architecture: How We Do the Magic We Do

Multitenant Query Optimizer

Check user visibility

Check filer selectivity

Dynamically write query based on pre-queries

Run Pre-Queries

Execute optimized query

user visibility = number of rows user can access

filter selectivity = index corresponding to filter column

Search originates from API or global search

return results

Page 33: Understanding the Salesforce Architecture: How We Do the Magic We Do

The optimizer considers pre-query selectivity measurements when writing a query

Pre-Query Selectivity

Measurements

… use of index related to filter. High High

… ordered hash join; drive using Data table. Low High

… use of index related to filter. High Low

… nested loops join; drive using view of rows that the user can see. Low Low

Write final database access query, forcing … Filter User

Page 34: Understanding the Salesforce Architecture: How We Do the Magic We Do

Highly Scalable Multitenant Architecture

Page 35: Understanding the Salesforce Architecture: How We Do the Magic We Do

Service isolation and redundant design ensures availability Highly Scalable Multitenant Architecture

•  Instances –  Consistent deployment size –  Easy to scale –  Repeatable

•  Instance Groups –  Shared service isolation

within a Data Center

• Data Centers –  Consistent for Production

and Disaster Recovery –  Shared services across data

centers Data Centre

Shared Services

Instance Group Shared

Services

Sandbox DR Instances

Sandbox Instances

Core DR Instances

Core Instances

Instance Group Shared

Services

Sandbox DR Instances Sandbox

Instances Core DR

Instances Core Instances

Data Centre

Shared Services

Instance Group Shared

Services

Sandbox DR Instances Sandbox

Instances Core DR

Instances Core Instances

Instance Group Shared

Services

Sandbox DR Instances Sandbox

Instances Core DR

Instances Core Instances

Page 36: Understanding the Salesforce Architecture: How We Do the Magic We Do

 Production cluster capacity

•  7+1 (active + spare) nodes

•  Active Data Guard to local standby (2 node cluster) for fast data recovery

 Data replication to secondary instance

•  Encrypted block-level replication

•  Enables site switching for disaster recovery

Redundant Site Design with 4 Online Copies of Data Today: Reliable Core by Design

Encrypted Async

Replication Data Guard Replication

Primary Instance

Application Servers

Production DB Cluster

Standby DB Cluster

Data Guard Replication

Application Servers

Production DB Cluster

Standby DB Cluster

Secondary Instance

Page 37: Understanding the Salesforce Architecture: How We Do the Magic We Do

 6+2 Production RAC Cluster

•  2 spare nodes provides additional DB cluster resilience

 Data Guard to remote site

•  Hardens remote replication

•  Enables faster site switching

•  Shorter planned and unplanned maintenance windows

Faster Site Switches Tomorrow: Enhancing Core Reliability

Encrypted Async DB

Replication

Data Guard Replication

Primary Instance

Application Servers

Production DB Cluster

Standby DB Cluster

Data Guard Replication

Application Servers

Production DB Cluster

Standby DB Cluster

Secondary Instance

Page 38: Understanding the Salesforce Architecture: How We Do the Magic We Do

4 key methods to enable performance at scale Adaptive Capacity Planning

 Horizontally  Scaling

 Scale by adding additional servers or storage for each application

 Scale by using more powerful servers

•  More CPU cores

•  Larger memory

 Continuous Salesforce application and database optimizations

 Regular customer and partner application tuning to improve individual org performance

 Vertically  Scaling

 Application and DB  Tuning

 Customer Application  Tuning

45% Reduction in Latency

NA7 Aug 20

NA7 Aug 27

360

ms

250

ms

140+ Hours Loading Time

21 Hours Loading Time

85% Reduction in Load Time

1 2 3 4

Automatically Done For Customers

48c

48c

64c

64c

Page 39: Understanding the Salesforce Architecture: How We Do the Magic We Do

Force.com Extras

Page 40: Understanding the Salesforce Architecture: How We Do the Magic We Do

Apex: Force.com’s procedural frontier Integer NUM = 10; Account [] accs; // Clean up old data accs = [select id from account where name like 'test%']; delete accs; commit; accs = new Account [NUM]; for (Integer i = 0; i < NUM; i++) { accs [i] = new Account (name='test ' + i, outstandingshares__c=i); } insert accs; Contact [] cons = new Contact [0]; for (Account acc : accs) { cons.add (new Contact (lastName=acc.name + '1', accountid=acc.id)); cons.add (new Contact (lastName=acc.name + '2', accountid=acc.id)); } insert cons;

SOQL Query

Variable Declaration

Control Structure

Array

Data Operation

Commit Transaction

Page 41: Understanding the Salesforce Architecture: How We Do the Magic We Do

Apex code is stored as metadata, interpreted at runtime, and cached for scalability

Page 42: Understanding the Salesforce Architecture: How We Do the Magic We Do

§  Bulk DML

§  Email and messaging

§  Asynchronous processing (@future)

§  XmlStream / HTTP (RESTful) services classes

§  Declarative exposure as new Web Services

§  Platform Encryption

Apex is deeply integrated with platform features

Page 43: Understanding the Salesforce Architecture: How We Do the Magic We Do

Share Your Feedback, and Win a GoPro!

3 Earn a GoPro prize entry for each completed survey

Tap the bell to take a survey 2Enroll in a session 1

Page 44: Understanding the Salesforce Architecture: How We Do the Magic We Do