Building Web Scale Applications with AWS

2,808 views
2,498 views

Published on

AWS provides a platform that is ideally suited for deploying highly available and reliable systems that can scale with a minimal amount of human interaction.  This talk describes a set of architectural patterns that support highly available services that are also scalable, low cost, low latency and allow for agile  development practices.   We walk through the various architectural decisions taken for each tier and explain our choices for appropriate AWS services and building blocks to ensure the security, scale, availability and reliability of the application.

Published in: Technology, News & Politics

Building Web Scale Applications with AWS

  1. 1. Building Web-Scale Applications with AWS Dan Cuddeford and Matthew Trescot Enterprise Solutions Architect and Solutions Architect
  2. 2. I am Barack Obama, Ask me anythingReddit Needed to Scale for a special guest • 2,987,307 pageviews on the day of the IAmA • President Obama’s user page received 428,004 pageviews on the day of the IAMA • Added 60 dedicated instance to handle the increased load • At peek transfering 48 MB/s to the internet
  3. 3. While You Scale• Architect for Failure • Architect with Security – Failures do happen – Security must happen
  4. 4. Why Is Scale Important? AWS Actual demand Actual demand Customer Dissatisfaction SelfHosting Waste Predicted Demand Rigid Elastic
  5. 5. Regions and StorageWhere and What
  6. 6. Regions US-WEST (Oregon) EU-WEST (Ireland) AWS GovCloud (US) ASIA PAC (Tokyo) US-EAST (Virginia) ASIA PAC (Sydney)US-WEST (N. California) SOUTH AMERICA (Sao Paulo) ASIA PAC (Singapore)
  7. 7. Availability Zones US-WEST (Oregon)) EU-WEST (Ireland) AWS GovCloud (US) ASIA PAC (Tokyo) US-EAST (Virginia) ASIA PAC (Sydney)US-WEST (N. California) SOUTH AMERICA (Sao Paulo) ASIA PAC (Singapore)
  8. 8. Storage TypesEphemeral Storage Elastic Block Storage• (Almost) every instance has them • 1GB to 1TB• Fast • Snapshot-able• Cheap • You choose the IOPS• Volatile • Good for random IO
  9. 9. Storage TypesS3 Glacier• (Almost) infinitely durable • (Almost) infinitely durable• Infinitely scalable • Infinitely scalable• CloudFront integration • Cheapest
  10. 10. Storage TypesDatabase SQS• Readily queryable • Logic built-in• Consistency/performance options • Infinitely scalable • Good for small blobs and write/read once
  11. 11. Application ScalingWide and Proud
  12. 12. Loose coupling sets you free!• The looser theyre coupled, the bigger they scale – Independent components – Design everything as a black box – Decouple interactions – Load-balance clustersUse Amazon SQS as Buffers Tight Coupling Controller A Controller B Controller C Q Q Q Loose Coupling Controller A Controller B Controller C
  13. 13. Allows for Parallel Processing and Failure• Fan out• Use varied instance types• Use varied billing models
  14. 14. Allows for Parallel Processing and Failure
  15. 15. Lets you Auto Scale Trigger auto- scaling policyas-create-auto-scaling-group MyGroup --launch-configuration MyConfig --availability-zones eu-west-1a --min-size 4 --max-size 200 Auto Scaling Automatic resizing of compute clusters based on demand Feature Details Control Define minimum and maximum instance pool sizes and when scaling and cool down occurs. Integrated to Amazon Use metrics gathered by CloudWatch to drive CloudWatch scaling. Instance types Run Auto Scaling for On-Demand and Spot Instances. Compatible with VPC.
  16. 16. …and Spread the LoadElastic Load Balancing• Create highly scalable applications• Distribute load across EC2 instances in multiple availability zones Feature Details Available Load balance across instances in multiple Availability Zones Health checks Automatically checks health of instances and takes them in or out of service Session stickiness Route requests to the same instance Secure sockets layer Supports SSL offload from web and application servers with flexible cipher support Monitoring Publishes metrics to CloudWatch
  17. 17. But usually some state has to reside somewhere Cookies in browser Session database Memory-resident session manager Framework-provided session handler
  18. 18. So this store of state needs to be… Performant Scalable Reliable
  19. 19. Where should session state reside? Trigger auto- scaling policy Not HereHere Session State State must reside OUTSIDE the scope of the elements you Service wish to scale
  20. 20. And what do I build it on?The state service itself mustbe well architected
  21. 21. IAM Temporary Security Credentials • Use Cases  Identity Federation to AWS APIs  Mobile and browser-based applications  Consumer applications with unlimited users • Scales to millions of users – No need to create an IAM identity for every user
  22. 22. The IAM Hierarchy of Permissions Permissions Example Unrestricted access to all enabled Action: * AWS Account services and resources Effect: Allow Credentials Resource: * (implicit) Access restricted by Group and Action: [‘s3:*’, ‘sts:Get*’] Effect: Allow IAM User User policies Resource: * Temporary Access restricted by generating Action: [ ‘s3:Get*’ ] Security Effect: Allow identity and further by policies Resource: Credentials used to generate token ‘arn:aws:s3:::userbucket/*’
  23. 23. AWS Application Management Solutions Higher-level Services Do it yourself Elastic Beanstalk OpsWorks CloudFormation EC2Convenience Control
  24. 24. Data Tier ScalingThe bane of the Architect’s existence
  25. 25. Vertical Scaling“We’re gonna need a bigger box”• Simplest approach• Can now leverage PIOPs• High I/O instances• Easy to change instance sizes• Will hit an endpoint eventually hi1.4xlarge m2.4xlarge m1.small
  26. 26. Master/Slave Horizontal Scaling • Reasonably simple to adapt to • Can now leverage PIOPs • Easy to change instances sizes • Will hit an endpoint eventually
  27. 27. • More complex at the application layerSharded Horizontal Scaling • ORM support can help • No practical limit on scalability • Operation complexity/sophistication • Shard by function or key space D A • RDBMS or NoSQL Hash Ring C B
  28. 28. Horizontal Scaling – Fully ManagedDynamoDB Feature Details• Provisioned throughput NoSQL database Provisioned Dial up or down provisioned read/write• Fast, predictable performance throughput capacity.• Fully distributed, fault tolerant architecture Predictable Average single digit millisecond latencies• Considerations for non-uniform data performance from SSD-backed infrastructure. Strong consistency Be sure you are reading the most up to date values. Fault tolerant Data replicated across Availability Zones. Monitoring Integrated to CloudWatch. Secure Integrates with AWS Identity and Access Management (IAM). Elastic Integrates with Elastic MapReduce for MapReduce complex analytics on large datasets.
  29. 29. Petabyte-Scale Data Warehousing Feature Details Optimized for Redshift uses a variety of innovations to Data obtain very high query performance on Warehousing datasets ranging in size from hundreds of gigabytes to a petabyte or more. Scalable Easily scale the number of nodes in your data warehouse up or down as your performance or capacity needs change Fault tolerant Data replicated across Availability Zones. Monitoring Integrated to CloudWatch. Secure Encrypt data in transit and at rest. Can also be run in VPC to isolate your data warehouse cluster. S3 intergration Loads data in parallel to each node from S3. Elastic Integrates with ERM via Data Pipeline. MapReduce
  30. 30. Summary• Use these techniques (and many, many others) situationally• Awareness of the options is the first step to good design• Scaling is the ability to move the bottlenecks around to the least expensive part of the architecture• AWS makes this easier – so your application is not a victim of its own success

×