John HildebrandtArchitecting for High AvailabilitySolutions Architect, AWS
22What is High Availability?• Availability: Percentage of time an application operates during its workcycle• Loss of avail...
33Availability is related to• Scalability– Ability of an application to accommodate growth without changing design– If app...
AWS GLOBALINFRASTRUCTURE
US-WEST (Oregon)EU-WEST (Ireland)ASIA PAC (Tokyo)ASIA PAC(Singapore)US-WEST (N. California)SOUTH AMERICA (Sao Paulo)US-EAS...
US-WEST (Oregon))EU-WEST (Ireland)ASIA PAC (Tokyo)ASIA PAC(Singapore)US-WEST (N. California)SOUTH AMERICA (Sao Paulo)US-EA...
AWS BUILDING BLOCKSInherently Highly Available andFault Tolerant ServicesHighly Available withthe right architecture Amaz...
1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
LET’S BUILD AHIGHLY AVAILABLESYSTEM
#1DESIGN FOR FAILURE●○○○○
« Everything failsall the time »Werner VogelsCTO of Amazon
AVOID SINGLE POINTS OF FAILURE
AVOID SINGLE POINTS OF FAILUREASSUME EVERYTHING FAILS,AND WORK BACKWARDS
YOUR GOALApplications should continue to function
AMAZON EBSELASTIC BLOCK STORE
AMAZON ELBELASTIC LOAD BALANCING
HEALTH CHECKS
#2MULTIPLEAVAILABILITY ZONES●●○○○
AMAZON RDSMULTI-AZ
AMAZON ELB ANDMULTIPLE AZs
#3SCALING●●●○○
AUTO SCALINGSCALE UP/DOWN EC2 CAPACITY
#4SELF-HEALING●●●●○
HEALTH CHECKS+AUTO SCALING
HEALTH CHECKS+AUTO SCALING=SELF-HEALING
#5LOOSECOUPLING●●●●●
BUILD LOOSELYCOUPLED SYSTEMSThe looser they are coupled,the bigger they scale,the more fault tolerant they get…
AMAZON SQSSIMPLE QUEUE SERVICE
PUBLISH&NOTIFYRECEIVE TRANSCODE
PUBLISH&NOTIFYRECEIVE TRANSCODE
VISIBILITY TIMEOUT
BUFFERING
CLOUDWATCH METRICSFOR AMAZON SQS+AUTO SCALING
1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
YOUR GOALApplications should continue to function
IT’S ALL ABOUTCHOICEBALANCE COST & HIGH AVAILABILITY
AWS ARCHITECTURE CENTERhttp://aws.amazon.com/architectureAWS TECHNICAL ARTICLEShttp://aws.amazon.com/articlesAWS BLOGhttp:...
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
AWS Summit 2013 | Auckland - Architecting for High Availability
Upcoming SlideShare
Loading in …5
×

AWS Summit 2013 | Auckland - Architecting for High Availability

1,105 views
1,001 views

Published on

AWS provides a platform that is ideally suited for building highly available systems, enabling you to build reliable, affordable, fault-tolerant systems that operate with a minimal amount of human interaction. This session covers many of the high-availability and fault-tolerance concepts and features of the various services that you can use to build highly reliable and highly available applications in the AWS Cloud: architectures involving multiple Availability Zones, including EC2 best practices and RDS Multi-AZ deployments; loosely coupled and self-healing systems involving SQS and Auto Scaling; networking best practices for high availability, including Elastic IP addresses, load balancing, and DNS; leveraging services that inherently are built with high-availability and fault tolerance in mind, including S3, Elastic Beanstalk and more.

Published in: Technology, Business

