AWS for Start-ups - Architectural Best Practices & Automating Your Infrastructure
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

AWS for Start-ups - Architectural Best Practices & Automating Your Infrastructure

on

  • 2,540 views

Getting started with Amazon Web Services (AWS) is fast and simple. This presentation outlines best practice guidance from the Amazon Web Services team. ...

Getting started with Amazon Web Services (AWS) is fast and simple. This presentation outlines best practice guidance from the Amazon Web Services team.

By Ryan Shuttleworth, AWS Technical Evangelist

Statistics

Views

Total Views
2,540
Views on SlideShare
2,516
Embed Views
24

Actions

Likes
10
Downloads
112
Comments
0

2 Embeds 24

http://lab4109.blogspot.kr 20
http://lab4109.blogspot.com 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

AWS for Start-ups - Architectural Best Practices & Automating Your Infrastructure Presentation Transcript

  • 1. Architectural Best practices &Automating your Infrastructure
  • 2. Architectural Best practices &Automating your InfrastructureRules for ‘just making things work’
  • 3. What your users want…
  • 4. What your users want…Fast, performant experience
  • 5. What your users want… Always on,Fast, performant accessible experience anywhere
  • 6. What your users want… Always on,Fast, performant accessible experience anywhere Personalized and rich application
  • 7. What your users want… Always on,Fast, performant accessible experience anywhere Lots of new Personalized andfeatures all of the rich application time
  • 8. Always on,Fast, performant accessible experience anywhere Powerful web applications Lots of new Personalized andfeatures all of the rich application time
  • 9. How?
  • 10. Building powerful web applications
  • 11. Rule 1: Service all web requestsRule 2: Service requests as fast as possibleRule 3: Handle requests at any scaleRule 4: Simplify architecture with servicesRule 5: Automate operational managementRule 6: Leverage unique cloud properties
  • 12. Rule 1: Service all web requests Or“you aren’t doing anything if you don’t answer the door…”
  • 13. Rule 1: Service all web requestsa) Make sure requests get to your ‘front door’ DNS Application Data
  • 14. Rule 1: Service all web requests a) Make sure requests get to your ‘front door’Request DNS Application Data
  • 15. Rule 1: Service all web requests a) Make sure requests get to your ‘front door’Request DNS Application Data
  • 16. Rule 1: Service all web requests a) Make sure requests get to your ‘front door’Request DNS Application Data Clients can’t resolve …then this is you? irrelevant
  • 17. Rule 1: Service all web requests a) Make sure requests get to your ‘front door’ Request DNS Application Data Feature Details Global Supported from AWS global edge locations for fast and reliable domain name resolution “100% Scalable Automatically scales based upon query volumes Available” Route53 Latency based routing Supports resolution of endpoints based upon latency, enabling multi- SLA region application delivery Integrated Integrates with other AWS services allowing Route 53 to front loadhttp://aws.amazon.com/route53/sla balancers, S3 and EC2 Secure Integrates with IAM giving fine grained control over DNS record access
  • 18. Rule 1: Service all web requests a) Make sure requests get to your ‘front door’ b) Make sure you open the door when they arriveRequest DNS Application Data Route53
  • 19. Rule 1: Service all web requests a) Make sure requests get to your ‘front door’ b) Make sure you open the door when they arriveRequest DNS Application Data Region Availability Zone Elastic load balancing Route53 Availability Zone Multi-availability zone Multi-region Availability Zone Elastic Load Balancer Availability Zone Region
  • 20. Rule 1: Service all web requests a) Make sure requests get to your ‘front door’ b) Make sure you open the door when they arrive c) Have the data to form a responseRequest DNS Application Data Region Availability Zone Route53 Availability Zone Availability Zone Elastic Load Balancer Availability Zone Region
  • 21. Rule 1: Service all web requests a) Make sure requests get to your ‘front door’ b) Make sure you open the door when they arrive c) Have the data to form a response Request DNS Application Data RegionMulti-AZ RDS Availability Zone(Master-slave) Route53 Availability ZoneInter-regionreplication Availability ZoneRead-replicas Elastic Load Balancer Availability Zone Region
  • 22. Rule 1: Service all web requestsRule 2: Service requests as fast as possibleRule 3: Handle requests at any scaleRule 4: Simplify architecture with servicesRule 5: Automate operational managementRule 6: Leverage unique cloud properties
  • 23. Rule 1: Service all web requests Rule 2: Service requests as fast as possible Or“I’m not hanging around, so be quick…”
  • 24. Rule 2: Service requests as fast as possible
  • 25. Rule 2: Service requests as fast as possiblea) Choose the fastest route Request Route53 Region Region B A
  • 26. Rule 2: Service requests as fast as possiblea) Choose the fastest route Request Route53 16ms 92ms Region Region B A
  • 27. Rule 2: Service requests as fast as possiblea) Choose the fastest route Request Route53 16ms 92ms Region Region B A
  • 28. Rule 2: Service requests as fast as possiblea) Choose the fastest route Request Route53 Region A DNS entry 16ms Region Region B A
  • 29. Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application serversCloudFront 3 Served from S3World-wide content distribution network /images/*Easily distribute content to end users with lowlatency, high data transfer speeds, and nocommitments. London 2 Served from EC2 *.php Paris 1 Single CNAME NY www.mysite.com
  • 30. Rule 2: Service requests as fast as possiblea) Choose the fastest routeb) Offload your application servers Without CloudFront EC2 webservers/app servers loaded by user requests
  • 31. Rule 2: Service requests as fast as possiblea) Choose the fastest routeb) Offload your application servers With CloudFront Load of user requests pushed into CloudFront, EC2 cluster can scale down Offload Scale Down
  • 32. Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application serversNo CDN CDN for CDN for Static Static & Content Dynamic Content Offload Scale Down Response TimeResponse Time Response Time Server Load Server Server Load Load
  • 33. Rule 2: Service requests as fast as possible a) Choose the fastest route b) Offload your application servers c) Cache it if you canElastiCacheMemcached compatible cachinglayerServe frequently requested & slowchanging data from scalable cacheclustersReduce load on database and otherservers
  • 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 mattersDatabase Query Performance Desired consistency, predictability Scale
  • 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 mattersDatabase Query Performance Desired consistency, predictability Actual degraded performance with scale Scale
  • 36. 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 mattersDatabase Query Performance Desired consistency, predictability Management problems Data sharding Data caching Actual Provisioning degraded Cluster management performance Fault management with scale Scale
  • 37. 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 mattersDatabase Query Performance Dynamo DB Query Performance DynamoDB Low latency Large scale Zero admin Predictable performance Relational Database Query Performance Scale
  • 38. 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 mattersDatabase Query Performance Dynamo DB Query Performance DynamoDB Low latency Large scale Average single-digit milliseconds server side Zero admin latencies Predictable performance Runs on solid state drives, and is built to maintain consistent, fast latencies at any scale Scale
  • 39. Rule 1: Service all web requestsRule 2: Service requests as fast as possibleRule 3: Handle requests at any scaleRule 4: Simplify architecture with servicesRule 5: Automate operational managementRule 6: Leverage unique cloud properties
  • 40. Rule 1: Service all web requests Rule 2: Service requests as fast as possible Rule 3: Handle requests at any scale Or“When they come, they REALLY come…”
  • 41. Rule 3: Handle requests at any scalea) Scale up Vertical Scaling From $0.02/hr Scale up with Elastic Compute Cloud (EC2) Basic unit of compute capacity Range of CPU, memory & local disk options 14 Instance types available, from micro through cluster compute to SSD backed
  • 42. Rule 3: Handle requests at any scalea) Scale upb) Scale out as-create-auto-scaling-group MyGroupTriggerauto-scaling --launch-configuration MyConfigpolicy --availability-zones eu-west-1a --min-size 4 --max-size 200 Auto-scaling Automatic re-sizing of compute clusters based upon demand
  • 43. Rule 3: Handle requests at any scalea) Scale upb) Scale out Manually By Schedule Send an API call or use CLI to Scale up/down based on date and timelaunch/terminate instances – Only need to specify capacity change (+/-) By Policy Auto-RebalanceScale in response to changing conditions, Instances are automatically based on user configured real-time launched/terminated to ensure the monitoring and alerts application is balanced across multiple Azs
  • 44. Rule 3: Handle requests at any scalea) Scale upb) Scale out Manually By Schedule Preemptive manual scaling of Send an API call or use CLI to Regular scaling up and down of Scale up/down based on date and timelaunch/terminate instances – Only need capacity instances e.g. before a marketing event add(+/-) to specify capacity change 10 more e.g. scale from 0 to 2 to process SQS instances messages every night or double capacity on a Friday night By Policy Auto-RebalanceScale in response to changing conditions, Instances are automatically Dynamic scale based upon based on user configured real-time Maintain capacity across launched/terminated to ensure the monitoringmetrics custom and alerts application is balancedzones multiple availability across e.g. SQS queue depth, Average CPU load, e.g. Instance availability maintained in Azs ELB latency event of AZ becoming unavailable
  • 45. Rule 3: Handle requests at any scale a) Scale up b) Scale out c) Dial it up Elastic Block Store DynamoDBProvisioned IOPS up to 1000 per EBS Provisioned read/write performance per volume table Predictable performance for Predictable high performance scaled via demanding workloads such as console or API databases
  • 46. “AWS gave us the flexibility to bring a massive amount of capacity online in a short period of DynamoDB: time and allowed us to do so in an operationally over 500,000 writes per straightforward way. second AWS is now Shazam’s cloud provider of choice,” Amazon EMR:more than 1 million writes Jason Titus, per second CTO
  • 47. Rule 1: Service all web requestsRule 2: Service requests as fast as possibleRule 3: Handle requests at any scaleRule 4: Simplify architecture with servicesRule 5: Automate operational managementRule 6: Leverage unique cloud properties
  • 48. Rule 1: Service all web requests Rule 2: Service requests as fast as possible Rule 3: Handle requests at any scale Rule 4: Simplify architecture with services Or“Building new stuff is fun, but other peoples’ software is a drag”
  • 49. Rule 4: Simplify architecture with services 30% 70% Traditional Your Managing All of theInfrastructure Business “Undifferentiated Heavy Lifting”
  • 50. Rule 4: Simplify architecture with services 30% 70% Traditional Your Managing All of theInfrastructure Business “Undifferentiated Heavy Lifting” AWS More Time to Focus on Configuring Your Cloud-Based Your Business Cloud AssetsInfrastructure 70% 30%
  • 51. Rule 4: Simplify architecture with services Relational Database ServiceUse RDS for databases Database-as-a-Service No need to install or manage database instances Scalable and fault tolerant configurations DynamoDB Use DynamoDB for Provisioned throughput NoSQL database high performance key- Fast, predictable performance value DB Fully distributed, fault tolerant architecture
  • 52. Rule 4: Simplify architecture with services Amazon SQS Reliable messageProcessing results Reliable, highly scalable, queue service queuing without for storing messages as they travel Amazon SQS between instances additional software 1 Processing task/processing trigger 2Push inter-process Simple Workflow Task Aworkflows into the Reliably coordinate processing steps Task B 3 across applicationscloud with SWF (Auto-scaling) Integrate AWS and non-AWS resources Manage distributed state in complex systems Task C
  • 53. Rule 4: Simplify architecture with services Document Server Cloud SearchDon’t install search Elastic search engine based uponsoftware, use Amazon A9 search engine Fully managed service withCloudSearch Search sophisticated feature set Server Scales automatically Results Elastic MapReduce Elastic Hadoop cluster Process large volumes Integrates with S3 & DynamoDB of data cost effectively Leverage Hive & Pig analytics scripts with EMR Integrates with instance types such as spot
  • 54. “Amazon CloudSearch is a game-changingproduct that has allowed us to deliver powerfulnew search capabilities. Our customers can now find what they are looking for faster and more easily than ever before… ….We saved many months of re-architecture and development time by going with Amazon CloudSearch” Don MacAskill CEO & Chief Geek SmugMug
  • 55. Rule 1: Service all web requestsRule 2: Service requests as fast as possibleRule 3: Handle requests at any scaleRule 4: Simplify architecture with servicesRule 5: Automate operational managementRule 6: Leverage unique cloud properties
  • 56. Or“Run it from the iPhone…”Rule 5: Automate operational managementRule 6: Leverage unique cloud properties
  • 57. Rule 5: Automate operational management a) Everything is programmableAccess everything Achieve the highest levels via CLI, API or Compute of automation Console Security Scaling sophistication with ease CDN Backup DNS Database Storage Load Balancing Workflow Monitoring Networking Messaging
  • 58. Rule 5: Automate operational managementa) Everything is programmableb) 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
  • 59. Rule 5: Automate operational management a) Everything is programmable b) Think disposable, one click deployments c) Design for failure, implement self healing Bootstrapping Auto-scaling Cloud Watch Customize instance Maintain capacity of Know what’s going on, startup instances take automated actions Get instances to ask ‘who am Using a minimum pool Use CloudWatch standard andI?’ question on startup and be size will maintain custom metrics to create configured dynamically upon capacity in the event of alarms. being asnwered instance failures Respond with automated administration actions
  • 60. Rule 5: Automate operational managementa) Everything is programmableb) Think disposable, one click deploymentsc) Design for failure, implement self healing
  • 61. Rule 1: Service all web requestsRule 2: Service requests as fast as possibleRule 3: Handle requests at any scaleRule 4: Simplify architecture with servicesRule 5: Automate operational managementRule 6: Leverage unique cloud properties
  • 62. Or“Do awesome things, fast…” Rule 6: Leverage unique cloud properties
  • 63. Rule 6: Leverage unique cloud propertiesa) Optimize costs with instance types High I/O 4XL 60.5 GB High Storage 8XL 117 GB 35 EC2 Compute Units Hi-Mem Cluster Compute 8XL 244 GB 35 EC2 Compute Units, 16 virtual cores 88 EC2 Compute Units 24 * 2 TB ephemeral drives 256 2*1024 GB SSD-based local instance storage 16 virtual cores 10 GB Ethernet $3.10/3.58 240 GB SSD $4.60/4.931 $2.40/2.97 Hi-Mem 4XL 68.4 GB 128 26 EC2 Compute Units 8 virtual cores $1.80/2.28 10 GB Cluster Compute 8XL 60.5 GB 64 Hi-Mem 2XL 34.2 GB 13 EC2 Compute Units 4 virtual cores Inter-Instance 88 EC2 Compute Units $2.40/2.97 $0.90/1.14 Hi-Mem XL 17.1 GB Network Cluster Compute 4XL 23 GB 32 6.5 EC2 Compute Units 33.5 EC2 Compute Units 2 virtual cores $1.30/1.61 $0.45/0.57 Memory (GB) Cluster GPU 4XL 22 GB 16 Extra Large 15 GB 8 EC2 Compute Units 4 virtual cores 33.5 EC2 Compute Units, 2 x NVIDIA Tesla “Fermi” M2050 GPUs $2.10/2.60 $0.64/0.92 M3 XL 15 GB M3 2XL 30 GB 13 EC2 Compute Units 4 26 EC2 Compute Units 8 virtual cores virtual cores 8 Medium 3.7 GB, 2 EC2 Compute Units 1 virtual core EBS storage only $0.58/0.98 EBS storage only $1.16/1.96 $0.16/0.23 Large 7.5 GB 4 4 EC2 Compute Units 2 virtual cores $0.32/0.46 High-CPU XL 7 GB 20 EC2 Compute Units 8 virtual cores $0.66/1.14 Small 1.7 GB, High-CPU Med 1.7 GB 1 EC2 Compute Unit 5 EC2 Compute Units 2 1 virtual core $0.08/0.115 2 virtual cores $0.165/0.285 Micro 613 MB Up to 2 ECUs (for short bursts) 1 $0.02/0.03 1 2 4 8 16 32 64 128 256 EC2 Compute Units (HP)
  • 64. Rule 6: Leverage unique cloud properties a) Optimize costs with instance types On-demand instances Reserved instances Spot instances Unix/Linux instances start at 1- or 3-year terms Bid on unused EC2 capacity $0.02/hour Pay low up-front fee, receive significant hourly Spot Price based on supply/demand, Pay as you go for compute power discount determined automatically Low cost and flexibility Low Cost / Predictability Cost / Large Scale, dynamic workload handlingPay only for what you use, no up-front Helps ensure compute capacity is available commitments or long-term contracts when needed Use Cases: Use Cases: Use Cases: Applications with flexible start and end timesApplications with short term, spiky, or unpredictable workloads; Applications with steady state or predictable Applications only feasible at very low compute usage prices Application development or testing Applications that require reserved capacity, including disaster recovery
  • 65. Rule 6: Leverage unique cloud propertiesa) Optimize costs with instance types 7000 6000 Spot 5000 4000 On Demand 3000 2000 Reserved Instances 1000 0
  • 66. Rule 6: Leverage unique cloud properties a) Optimize costs with instance types b) Get insight fast with Elastic MapReduceElastic MapReduce Feature DetailsManaged, elastic Hadoop cluster Scalable Use as many or as few compute instances running Hadoop as you want. Modify the number ofIntegrates with S3 & DynamoDB instances while your job flow is runningLeverage Hive & Pig analytics scriptsIntegrates with instance types such as spot Integrated with Works seamlessly with S3 as origin and output. other services 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
  • 67. Rule 6: Leverage unique cloud properties a) Optimize costs with instance types b) Get insight fast with Elastic MapReduce S3 + DynamoDB Input dataCode Elastic Name Output MapReduce node S3 + SimpleDB Queries HDFS + BI Via JDBC, Pig, Hive Elastic cluster
  • 68. Features powered by Amazon Elastic MapReduce: People Who Viewed this Also Viewed Review highlights Auto complete as you type on search Search spelling suggestions Top searches Ads200 Elastic MapReduce jobs per day Processing 3TB of data
  • 69. “With AWS, our developers can now do things they couldn’t before……Our systems team can focus their energies on other challenges.” Dave Marin Search and data-mining engineer
  • 70. 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 itCluster compute instances Network placement groupsImplement HVM process execution Cluster instances deployed in a ‘Placement Group’ enjoy lowIntel® Xeon® E5-2670 processors latency, full bisection 10 Gbps bandwidth10 Gigabit Ethernet 80 EC2 Compute Units 60GB RAM 3TB Local Disk Cluster Compute 10Gbps
  • 71. Rule 1: Service all web requestsRule 2: Service requests as fast as possibleRule 3: Handle requests at any scaleRule 4: Simplify architecture with servicesRule 5: Automate operational managementRule 6: Leverage unique cloud properties
  • 72. What your users want… Always on,Fast, performant accessible experience anywhere Lots of new Personalized andfeatures all of the rich application time
  • 73. With AWS Elastic utility capacity ✔ Always on, accessible anywhere Lots of new Personalized andfeatures all of the rich application time
  • 74. With AWS Elastic utility capacity ✔ Highly available global coverage ✔ Lots of new Personalized andfeatures all of the rich application time
  • 75. With AWSElastic utility capacity ✔ Highly available global coverage ✔ ✔ Agility & Personalized andautomated rich applicationoperations
  • 76. With AWSElastic utility capacity ✔ Highly available global coverage ✔ ✔ ✔ Agility & Cost effectiveautomated storage, big data &operations analytics
  • 77. Thank youaws.amazon.com/free aws.amazon.com/careers/
  • 78. aws.amazon.com