How to Build Scalable Websites in the Cloud

2,147 views

Published on

RightScale Webinar: December 14, 2010 – In this webinar, we show you how to use the cloud to build websites that scale to meet demand.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,147
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
37
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

How to Build Scalable Websites in the Cloud

  1. 1. How to BuildScalable Web Applicationsin the CloudReference Architectures and Best PracticesDecember 14, 2010<br />
  2. 2. Your Panel Today<br />Presenting:<br /><ul><li>Michael Crandell, CEO
  3. 3. Brian Adler, Sr. Professional Services Architect</li></ul>Q&A:<br /><ul><li>JarrydHensel, Account Manager</li></ul>Please use the questions window to ask questions any time!<br />
  4. 4. Agenda<br /><ul><li>What’s, why’s, when’s, and how’s of scalable web apps
  5. 5. Comparison of traditional and cloud resource models
  6. 6. Reference architecture for a scalable web application
  7. 7. Best practices for each tier of the reference architecture
  8. 8. Summary & conclusions</li></ul>Please use the questions window to ask questions any time!<br />
  9. 9. Scalable Web Application<br />What?<br />An application built on an architecture that can adapt to changing conditions<br />
  10. 10. Scalable Web Application<br />What?<br />An application layered on an architecture that can adapt to changing conditions<br />Why?<br />Traffic and load patterns are unpredictable<br />Viral or flash-mob events can result in very dynamic conditions<br />Availability and Reliability<br />Application must be distributed to increase likelihood of end-user accessibility<br />Overprovision<br />Under-utilized resources == wasted $$$<br />Underprovision<br />Missed opportunities – users unable to access your site/product<br />Don’t be a victim of your own success<br />
  11. 11. Pre-Cloud Provisioning<br />
  12. 12. Cloud-enabled Provisioning<br />
  13. 13. Reference Architecture<br />
  14. 14. Load Balancing Tier<br />
  15. 15. Load Balancing<br />HAProxy + Apache<br />Can handle SSL termination on the load balancer<br />Connection statistics available via socket connection and status web page<br />Each instance can handle a specific amount of traffic with no ramp-up time<br />Each instance can only handle a specific amount of traffic<br />Addition of load balancers is possible, but requires DNS modifications<br />
  16. 16. Load Balancing<br />HAProxy + Apache<br />Can handle SSL termination on the load balancer<br />Connection statistics available via socket connection and status web page<br />Each instance can handle a specific amount of traffic with no ramp-up time<br />Each instance can only handle a specific amount of traffic<br />Addition of load balancers is possible, but requires DNS modifications<br />Elastic Load Balancer (ELB)<br />SSL termination is now supported<br />Can scale to handle large amounts of traffic, but can be slow to ramp-up<br />Options do exist for “pre-warming” the ELB<br />Only need one – it will scale to accommodate traffic load<br />Essentially a load balancing appliance<br />No visibility into inner-workings and/or connection rates, statistics, failures, etc.<br />(RightScale has a technical white paper on load balancing solutions that is available at www.RightScale.com/whitepapers)<br />
  17. 17. Load Balancing<br />Load Balancer + Application server<br />Possible, and good for test and dev<br />Not a best practice for a production environment<br />Traffic spikes can cause instance to perform both load balancing and application functions…poorly<br />
  18. 18. Load Balancing<br />Load Balancer + Application server<br />Possible, and good for test and dev<br />Not a best practice for a production environment<br />Traffic spikes can cause instance to perform both load balancing and application functions…poorly<br />Recommendation: Minimum of two load balancers<br />Each load balancer should be in a different availability zone (AZ) to increase reliability and availability<br />RightScale testing has shown that m1.large is a good choice for load balancers<br />Due to 100K-120K packet-per-second limit, larger instances do not provide much gain in throughput<br />Roughly 5K responses/second can be handled by m1.large<br />With the 5K threshold in mind, select the number of load balancers required to handle your peak traffic<br />
  19. 19. Application Server Tier<br />Puts the “scalable” in a scalable application<br />True autoscaling a must in any dynamic/unpredictable environment<br />
  20. 20. Application Server Tier<br />Autoscaling<br />Fully automated server launch based on autoscaling triggers<br />No manual intervention (can be challenging in certain environments, i.e. Windows)<br />Download and install application code from common repository to ensure identical configuration of all servers in the tier<br />
  21. 21. Application Server Tier<br />Autoscaling<br />Fully automated server launch based on autoscaling triggers<br />No manual intervention (can be challenging in certain environments, i.e. Windows)<br />Download and install application code from common repository to ensure identical configuration of all servers in the tier<br />Triggers<br />Common<br />CPU idle<br />Free memory<br />System load<br />Custom<br />Web server connections<br />Application-specific metrics<br />
  22. 22. Application Server Tier<br />When to scale?<br />Conservatively. Both up and down<br />
  23. 23. Application Server Tier<br />When to scale?<br />Conservatively. Both up and down<br />Up<br />Allow adequate lead time for new servers to become operational<br />Before system is negatively impacted<br />Look for trends in activity and react early<br />Worst that can happen: Charged for an extra instance hour<br />
  24. 24. Application Server Tier<br />When to scale?<br />Conservatively. Both up and down<br />Up<br />Allow adequate lead time for new servers to become operational<br />Before system is negatively impacted<br />Look for trends in activity and react early<br />Worst that can happen: Charged for an extra instance hour<br />Down<br />When system has been underutilized for a consistent, consecutive period of time<br />Scale down fewer servers than in a scale-up event<br />Again, only downside is an extra hour of instance charge<br />Better safe than sorry<br />
  25. 25. Application Server Tier<br />Array considerations<br />
  26. 26. Application Server Tier<br />Array considerations<br />Weight the array across all availability zones (not regions)<br />Increases reliability of application<br />NOTE: Traffic within an AZ on private IPs is free. Traffic between AZs incurs a per-gigabyte charge<br />Traffic between regions is charged at public Internet rates<br />
  27. 27. Application Server Tier<br />Array considerations<br />Weight the array across all availability zones (not regions)<br />Increases reliability of application<br />NOTE: Traffic within an AZ on private IPs is free. Traffic between AZs incurs a per-gigabyte charge<br />Traffic between regions is charged at public Internet rates<br />Set minimums and maximums appropriately<br />Minimum can assist in cost savings in times of low usage<br />Maximum can limit overall cost exposure<br />
  28. 28. Application Server Tier<br />Array considerations<br />Weight the array across all availability zones (not regions)<br />Increases reliability of application<br />NOTE: Traffic within an AZ on private IPs is free. Traffic between AZs incurs a per-gigabyte charge<br />Traffic between regions is charged at public Internet rates<br />Set minimums and maximums appropriately<br />Minimum can assist in cost savings in times of low usage<br />Maximum can limit overall cost exposure<br />Instance size<br />m1.large is typically a good choice for array-based servers in a production environment<br />m1.smalls (and even micro instances) can be used in test and development environments<br />Every application is different, so run load tests and benchmarks to find the optimal solution for your environment<br />
  29. 29. Application Server Tier<br />Array considerations<br />Weight the array across all availability zones (not regions)<br />Increases reliability of application<br />NOTE: Traffic within an AZ on private IPs is free. Traffic between AZs incurs a per-gigabyte charge<br />Traffic between regions is charged at public Internet rates<br />Set minimums and maximums appropriately<br />Minimum can assist in cost savings in times of low usage<br />Maximum can limit overall cost exposure<br />Instance size<br />m1.large is typically a good choice for array-based servers in a production environment<br />m1.smalls (and even micro instances) can be used in test and development environments<br />Every application is different, so run load tests and benchmarks to find the optimal solution for your environment<br />Code Deployment<br />Updated code can be pushed to all servers in an array via a single click of a button<br />
  30. 30. Caching Tier<br />Caching can dramatically decrease the load on the database<br />Particularly in read-intensive applications<br />Costs of caching<br />Application complexity/modification<br />Additional instance hours to support the cache<br />
  31. 31. Caching Tier<br />Best practice is to have a separate, dedicated caching tier<br />Caching can be implemented on each application server<br />Prevents the use of a distributed cache<br />Local cache should only be used by the co-resident application server<br />Application complexities<br />Database performance degradation<br />
  32. 32. Caching Tier<br />Best practice is to have a separate, dedicated caching tier<br />Caching can be implemented on each application server<br />Prevents the use of a distributed cache<br />Local cache should only be used by the co-resident application server<br />Application complexities<br />Database performance degradation<br />Instance Size and Count<br />Determine memory caching footprint<br />Select instance size and count that spreads the load over several servers<br />Prevents loss of entire cache if a single instance fails<br />Distribute caching servers across AZs for reliability<br />Overprovision if possible<br />Provide capacity for system to grow to fully utilize cache (budget permitting)<br />
  33. 33. Caching Tier<br />Best practice is to have a separate, dedicated caching tier<br />Caching can be implemented on each application server<br />Prevents the use of a distributed cache<br />Local cache should only be used by the co-resident application server<br />Application complexities<br />Database performance degradation<br />Instance Size and Count<br />Determine memory caching footprint<br />Select instance size and count that spreads the load over several servers<br />Prevents loss of entire cache if a single instance fails<br />Distribute caching servers across AZs for reliability<br />Overprovision if possible<br />Provide capacity for system to grow to fully utilize cache (budget permitting)<br />Manually scaling caching servers is possible but non-trivial<br />Involves application and database performance degradation<br />Time To Lives (TTLs)<br />Always set to expire<br />
  34. 34. Caching Tier<br />Write-intensive applications<br />Don’t see as large a performance gain as read-intensive apps<br />
  35. 35. Caching Tier<br />Write-intensive applications<br />Don’t see as large a performance gain as read-intensive apps<br />Third-party providers<br />Vendor solutions exist that allow dynamic memcached scaling<br />
  36. 36. Database Tier<br />Numerous database architecture options exist<br />No “one size fits all” solution, so testing and benchmarking are critical to determine proper configuration<br />
  37. 37. Database Tier<br />Masters and Slave(s)<br />Multiple Slaves if budget permits<br />Distribute Master and Slave(s) across AZs<br />Always use same instance size for Master and Slaves<br />
  38. 38. Database Tier<br />Masters and Slave(s)<br />Multiple Slaves if budget permits<br />Distribute Master and Slave(s) across AZs<br />Always use same instance size for Master and Slaves<br />Data Storage<br />EBS volumes for data store<br />Never use ephemeral storage for persistent data<br />Back up Master and Slaves frequently<br />Upload snapshots to S3 or some other persistent, redundant storage<br />
  39. 39. Database Tier<br />Masters and Slave(s)<br />Multiple Slaves if budget permits<br />Distribute Master and Slave(s) across AZs<br />Always use same instance size for Master and Slaves<br />Data Storage<br />EBS volumes for data store<br />Never use ephemeral storage for persistent data<br />Back up Master and Slaves frequently<br />Upload snapshots to S3 or some other persistent, redundant storage<br />Instance Size<br />Varies greatly based on the nature of the application and site traffic<br />Load testing and benchmarking can assist in identifying a reasonable initial size<br />
  40. 40. Database Tier<br />Relational Database Service (RDS)<br />Database Appliance<br />No access to instance (no visibility into CPU utilization, memory usage, slow-query logs, etc.)<br />Requires scheduled downtime<br />Announcement of multi-AZ functionality in May 2010 allows 24/7 operation<br />Read replicas announced in October 2010<br />
  41. 41. Database Scaling<br />
  42. 42. Database Scaling<br />Vertical<br />“Grow” or “shrink” a database server from one instance size to another<br />
  43. 43. Database Scaling<br />Vertical<br />“Grow” or “shrink” a database server from one instance size to another<br />Horizontal<br />Add additional servers to spread the database load<br />
  44. 44. Database Vertical/Horizontal Scaling<br />
  45. 45. Horizontal Database Scaling<br />Addition of read Slaves<br />Effective for read-intensive applications<br />Only writes need to access the master<br />Replication lag to slaves must be considered<br />
  46. 46. Horizontal Database Scaling<br />Addition of read Slaves<br />Effective for read-intensive applications<br />Only writes need to access the master<br />Replication lag to slaves must be considered<br />Effective mechanism is to use MySQL Proxy<br />
  47. 47. Horizontal Database Scaling<br />Sharding<br />Concept is to partition the database into distinct, non-overlapping pieces<br />“Horizontal slicing” of the database tables into groups of rows<br />Forethought required in setting up shards since cross-shard joins are resource intensive<br />
  48. 48. Horizontal Database Scaling<br />Before Sharding<br />
  49. 49. Horizontal Database Scaling<br />After Sharding<br />
  50. 50. Horizontal Database Scaling<br />Master-Master<br />Two (or more) Master DBs<br />Any Master can modify any database object<br />Replication lag can result in database inconsistencies<br />Poorly-designed applications can cause data object collisions and leave databases in indeterminate state<br />Not a recommended best practice, nor supported by RightScale<br />
  51. 51. Horizontal Database Scaling<br />NoSQL solutions<br />Many options exist – SimpleDB, Cassandra, Membase, CouchDB, MongoDB, Riak, etc.<br />Basically a Key/Value store<br />No complex operations between data objects (no relational operations)<br />Multiple nodes can be used to implement a distributed data store<br />Coordinated backup and recovery can be challenging<br />Some RightScale customers are beginning to use some NoSQL solutions in specific use cases.<br />
  52. 52. So What’s Best?<br />
  53. 53. So What’s Best?<br />As is typical in many technology discussions…<br />
  54. 54. So What’s Best?<br />As is typical in many technology discussions…<br />“It depends”<br />
  55. 55. So What’s Best?<br />As is typical in many technology discussions…<br />Many scalable environments share some common underlying architecture concepts<br />“It depends”<br />
  56. 56. So What’s Best?<br />As is typical in many technology discussions…<br />Many scalable environments share some common underlying architecture concepts<br />Every application is different. As such, there is no “one size fits all”<br />“It depends”<br />
  57. 57. So What’s Best?<br />As is typical in many technology discussions…<br />Many scalable environments share some common underlying architecture concepts<br />Every application is different. As such, there is no “one size fits all”<br />But…<br />“It depends”<br />
  58. 58. Mix-n-Match Pre-Built Components<br />
  59. 59. Q&A / Getting Started<br />Have a project, but need some help?<br />Contact us: sales@rightscale.com or (866) 720-0208<br />Ready to get started? <br />Sign up for our Free Edition:www.RightScale.com/Free<br />Call us for a VIP trial of our paid editions<br />Need to learn more?<br />Scalable Web Apps white paper – Coming Soon!<br />TCO calculator:www.RightScale.com/tco-calculator<br /> Webinar archive: www.RightScale.com/webinars<br /> White papers: www.RightScale.com/whitepapers<br />
  60. 60. Thank You!<br />

×