AWS Summit 2013 | Auckland - Architecting for High Availability

  1. 1. John HildebrandtArchitecting for High AvailabilitySolutions Architect, AWS
  2. 2. 22What is High Availability?• Availability: Percentage of time an application operates during its workcycle• Loss of availability is known as an outage or downtime– App is offline, unreachable, or partially available– App is slow to use– Planned and unplanned• Goal– No downtime– Always available
  3. 3. 33Availability is related to• Scalability– Ability of an application to accommodate growth without changing design– If app cannot scale, availability may be impacted– Scalability doesn’t guarantee availability• Fault Tolerance– Built-in redundancy so apps can continue functioning when components fail– Fault tolerance is crucial to HA• AWS democratizes High Availability– Multiple servers, isolated redundant data centers, regions across the globe, FT services, etc.
  4. 4. AWS GLOBALINFRASTRUCTURE
  5. 5. US-WEST (Oregon)EU-WEST (Ireland)ASIA PAC (Tokyo)ASIA PAC(Singapore)US-WEST (N. California)SOUTH AMERICA (Sao Paulo)US-EAST (Virginia)AWS GovCloud (US)ASIA PAC (Sydney)Regions
  6. 6. US-WEST (Oregon))EU-WEST (Ireland)ASIA PAC (Tokyo)ASIA PAC(Singapore)US-WEST (N. California)SOUTH AMERICA (Sao Paulo)US-EAST (Virginia)AWS GovCloud (US)ASIA PAC (Sydney)Availability Zones
  7. 7. AWS BUILDING BLOCKSInherently Highly Available andFault Tolerant ServicesHighly Available withthe right architecture Amazon S3 Amazon DynamoDB Amazon CloudFront Amazon Route53 Elastic Load Balancing Amazon SQS Amazon SNS Amazon SES Amazon SWF … Amazon EC2 Amazon EBS Amazon RDS Amazon VPC
  8. 8. 1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
  9. 9. LET’S BUILD AHIGHLY AVAILABLESYSTEM
  10. 10. #1DESIGN FOR FAILURE●○○○○
  11. 11. « Everything failsall the time »Werner VogelsCTO of Amazon
  12. 12. AVOID SINGLE POINTS OF FAILURE
  13. 13. AVOID SINGLE POINTS OF FAILUREASSUME EVERYTHING FAILS,AND WORK BACKWARDS
  14. 14. YOUR GOALApplications should continue to function
  15. 15. AMAZON EBSELASTIC BLOCK STORE
  16. 16. AMAZON ELBELASTIC LOAD BALANCING
  17. 17. HEALTH CHECKS
  18. 18. #2MULTIPLEAVAILABILITY ZONES●●○○○
  19. 19. AMAZON RDSMULTI-AZ
  20. 20. AMAZON ELB ANDMULTIPLE AZs
  21. 21. #3SCALING●●●○○
  22. 22. AUTO SCALINGSCALE UP/DOWN EC2 CAPACITY
  23. 23. #4SELF-HEALING●●●●○
  24. 24. HEALTH CHECKS+AUTO SCALING
  25. 25. HEALTH CHECKS+AUTO SCALING=SELF-HEALING
  26. 26. #5LOOSECOUPLING●●●●●
  27. 27. BUILD LOOSELYCOUPLED SYSTEMSThe looser they are coupled,the bigger they scale,the more fault tolerant they get…
  28. 28. AMAZON SQSSIMPLE QUEUE SERVICE
  29. 29. PUBLISH&NOTIFYRECEIVE TRANSCODE
  30. 30. PUBLISH&NOTIFYRECEIVE TRANSCODE
  31. 31. VISIBILITY TIMEOUT
  32. 32. BUFFERING
  33. 33. CLOUDWATCH METRICSFOR AMAZON SQS+AUTO SCALING
  34. 34. 1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
  35. 35. 1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
  36. 36. 1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
  37. 37. 1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
  38. 38. 1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
  39. 39. 1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
  40. 40. YOUR GOALApplications should continue to function
  41. 41. IT’S ALL ABOUTCHOICEBALANCE COST & HIGH AVAILABILITY
  42. 42. AWS ARCHITECTURE CENTERhttp://aws.amazon.com/architectureAWS TECHNICAL ARTICLEShttp://aws.amazon.com/articlesAWS BLOGhttp://aws.typepad.comAWS PODCASThttp://aws.amazon.com/podcast

×