Ryan Horn, Lead Software Engineer at Twilio. November 12, 2014 Las Vegas. BDT312 Using the Cloud to Scale from a Database to a Data Platform

Size: px

Start display at page:

Download "Ryan Horn, Lead Software Engineer at Twilio. November 12, 2014 Las Vegas. BDT312 Using the Cloud to Scale from a Database to a Data Platform"

Thomasine Weaver
8 years ago
Views:

1 BDT312 Using the Cloud to Scale from a Database to a Data Platform Ryan Horn, Lead Software Engineer at Twilio November 12, 2014 Las Vegas 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.

com, Inc. and its affiliates. All rights reserved.

2 Hi, I m Ryan Tech Lead of the User Data team at Twilio

3 What is Twilio? We provide a communications API that enables phones, VoIP, and messaging to be embedded into web, desktop and mobile software.

4 How Does it Work? A user calls your number Twilio receives the call Your app responds

5 What is the User Data Team? We scale Twilio's backend database infrastructure We build customer facing data APIs We manage data policies and data security at rest

6 Databases at Twilio

7 Calls and Messages are Stateful Queued Queued Ringing Sending In Progress Sent Completed Delivered

8 In the Beginning All data was placed in the same physical database regardless of where the call or message was in its lifecycle.

9 The Monolithic Database Model API Carriers Web MySQL Call/Message Service Billing

10 Problems at Scale Many consumers of data Data with different performance characteristics Failure in the database degrades many services Horizontal scaling and orchestration is complicated

11 Moving to a Service-Oriented Architecture

12 What is a Service-Oriented Architecture? An architecture in which required system behavior is decomposed into discrete units of functionality, implemented as individual services for applications to compose and consume.

decomposed into discrete units of functionality,

13 Communicate Through Interfaces, Not Databases Carriers API Call/Message Service Web In Flight Service In Flight MySQL Billing Post Flight Service Post Flight MySQL

14 Database Can Change Without Changing Every Service Carriers API Call/Message Service Web In Flight Service In Flight MySQL Billing Post Flight Service Post Flight Amazon DynamoDB

15 SOA Doesn t Solve Everything No matter how many services you put in front of MySQL, it s still a single point of failure.

16 Sharding MySQL

17 Implementing Sharding (the easy part) 1. Choose partitioning scheme 2. Implement routing logic 3. Send application queries through router 4. Go!

18 Sharding at Twilio Shard Application Router Shard1 6-9 Shard2

19 Rolling it Out With Zero Downtime (the hard part) We provide a 24/7, always on service Communications is intolerant of inconsistency and latency There is no maintenance window

20 Bringing Up a New Shard Master1 0-9 Application Slave1 Master2 Slave2

21 Split Odds and Evens for Writes Master1 Odds 0-9 Application Slave1 Master2 Evens Slave2

22 Update Routing Master1 Odds 0-4 Application 5-9 Slave1 Master2 Evens Slave2

23 Cut Slave Link Master1 0-4 Application 5-9 Slave1 Master2 Slave2

24 New Solutions, New Problems

25 A Necessary Burden In the beginning, the burden of managing our own databases was non-negotiable.

26 The Landscape has Changed We now have a variety of managed database services which solve these problems for us, such as Amazon RDS, Amazon DynamoDB, Amazon SimpleDB, Amazon Redshift, etc.

27 Cost Is Never Optimized Application developers do not (and should not) optimize for database cost.

28 Self Managed Databases are Costly Everything Else 22% Databases 78% Source: Twilio Data Usage

29 Keeping up With Growth As growth continues to accelerate, we need to somehow keep up.

30 A Change in Approach Change our hiring practices and bring in specialists Remove the context switching

31 Focusing on What We Do Well

32 Adopting Amazon DynamoDB

33 Thinking in Terms of Throughput Amazon DynamoDB allows us to scale in terms of throughput, not machines. This is the future of resource provisioning.

34 Operations Management and scaling of our cluster is fully abstracted away from us.

35 Cost Compared to MySQL Amazon DynamoDB 18% MySQL 82% Source: Twilio Data Usage

36 Cost with MySQL Fully Replaced Databases 39% Everything Else 61% Source: Twilio Data Usage

37 A Relational Model with Amazon DynamoDB Many of our services allow for querying data in a way that maps naturally to a relational database.

38 GET /Accounts/2/Events SELECT * FROM events ORDER BY date DESC;

39 SELECT * FROM events WHERE IpAddress= ORDER BY date DESC;

40 GET /Accounts/2/Events?IpAddress= &Date<= SELECT * FROM events WHERE IpAddress= AND Date<= ORDER BY date DESC;

41 GET /Accounts/2/Events AccountId=2, ScanIndexForward=false AccountId (Hash) Date (Range) IpAddress_Date Type call message

42 GET /Accounts/2/Events?IpAddress= AccountId=2, IpAddress_Date begins with , ScanIndexForward=false AccountId (Hash) IpAddress_Date (Range) Date call Type message

43 GET /Accounts/2/Events?IpAddress= &Date<= AccountId=2, IpAddress_Date LT , ScanIndexForward=false AccountId (Hash) IpAddress_Date (Range) Date call Type message

44 Need to Handle Exceeded Throughput Failures Exceeding provisioned throughput is a runtime error.

45 Handling Exceeded Write Throughput with Amazon SQS Queuing events to Amazon SQS processing asynchronously allows us to gracefully deal with write throughput errors.

46 API Web Amazon SQS Events Processor Amazon DynamoDB Billing

47 Maximum of 5 Global and 5 Local Indexes You can manage your own indexes, but your application must then handle partial mutation failures.

48 Local Index Size Limits Local secondary indexes provide immediate consistency and limit the data set for a given hash key to 10GB.

49 Data Warehouse

50 Brief History All business intelligence queries run on replicas of MySQL clusters serving production traffic.

51 Brief History Data pushed to Amazon S3 and queried with Pig, Amazon EMR, improving ability to aggregate, but with high latency.

52 Brief History Present Move to Amazon Redshift cut the time these reports took from hours to seconds allowing us to answer critical BI and financial questions in near real time.

53 Pushing Data Into Amazon Redshift SQS (DLQ) S3 Warehouse Loader Amazon Redshift Post Flight Service Kafka Amazon S3 Loader

54 Wrapping Up

55 Managed Services as a Culture Our focus is on creating an experience that unifies and simplifies communications is a reflection on our adoption of managed services.

56 Managed Services as a Culture Understanding and focusing on our areas of expertise and leveraging managed services for the rest accelerates the delivery of value and innovation to our customers.

57 Thank You!

Database Scalability {Patterns} / Robert Treat

Database Scalability {Patterns} / Robert Treat robert treat omniti postgres oracle - mysql mssql - sqlite - nosql What are Database Scalability Patterns? Part Design Patterns Part Application Life-Cycle