Selecting the Right Cloud Host
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,663
On Slideshare
2,659
From Embeds
4
Number of Embeds
2

Actions

Shares
Downloads
32
Comments
0
Likes
3

Embeds 4

http://www.linkedin.com 3
http://bitly.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • We worked with following priorities High: a) Scalability - especially on DB layer b) Easy maintenance as we do not want to keep an admin team /guy for server side c) Geographical fail-over - high availability Medium: a) Network latency  - we think about 500 ms is acceptable) Auto Scaling on app layer processing on application layer is less than DB. 2 large servers should be enough with buffer in computing power for load spikes c) Cost - while we want to be efficient but we do not want to optimize scaling too much so we loose grip on it But let's discuss!
  • Why Amazon-RDS is here: While we did not recommend Amazon RDS at first place, the idea was to discuss different options we studied for knowledge sharing reasons
  • Why Two Amazon EC2 Large Instances: a) Large instance comes with 7.5 G memory. The cheaper option is only a small instance with 1.7GB of memory and that is not recommended for enterprise Ruby to work b) 2 Large instances will suffice for spikes of load to us. Current production is an Extra Large instance. It holds DB and Ruby and so far have not reached 10% resource utilization till today. c) If DB is externalized, large instances will be good enough to handle Ruby with a cache mechanism enabled
  • We worked with following priorities High: a) Scalability - especially on DB layer i.e. performance and failover b) Easy maintenance as we do not want to keep an admin team /guy for server side c) Geographical fail-over - high availability d) Backups: e) Auto Scaling Medium: a) Network latency  - we think about 500 ms is acceptable) c) Master-Master: d) Multiple Read instances Low:- Provider Profile But let's discuss!
  • No Autoscaling on Ruby level here, why? We can look towards adding a third server launch based on auto-scale policies.    However  a) EC2 auto-scale launches an instance based on AMI. There is additional maintenance to keep an updated AMI as server code enhances over time. b) Sometimes (not often) instance launch based on AMI fails on EC2   Heroku provides failover in this case.

Transcript

  • 1. Selecting the Right Cloud Hosting for Your WebSite
  • 2. Agenda
      • Goal of server-side architecture exploration
      • Traditional single-write and multiple-read DB architecture
      • Cloud Approach
      • Comparison of cloud providers
      • Suggested Architecture
      • Cost
      • References
  • 3. Our Goal: Design a flexible and scalable architecture
  • 4. Option 1: Traditional Multiple App and DB Read Instances Auto Scaling Performance Fail-over Geographical  Fail-over Maintenance Cost and Set-up Backups Multiple Read Instances Self setup DB w/ multiple reads No High No No Very High Yes Yes
  • 5. Option 2: Cloud Approach and separate out App and DB layer
  • 6. Application Cloud Options Performance   Load Balancer Auto Scaling   Geographical  Fail-over Maintenance Cost and Set-up Provider Profile EC2 instances (recommend) High Yes Yes Yes (set one instance in East and West coast) Medium High Strong Heroku High Internal Handling No No Low BlueBox High Yes Yes No Low Low Internal Handling No No Low Medium
  • 7. Database Cloud Auto Scaling Performance Fail-over Geographical  Fail-over Maintenance Cost and Set-up Backups Master-Master Network Latency Multiple Reads Instances Provider Profile Amazon RDS (Cloud DB) No Medium-high Yes No High Yes but weekly down time No ~500ms per transaction Manual Strong XeRound (Cloud DB) Yes High Yes Yes Low Yes Yes ~500 ms per transaction Yes Medium Heruko No High Yes No Low Yes No Low No Medium Self setup DB w/ multiple reads No High No No High Yes Yes (limited to 2 instances) Not Recommended None Yes Strong  
  • 8. Suggested Architecture: Two (or more) Geographically spread EC2 instances for Application layer with Xeround for Database Layer
  • 9. More Reasons ..
    • Xeround Database
      • Non-dependent on EC2 (uses RackSpace and other cloud platforms as well alongside EC2)
      • Survived EC2 Ireland outage in Sep-2011
      • Automatic backups, scalability
      • ZERO scheduled outages
    •  
    • EC2 Hosted Application Layer
      • 2 load-balanced servers can take on *50+ tps load
      • Easy to add a new instance manually (in ~1 hour)
      • *Calculated based on detailed load testing
  • 10. Cost of this infrastructure
    • Some detailed cost estimations are present for a messaging system we delivered at the following link:
    • http://bit.ly/server_cost_est
  • 11. References
    • http://xeround.com/cloud-database-comparison/ec2-mysql/
    • http://www.williambharding.com/blog/rails/ec2-vs-heroku-vs-blue-box-group-for-rails-hosting/ 
    •  
    • http://heroku.com
    • http://aws.amazon.com/elasticloadbalancing/