Scaling highly available database infrastructure to 100x, 1000x, and beyond has historically been one of the hardest technical challenges that any successful web business must face. This is quickly changing with fully-managed database services such as Amazon DynamoDB and Amazon Redshift, as the scaling efforts which previously required herculean effort are now as simple as an API call. Over the last few years, Twilio has evolved their database infrastructure to a pipeline consisting of Amazon SQS, Sharded MySQL, Amazon DynamoDB, Amazon S3, Amazon EMR and Amazon Redshift. In this session, Twilio cover show they achieved success, specifically: - How they replaced their data pipeline deployed to Amazon EC2 to meet their scaling needs with zero downtime. - How they adopted Amazon DynamoDB and Amazon Redshift at the same scale as their MySQL infrastructure, at 1/5th the cost and operational overhead. - Why they believe adopting managed database services like Amazon DynamoDB is key to accelerating delivery of value to their customers. Sponsored by Twilio.

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

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'sbackend 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
Ringing
In Progress
Completed
Queued
Sending
Sent
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
Web
Billing
MySQL
Call/Message Service
Carriers

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.

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

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

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. ShardingMySQL

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
Application
Router
Shard1
Shard2
Shard0
0-3
3-6
6-9

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

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

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

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

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

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: TwilioData 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. AdoptingAmazon DynamoDB

33. Thinking in Terms of Throughput
Amazon DynamoDBallows 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
MySQL 82%
Amazon DynamoDB 18%
Source: TwilioData Usage

36. Cost with MySQL Fully Replaced
Everything Else 61%
Databases 39%
Source: TwilioData 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=“5.6.7.8” ORDER BY date DESC;

40. SELECT * FROM events WHERE IpAddress=“5.6.7.8” AND Date<=“2014-10-03” ORDER BY date DESC;
GET /Accounts/2/Events?IpAddress=5.6.7.8&Date<=2014-10-03

41. AccountId (Hash)
Date (Range)
IpAddress_Date
Type
2
2014-10-03
5.6.7.8|2014-10-03
call
2
2014-10-01
5.6.7.8|2014-10-01
message
GET /Accounts/2/Events
AccountId=2, ScanIndexForward=false

42. AccountId (Hash)
IpAddress_Date (Range)
Date
Type
2
5.6.7.8|2014-10-03
2014-10-03
call
2
5.6.7.8|2014-10-01
2014-10-01
message
GET /Accounts/2/Events?IpAddress=5.6.7.8
AccountId=2, IpAddress_Date begins with “5.6.7.8|”, ScanIndexForward=false

43. AccountId (Hash)
IpAddress_Date (Range)
Date
Type
2
5.6.7.8|2014-10-03
2014-10-03
call
2
5.6.7.8|2014-10-01
2014-10-01
message
GET /Accounts/2/Events?IpAddress=5.6.7.8&Date<=2014-10-03
AccountId=2, IpAddress_DateLT “5.6.7.8|2014-10-03”, ScanIndexForward=false

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
Billing
Amazon SQS
Events Processor
Amazon DynamoDB

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
2008 -2011
All business intelligence queries run on replicas of MySQL clusters servingproduction traffic.

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

52. Brief History
2013 -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
Post Flight Service
Kafka
SQS (DLQ)
Amazon S3 Loader
S3
Warehouse Loader
Amazon Redshift

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!

58. http://bit.ly/awsevals