Architecting for High Availability

4,247 views
4,035 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

Architecting for High Availability

  1. 1. Architecting for High Availability Sajee Mathew Solutions Architect
  2. 2. What is High Availability?• Availability: Percentage of time an application operates during its work cycle• 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 2
  3. 3. Availability 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• Disaster Recovery – The process, policies, and procedures related to restoring service after a catastrophic event• AWS democratizes High Availability – Multiple servers, isolated redundant data centers, regions across the globe, FT services, etc. 3
  4. 4. AWS GLOBALINFRASTRUCTURE
  5. 5. 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)
  6. 6. 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)
  7. 7. AWS BUILDING BLOCKSInherently Highly Available and Highly Available withFault Tolerant Services the right architecture Amazon S3  Amazon SQS  Amazon EC2 Amazon DynamoDB  Amazon SNS  Amazon EBS Amazon CloudFront  Amazon SES  Amazon RDS Amazon Route53  Amazon SWF  Amazon VPC Elastic Load Balancing  …
  8. 8. 1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
  9. 9. LET’S BUILD AHIGHLY AVAILABLE SYSTEM
  10. 10. # 1DESIGN FOR FAILURE ●○○○○
  11. 11. « Everything fails all the time » Werner Vogels CTO 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 EBS ELASTIC BLOCK STORE
  16. 16. AMAZON ELBELASTIC LOAD BALANCING
  17. 17. HEALTH CHECKS
  18. 18. # 2 MULTIPLEAVAILABILITY 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. DEGRADED MODE
  27. 27. AMAZON S3 STATIC WEBSITE + AMAZON ROUTE 53WEIGHTED RESOLUTION
  28. 28. #5 LOOSECOUPLING ●●●●●
  29. 29. BUILD LOOSELYCOUPLED SYSTEMS The looser they are coupled, the bigger they scale, the more fault tolerant they get…
  30. 30. AMAZON SQS SIMPLE QUEUE SERVICE
  31. 31. PUBLISH&RECEIVE TRANSCODE NOTIFY
  32. 32. PUBLISH&RECEIVE TRANSCODE NOTIFY
  33. 33. VISIBILITY TIMEOUT
  34. 34. BUFFERING
  35. 35. CLOUDWATCH METRICS FOR AMAZON SQS + AUTO SCALING
  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. 1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
  41. 41. 1. DESIGN FOR FAILURE2. MULTIPLE AVAILABILITY ZONES3. SCALING4. SELF-HEALING5. LOOSE COUPLING
  42. 42. YOUR GOALApplications should continue to function
  43. 43. IT’S ALL ABOUT CHOICEBALANCE COST & HIGH AVAILABILITY
  44. 44. AWS ARCHITECTURE CENTERhttp://aws.amazon.com/architectureAWS TECHNICAL ARTICLEShttp://aws.amazon.com/articlesAWS BLOGhttp://aws.typepad.comAWS PODCASThttp://aws.amazon.com/podcast

×