5. Timeline
April 2006 -- S3 for logos
September 2007 -- S3 for thumbnails
November 2008 -- EC2 for batch processing
May 2009 -- EC2 for entire site
http://www.revolutioncloud.com
6. What led us to AWS
(part 1)
• Needed an easy way to distribute and
upload our logo
http://www.revolutioncloud.com
8. What led us to AWS
(part 2)
• Thumbnails!
http://www.revolutioncloud.com
9. What led us to AWS
(part 3)
• Didn’t want to rent another cabinet
http://www.revolutioncloud.com
10. What led us to AWS
(part 3)
• Didn’t want to rent another cabinet
• Didn’t want to buy more servers
http://www.revolutioncloud.com
11. What led us to AWS
(part 3)
• Didn’t want to rent another cabinet
• Didn’t want to buy more servers
New Servers
New Servers
http://www.revolutioncloud.com
12. Imaging and Racking Servers Is
A (Sometimes Fun) Chore
http://www.revolutioncloud.com
13. EC2 for Overflow
• Used openvpn to create a secure link to
our datacenter for batch processing
http://www.revolutioncloud.com
14. Moving to EC2
• Started by migrating all data
http://www.revolutioncloud.com
15. Moving to EC2
• Started by migrating all data
• Got a complete stack running on EC2
http://www.revolutioncloud.com
16. Moving to EC2
• Started by migrating all data
• Got a complete stack running on EC2
• Long Saturday night finishing the migration
and “forklifting” the last bits of data
http://www.revolutioncloud.com
18. Stats
• 190 Virtual CPUs
• 338GB of RAM
• 9TB of Elastic Block Storage
• 2TB of S3 Storage
• 6.5 TB of Data Out / mo
• 2TB of Data In / mo
• 150M+ Pageviews and just one sysadmin!
http://www.revolutioncloud.com
19. Benefits
Data Center (per month) EC2 (per month)
Servers: $6K Servers: $13K
Cabinet (x3): $15K Storage: $1.5K
Bandwidth: $2.5K Bandwidth: $1.1K
Support: N/A Support: $1.2K
Total: $23.5K Total: $16.8K
29% Cheaper!
Based on Amazon public pricing, reddit open source
Estimated Pricing code, and public configuration information
http://www.revolutioncloud.com
21. Benefits
• Don’t have to procure servers anymore
• No racking or imaging servers anymore
http://www.revolutioncloud.com
22. Benefits
• Don’t have to procure servers anymore
• No racking or imaging servers anymore
• Time to market is faster
http://www.revolutioncloud.com
23. Benefits
• Don’t have to procure servers anymore
• No racking or imaging servers anymore
• Time to market is faster
• Multiple physical locations with AZs
http://www.revolutioncloud.com
24. Benefits
• Don’t have to procure servers anymore
• No racking or imaging servers anymore
• Time to market is faster
• Multiple physical locations with AZs
• Get “free” upgrades
http://www.revolutioncloud.com
25. Benefits
• Don’t have to procure servers anymore
• No racking or imaging servers anymore
• Time to market is faster
• Multiple physical locations with AZs
• Get “free” upgrades
• Elasticity!
http://www.revolutioncloud.com
29. Pain Points
EBS sometimes slows down a bit
Workaround: Use caching and replication
with read slaves to avoid relying on a single
disk.
http://www.revolutioncloud.com
30. Pain Points
Instances go away sometimes
Workaround: Avoid single points of failure
and make sure your servers have automated
configuration.
http://www.revolutioncloud.com
31. Pain Points
Fixing these issues made
our app more reliable and
highly available. We are
better off than when we
started.
http://www.revolutioncloud.com
32. Best Practices
• Keep data in multiple Availability Zones
http://www.revolutioncloud.com
33. Best Practices
• Keep data in multiple Availability Zones
• EBS for all persistent data
http://www.revolutioncloud.com
34. Best Practices
• Keep data in multiple Availability Zones
• EBS for all persistent data
• Snapshots
http://www.revolutioncloud.com
35. Best Practices
• Keep data in multiple Availability Zones
• EBS for all persistent data
• Snapshots
• No secret keys on the instance
http://www.revolutioncloud.com
36. Best Practices
• Keep data in multiple Availability Zones
• EBS for all persistent data
• Snapshots
• No secret keys on the instance
• Different functions in different Security
Groups
http://www.revolutioncloud.com
37. Best Practices
• A full stack in each zone
http://www.revolutioncloud.com
38. Best Practices
• A full stack in each zone
• All data stored as key-value pairs
http://www.revolutioncloud.com
39. Best Practices
• A full stack in each zone
• All data stored as key-value pairs
• More use of queues
http://www.revolutioncloud.com
41. Conclusion
• AWS saves us a lot of money
• AWS gives us a lot of flexibility
http://www.revolutioncloud.com
42. Conclusion
• AWS saves us a lot of money
• AWS gives us a lot of flexibility
• Moving to AWS has forced us to build
better applications and follow better IT
practices.
http://www.revolutioncloud.com
43. Conclusion
• AWS saves us a lot of money
• AWS gives us a lot of flexibility
• Moving to AWS has forced us to build
better applications and follow better IT
practices.
• http://code.reddit.com
http://www.revolutioncloud.com
community where people come together
share and discuss interesting things on the internet
such as links to other stuff or their own content.
reddit is a subsidiary of Conde Nast.
They are a multi-billion doallar media conglomorate that owns
TV, newspapers, and
some of the biggest brand names in publishing,
such as Vogue, GQ, etc
They also have a lot of webistes (other than reddit).
currently doing an EC2 proof of concept with
Vogue UK
and wired.com is also using EC2 for some of their site functionality.
But reddit is by far the biggest user of EC2 in Conde Nast.
Been AWS user since almost the begining
When we started, we had a custom logo almost every day.
Unfortunately, allowing the designer SVN access was untenable.
So we signed up for S3, and everything was great!
Now have over 20 million items in a single s3 bucket.
This is a graph of actual costs vs. what we could have spent on EC2.
you can see the spike every time we had to get
a new cabinet full of servers
So we had to make a decision
This was before Amazon offered the Virtual Private Cloud service.
Ran like this for about 7 months, slowing adding new machines as necessary.
This went so well we decided to move our whole site to EC2
started by migrating all the data that could be done ahead of time
set up replication to keep the data up to date
multiple zones
beta/staging is elastic
app servers are elastic
What our datacenter would have cost
vs.
what we pay now
29% cheaper!
Time to market is faster
because I no longer have to wait for servers
or set them up.
i can get capacity when i need it
As Amazon upgrades their hardware, I can move up to better stuff.
Don’t have to pay for capacity we don’t need.
I can shut down servers at night, or if a product doesn’t take off
But moving to EC2 wasn’t all roses
Virtualized hardware just doesn’t get sub-millisecond response times.
We had to rethink how we used memcached,
making less calls for more data at a time
Due to the redundant and network based nature,
sometimes the underlying drive has to remirror
or the network may be momentarily unavailable.
This can be avoided by having read slaves and caching
It forced me to add read slaves I should have had anyway
It is a new paradigm you have to get used to.
Ideally the machine can be told to boot and
then be ready with no user intervention.
I can’t stress this enough.
Eric Hammond’s runurl to trigger a push
of the keys to only authorized hosts.
get a whole application stack in at least 2 zones
aka. nosql.
We’re mostly there, just a few more bits
A more functional style of programming
is generally more reliable in exchange for
eventual consistancy
We are open source, so go to
code.reddit.com to see our source.
This the website of our book
which we hope to start filling with lots
of useful stuff soon.
stay tuned.
thank you.