Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Scaling on AWS for the First 10 Million Users

Cloud computing gives you a number of advantages, such as being able to scale your application on demand. As a new business looking to use the cloud, you inevitably ask yourself, "Where do I start?" Join us in this session to understand best practices for scaling your resources from zero to millions of users. We will show you how to best combine different AWS services, make smarter decisions for architecting your application, and best practices for scaling your infrastructure in the cloud.

2.
Scaling on AWS for the First 10 Million Users
• Me:
– Chris Munns – munns@amazon.com
• YOU: Here to learn more about scaling
infrastructure on AWS
• TODAY: about best practices and things to think
about when building for large scale

20.
Day One, User One:
• We could potentially get
to a few hundred to a few
thousand depending on
application complexity
and traffic
• No failover
• No redundancy
• Too many eggs in one
basket
EC2
Instance
Elastic IP
Amazon
Route 53
User

21.
Day One, User One:
• We could potentially get
to a few hundred to a few
thousand depending on
application complexity
and traffic
• No failover
• No redundancy
• Too many eggs in one
basket
EC2
Instance
Elastic IP
Amazon
Route 53
User

27.
Why start with SQL?
• Established and well worn technology
• Lots of existing code, communities, books, background,
tools, etc
• You aren’t going to break SQL DBs in your first 10 million
users. No really, you won’t*
• Clear patterns to scalability
*Unless you are doing something SUPER weird with the data or
MASSIVE amounts of it, even then SQL will have a place in your stack

43.
Amazon ElastiCache
• Hosted Memcached & Redis
– Speaks same API as traditional open source
Memcached and Redis
• Scale from one to many nodes
• Self healing ( replaces dead instance )
• Very fast ( single digit ms speeds usually (or less) )
• Local to a single AZ for Memcache, with no persistence or
replication
• With Redis can put a replica in a different AZ with
persistence
• Use AWS’s Auto Discovery client to simplify clusters
growing and shrinking without affecting your application

58.
Host Based Configuration Management
Two big players:
– Chef
– PuppetLabs Puppet
• Both do more or less the same thing
• Both have syntax that isn’t too dissimilar
• Use HBCM along side one of the tools from the previous
slide
• Spend the time required to learn them
• Can’t scale easily without HBCM
• Growing in popularity: Salt, Ansible

59.
User >500k+:
You’ll potentially start to run into issues with speed and
performance of your applications.
• Make sure you have monitoring/metrics/logging in place
– If you can’t build it internally, outsource it! ( 3rd party SaaS )
• Pay attention to what customers are saying works well vs.
what doesn’t, use this direction
• Try to work on squeezing as much performance out of each
service/component

65.
SOA’ing
Move services into their own
tiers/modules. Treat each of these
as 100% whole-y separate pieces
of your infrastructure and scale
them independently.
Amazon.com and AWS do this
extensively! It offers flexibility and
greater understanding of each
component.

73.
User >5mil – 10mil:
You’ll potentially start to run into issues with your database
around contention on the write master.
How can you solve it?
• Federation ~ splitting into multiple DBs based on function
• Sharding ~ splitting one data set up across multiple hosts
• Moving some functionality to other types of DBs ( NoSQL )

74.
Database Federation
• Split up Databases by
function/purpose
• Harder to do cross function
queries
• Essentially delaying the need
for something like
sharding/NoSQL until much
further down the line
• Won’t help with single huge
functions/tables
ForumsDB
UsersDB
ProductsDB

79.
A Quick Review
• Make sure you have good
metrics/monitoring/logging tools in place
• Split tiers into individual services ( SOA )
• Use Auto Scaling once you’re ready for it
• Don’t reinvent the wheel
• Move to NoSQL if/when it makes sense

80.
Putting all this together
means we should now
easily be able to handle
10+ million users!