Scalable Web Applications Session at Codebase
1 like866 views
The document discusses the advantages of using AWS for developing scalable web applications, highlighting case studies of companies like Reddit and Expedia that effectively utilized AWS services to manage high traffic and improve performance. It outlines key rules for scalable architecture, emphasizing the need for fast service requests, architecture simplification, and operational automation. Additionally, it presents various AWS tools and strategies, such as auto-scaling and Elastic Load Balancing, to enhance the efficiency and reliability of web applications.
Scalable Web Applications Session at Codebase
- 1. Scalable Web Applications on AWS Ian Massingham - Technical Evangelist 17 June 2014
- 2. A popular use-case for AWS services Applications with growing, variable or cyclical demand fit AWS well Exercise elasticity and automation to real advantage AWS services allow you to accelerate application development Scalable Web Applications
- 3. Why use AWS for scalable web applictions? Rule Book for scalable web application on AWS Common patterns for web applications Where to go next to learn more Agenda
- 4. Why AWS for scalable web applications?
- 5. What your users want… High & consistent performance Lots of new features all of the time Always on, accessible anywhere Personalized and rich applications
- 6. • reddit is a San Francisco, CA company that provides reddit.com, a social news and entertainment website where users can submit and rank ideas, images, and links • reddit originally operated reddit.com on physical servers, but after the number of users quadrupled in 18 months, the company realized it couldn’t scale with an on-premises environment • By migrating to AWS, reddit can scale to manage 4 billion page views per month and run its website with only 20 employees With AWS, reddit scales its social news site to handle 4 billion page views per month with only 20 employees Find out more here : aws.amazon.com/de/solutions/case-studies/reddit/
- 7. • One of the world's leading online travel companies, providing leisure and business travel to customers worldwide • Expedia needed a global infrastructure to support its commitment to create a great experience for customers worldwide • Using AWS, Expedia created a global infrastructure for its critical applications while reducing network latency to under 50 milliseconds and enabling a 230% CPU consumption efficiency for data processing Expedia Uses AWS to Run Critical, High Volume Applications on a Global Infrastructure Find out more here : aws.amazon.com/solutions/case-studies/expedia/
- 8. Not excess capacity! Startups on AWS Find out more at : aws.amazon.com/solutions/case-studies
- 9. Rule Book for Scalable Web Applications on AWS
- 10. Rule 2: Service requests as fast as possible Rule 1: Service all web requests Rule 3: Handle requests at any scale Rule 4: Simplify architecture with services Rule 5: Automate operational management Rule 6: Leverage unique cloud properties
- 11. DNS Application Data Rule 1: Service all web requests
- 12. DNS Application DataRequest Rule 1: Service all web requests
- 13. DNS Application DataRequest Rule 1: Service all web requests
- 14. DNS Application DataRequest …then this is irrelevant Clients can’t resolve you? Rule 1: Service all web requests
- 15. DNS Application DataRequest “100% Available” SLA Rule 1: Service all web requests Route53 Feature Details Global Supported from AWS global edge locations for fast and reliable domain name resolution Scalable Automatically scales based upon query volumes Latency based routing Supports resolution of endpoints based upon latency, enabling multi-region application delivery Integrated Integrates with other AWS services allowing Route 53 to front load balancers, S3 and EC2 Secure Integrates with IAM giving fine grained control over DNS record access http://aws.amazon.com/route53/sla
- 16. DNS Application DataRequest Rule 1: Service all web requests Route53
- 17. Region DNS Application DataRequest Rule 1: Service all web requests Elastic Load Balancer Region Availability Zone Availability Zone Availability Zone Availability Zone Route53 Elastic load balancing Multi-availability zone Multi-region
- 18. Region Rule 1: Service all web requests DNS Application DataRequest Elastic Load Balancer Region Availability Zone Availability Zone Availability Zone Availability Zone Route53
- 19. Region Rule 1: Service all web requests DNS Application DataRequest Elastic Load Balancer Route53 Region Availability Zone Availability Zone Availability Zone Availability Zone Multi-AZ RDS (Master- slave) Inter-region replication Read-replicas
- 20. Rule 2: Service requests as fast as possible Rule 1: Service all web requests Rule 3: Handle requests at any scale Rule 4: Simplify architecture with services Rule 5: Automate operational management Rule 6: Leverage unique cloud properties
- 21. Rule 2: Service requests as fast as possible
- 22. Rule 2: Service requests as fast as possible a) Choose the fastest route Region A Route53 Region B Request
- 23. Rule 2: Service requests as fast as possible a) Choose the fastest route Region A Route53 Region B 16ms 92ms Request
- 24. Rule 2: Service requests as fast as possible a) Choose the fastest route Region A Route53 Region B 16ms 92ms Request
- 25. Rule 2: Service requests as fast as possible Region A Route53 Region B 16ms Request Region A DNS entry a) Choose the fastest route
- 26. Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application servers London Paris NY Served from S3 /images/* 3 Served from EC2 *.php 2 Single CNAME www.mysite.com 1 CloudFront World-wide content distribution network Easily distribute content to end users with low latency, high data transfer speeds, and no commitments.
- 27. Without CloudFront EC2 webservers/app servers loaded by user requests Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application servers
- 28. With CloudFront Load of user requests pushed into CloudFront, EC2 cluster can scale down Offload Scale Down Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application servers
- 29. Rule 2: Service requests as fast as possible ResponseTime ServerLoad ResponseTime Server Load ResponseTime Server Load No CDN CDN for Static Content CDN for Static & Dynamic Content Offload Scale Down a) Choose the fastest route b) Offload your application servers
- 30. Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application servers c) Cache it if you can ElastiCache Memcached compatible caching layer Serve frequently requested & slow changing data from scalable cache clusters Reduce load on database and other servers
- 31. Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application servers c) Cache it if you can d) Single digit latencies where it matters Scale DatabaseQueryPerformance Desired consistency, predictability
- 32. Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application servers c) Cache it if you can d) Single digit latencies where it matters Scale DatabaseQueryPerformance Desired consistency, predictability Actual degraded performance with scale
- 33. Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application servers c) Cache it if you can d) Single digit latencies where it matters Scale DatabaseQueryPerformance Desired consistency, predictability Actual degraded performance with scale Management problems Data sharding Data caching Provisioning Cluster management Fault management
- 34. Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application servers c) Cache it if you can d) Single digit latencies where it matters Scale DatabaseQueryPerformance Dynamo DB Query Performance Relational Database Query Performance DynamoDB Low latency Large scale Zero admin Predictable performance
- 35. Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application servers c) Cache it if you can d) Single digit latencies where it matters Scale DatabaseQueryPerformance Dynamo DB Query Performance DynamoDB Low latency Large scale Zero admin Predictable performance Average single-digit milliseconds server side latencies Runs on solid state drives, and is built to maintain consistent, fast latencies at any scale
- 36. Rule 2: Service requests as fast as possible Rule 1: Service all web requests Rule 3: Handle requests at any scale Rule 4: Simplify architecture with services Rule 5: Automate operational management Rule 6: Leverage unique cloud properties
- 37. Rule 3: Handle requests at any scale a) Scale up Vertical Scaling From $0.02/hr Basic unit of compute capacity Range of CPU, memory & local disk options 14 Instance types available, from micro through cluster compute to SSD backed Scale up with Elastic Compute Cloud (EC2)
- 38. Rule 3: Handle requests at any scale a) Scale up b) Scale out Trigger auto-‐ scaling policy aws autoscaling create-‐auto-‐scaling-‐group -‐-‐auto-‐scaling-‐group-‐name MyGroup -‐-‐launch-‐configuration MyConfig -‐-‐load-‐balancer-‐name MyELB -‐-‐availability-‐zones eu-‐west-‐1a -‐-‐min-‐size 4 -‐-‐max-‐size 200 Auto-scaling Automatic re-sizing of compute clusters based upon demand
- 39. Manually Send an API call or use CLI to launch/ terminate instances – Only need to specify capacity change (+/-) By Schedule Scale up/down based on date and time a) Scale up b) Scale out By Policy Scale in response to changing conditions, based on user configured real-time monitoring and alerts Auto-Rebalance Instances are automatically launched/ terminated to ensure the application is balanced across multiple Azs Rule 3: Handle requests at any scale
- 40. Manually Send an API call or use CLI to launch/ terminate instances – Only need to specify capacity change (+/-) By Schedule Scale up/down based on date and time Preemptive manual scaling of capacity e.g. before a marketing event add 10 more instances Regular scaling up and down of instances e.g. scale from 0 to 2 to process SQS messages every night or double capacity on a Friday night a) Scale up b) Scale out By Policy Scale in response to changing conditions, based on user configured real-time monitoring and alerts Auto-Rebalance Instances are automatically launched/ terminated to ensure the application is balanced across multiple Azs Rule 3: Handle requests at any scale Dynamic scale based upon custom metrics e.g. SQS queue depth, Average CPU load, ELB latency Maintain capacity across availability zones e.g. Instance availability maintained in event of AZ becoming unavailable
- 41. Rule 3: Handle requests at any scale a) Scale up b) Scale out c) Dial it up Elastic Block Store Provisioned IOPS up to 1000 per EBS volume Predictable performance for demanding workloads such as databases DynamoDB Provisioned read/write performance per table Predictable high performance scaled via console or API
- 42. Rule 2: Service requests as fast as possible Rule 1: Service all web requests Rule 3: Handle requests at any scale Rule 4: Simplify architecture with services Rule 5: Automate operational management Rule 6: Leverage unique cloud properties
- 43. Your Business 70% On-Premise Infrastructure 30% Managing All of the “Undifferentiated Heavy Lifting” Rule 4: Simplify architecture with services
- 44. AWS Cloud-Based Infrastructure Your Business More Time to Focus on Your Business Configuring Your Cloud Assets 70% 30%70% On-Premise Infrastructure 30% Managing All of the “Undifferentiated Heavy Lifting” Rule 4: Simplify architecture with services
- 45. Relational Database Service Database-as-a-Service No need to install or manage database instances Scalable and fault tolerant configurations DynamoDB Provisioned throughput NoSQL database Fast, predictable performance Fully distributed, fault tolerant architecture Use RDS for databases Use DynamoDB for high performance key-value DB Rule 4: Simplify architecture with services
- 46. Amazon SQS Processing task/ processing trigger Processing results Amazon SQS Reliable, highly scalable, queue service for storing messages as they travel between instances Task A Task B (Auto-scaling) Task C 2 3 1 Simple Workflow Reliably coordinate processing steps across applications Integrate AWS and non-AWS resources Manage distributed state in complex systems Push inter-process workflows into the cloud with SWF Reliable message queuing without additional software Rule 4: Simplify architecture with services
- 47. Cloud Search Elastic search engine based upon Amazon A9 search engine Fully managed service with sophisticated feature set Scales automatically Document Server Results Search Server Don’t install search software, use CloudSearch Process large volumes of data cost effectively with EMR Elastic MapReduce Elastic Hadoop cluster Integrates with S3 & DynamoDB Leverage Hive & Pig analytics scripts Integrates with instance types such as spot Rule 4: Simplify architecture with services
- 48. Rule 2: Service requests as fast as possible Rule 1: Service all web requests Rule 3: Handle requests at any scale Rule 4: Simplify architecture with services Rule 5: Automate operational management Rule 6: Leverage unique cloud properties
- 49. Rule 5: Automate operational management a) Everything is programmable Compute Storage Security Scaling Database Networking Monitoring Messaging Workflow DNS Load Balancing BackupCDN Access everything via CLI, API or Console Achieve the highest levels of automation sophistication with ease Find out more at: aws.amazon.com/developers/getting-started/
- 50. Rule 5: Automate operational management a) Everything is programmable b) Think disposable, one click deployments Cloud Formation Automate creation of ‘stacks’ in a repeatable way Scripting framework for AWS resource creation Feature Details Platform support Support for AWS resources from EC2 to IAM Resource creation Creates AWS resources behind the scenes and reports on progress Declarative Specify stacks in JSON format and source control your environments Customizable Drive stack creation with paramaters
- 51. Rule 5: Automate operational management a) Everything is programmable b) Think disposable, one click deployments c) Design for failure, implement self healing Customize instance startup Get instances to ask ‘who am I?’ question on startup and be configured dynamically upon being answered Maintain capacity of instances Using a minimum pool size will maintain capacity in the event of instance failures Know what’s going on, take automated actions Use CloudWatch standard and custom metrics to create alarms. Respond with automated administration actions Bootstrapping Auto-scaling Cloud Watch
- 52. Rule 5: Automate operational management a) Everything is programmable b) Think disposable, one click deployments c) Design for failure, implement self healing
- 53. Rule 2: Service requests as fast as possible Rule 1: Service all web requests Rule 3: Handle requests at any scale Rule 4: Simplify architecture with services Rule 5: Automate operational management Rule 6: Leverage unique cloud properties
- 54. Rule 6: Leverage unique cloud properties a) Optimize costs with instance types EC2 Compute Units Memory(GB) 0.5 1 2 4 8 16 32 64 128 256 1 2 4 8 16 32 64 128 General'Purpose' Compute'Op1mized' GPU'Instances' Memory'Op1mized' Storage'Op1mized' t1.micro' t1.micro 613 MB Up to 2 ECUs (for short bursts) m1.small 1.7 GB, 1 EC2 Compute Unit 1 virtual core m1.medium 3.7 GB, 2 EC2 Compute Units 1 virtual core m1.large 7.5 GB 4 EC2 Compute Units 2 virtual cores m1.xlarge 15 GB 8 EC2 Compute Units 4 virtual cores m3.medium 3.7 GB, 3 EC2 Compute Units 1 virtual core m3.large 7.5 GB 6.5 EC2 Compute Units 2 virtual cores m3.xlarge 15 GB 13 EC2 Compute Units 4 virtual cores m3.2xlarge 30 GB 26 EC2 Compute Units 8 virtual cores
- 55. Rule 6: Leverage unique cloud properties a) Optimize costs with instance types EC2 Compute Units Memory(GB) 0.5 1 2 4 8 16 32 64 128 256 1 2 4 8 16 32 64 128 General'Purpose' Compute'Op1mized' GPU'Instances' Memory'Op1mized' Storage'Op1mized' t1.micro' t1.micro 613 MB Up to 2 ECUs (for short bursts) m1.small 1.7 GB, 1 EC2 Compute Unit 1 virtual core m1.medium 3.7 GB, 2 EC2 Compute Units 1 virtual core m1.large 7.5 GB 4 EC2 Compute Units 2 virtual cores m1.xlarge 15 GB 8 EC2 Compute Units 4 virtual cores m3.medium 3.7 GB, 3 EC2 Compute Units 1 virtual core m3.large 7.5 GB 6.5 EC2 Compute Units 2 virtual cores m3.xlarge 15 GB 13 EC2 Compute Units 4 virtual cores m3.2xlarge 30 GB 26 EC2 Compute Units 8 virtual cores EC2 Compute Units Memory(GB) 0.5 1 2 4 8 16 32 64 128 256 1 2 4 8 16 32 64 128 General'Purpose' Compute'Op1mized' GPU'Instances' Memory'Op1mized' Storage'Op1mized' t1.micro' m2.xlarge 17.1 GB 6.5 EC2 Compute Units 2 virtual cores m2.2xlarge 34.2 GB 13 EC2 Compute Units 4 virtual cores m2.4xlarge 68.4 GB 26 EC2 Compute Units 8 virtual cores cr1.8xlarge 244 GB 88 EC2 Compute Units 32 virtual cores c1.medium 1.7 GB 5 EC2 Compute Units 2 virtual cores c3.large 3.75 GB 7 EC2 Compute Units 2 virtual cores C3.xlarge 7.5 GB 14 EC2 Compute Units 4 virtual cores c1.xlarge 7 GB 20 EC2 Compute Units 8 virtual cores C3.2xlarge 15 GB 28 EC2 Compute Units 8 virtual cores C3.4xlarge 30GB 55 EC2 Compute Units 16 virtual cores C3.8xlarge 60GB 108 EC2 Compute Units 32 virtual cores Cc2.8xlarge 60.5GB 88 EC2 Compute Units 32 virtual cores
- 56. Unix/Linux instances start at $0.02/ hour Pay as you go for compute power Low cost and flexibility Pay only for what you use, no up-front commitments or long-term contracts Use Cases: Applications with short term, spiky, or unpredictable workloads; Application development or testing On-demand instances 1- or 3-year terms Pay low up-front fee, receive significant hourly discount Low Cost / Predictability Helps ensure compute capacity is available when needed Use Cases: Applications with steady state or predictable usage Applications that require reserved capacity, including disaster recovery Reserved instances Bid on unused EC2 capacity Spot Price based on supply/demand, determined automatically Cost / Large Scale, dynamic workload handling Use Cases: Applications with flexible start and end times Applications only feasible at very low compute prices Spot instances Rule 6: Leverage unique cloud properties a) Optimize costs with instance types
- 57. 0 1000 2000 3000 4000 5000 6000 7000 Reserved Instances On Demand Spot Rule 6: Leverage unique cloud properties a) Optimize costs with instance types
- 58. a) Optimize costs with instance types b) Get insight fast with Elastic MapReduce Rule 6: Leverage unique cloud properties Elastic MapReduce Managed, elastic Hadoop cluster Integrates with S3 & DynamoDB Leverage Hive & Pig analytics scripts Integrates with instance types such as spot Feature Details Scalable Use as many or as few compute instances running Hadoop as you want. Modify the number of instances while your job flow is running Integrated with other services Works seamlessly with S3 as origin and output. Integrates with DynamoDB Comprehensive Supports languages such as Hive and Pig for defining analytics, and allows complex definitions in Cascading, Java, Ruby, Perl, Python, PHP, R, or C++ Cost effective Works with Spot instance types Monitoring Monitor job flows from with the management console
- 59. a) Optimize costs with instance types b) Get insight fast with Elastic MapReduce Elastic MapReduce Code Name node Output S3 + SimpleDB S3 + DynamoDB Elastic cluster HDFS Queries + BI Via JDBC, Pig, Hive Input data Rule 6: Leverage unique cloud properties
- 60. Cluster compute instances Implement HVM process execution Intel® Xeon® E5-2670 processors 10 Gigabit Ethernet Cluster Compute 80 EC2 Compute Units 60GB RAM 3TB Local Disk Network placement groups Cluster instances deployed in a ‘Placement Group’ enjoy low latency, full bisection 10 Gbps bandwidth 10Gbps Rule 6: Leverage unique cloud properties a) Optimize costs with instance types b) Get insight fast with Elastic MapReduce c) Create a supercomputer backend when you need it
- 61. Rule 2: Service requests as fast as possible Rule 1: Service all web requests Rule 3: Handle requests at any scale Rule 4: Simplify architecture with services Rule 5: Automate operational management Rule 6: Leverage unique cloud properties
- 62. Common Patterns for Scalable Web Applications
- 64. Design your application for the AWS Cloud More details on the AWS Architecture Center at : aws.amazon.com/architecture
- 65. AWS Training & Certification Certification aws.amazon.com/certification Demonstrate your skills, knowledge, and expertise with the AWS platform Self-Paced Labs aws.amazon.com/training/ self-paced-labs Try products, gain new skills, and get hands-on practice working with AWS technologies aws.amazon.com/training Training Skill up and gain confidence to design, develop, deploy and manage your applications on AWS
- 66. Scalable Web Applications on AWS Ian Massingham - Technical Evangelist 17 June 2014
- 67. @AWS_UKI for local AWS events & news @AWScloud for Global AWS News and Announcements ©Amazon.com, Inc. and its affiliates. All rights reserved. #AWSRoadShow