Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWS Summit Tel Aviv - Startup Track - Architecting for High Availability

1,003 views

Published on

Published in: Technology, Business
  • Be the first to comment

AWS Summit Tel Aviv - Startup Track - Architecting for High Availability

  1. 1. AWS Summit 2013 Tel Aviv Oct 16 – Tel Aviv, Israel ARCHITECTING FOR HIGH AVAILABILITY Alex Sinner Solutions Architect, Amazon Web Services
  2. 2. “LET’S BUILD A ________ WEB APPLICATION”
  3. 3. “LET’S BUILD A HIGHLY AVAILABLE ________ WEB APPLICATION”
  4. 4. “LET’S BUILD A HIGHLY AVAILABLE AND SCALABLE ________ WEB APPLICATION”
  5. 5. “LET’S BUILD A HIGHLY AVAILABLE, SCALABLE, AND RESILIENT ________ WEB APPLICATION”
  6. 6. AWS BUILDING BLOCKS Inherently Fault-Tolerant Services  Amazon S3  Amazon DynamoDB  Amazon CloudFront  Amazon SWF  Amazon SQS  Amazon SNS  Amazon SES  Amazon Route53  Elastic Load Balancing  AWS IAM  AWS Elastic Beanstalk  Amazon ElastiCache  Amazon EMR  Amazon Redshift  Amazon CloudSearch Fault-Tolerant with the right architecture  Amazon EC2  Amazon EBS  Amazon RDS  Amazon VPC
  7. 7. 1. DESIGN FOR FAILURE 2. USE MULTIPLE AZs 3. BUILD FOR SCALE 4. DECOUPLE COMPONENTS
  8. 8. « Everything fails all the time » Werner Vogels CTO of Amazon
  9. 9. YOUR GOAL APPLICATIONS SHOULD CONTINUE TO FUNCTION EVEN IF THE UNDERLYING PHYSICAL HARDWARE FAILS OR IS REMOVED OR REPLACED
  10. 10. # 1 DESIGN FOR FAILURE
  11. 11. AVOID SINGLE POINTS OF FAILURE ASSUME EVERYTHING FAILS, AND WORK BACKWARDS
  12. 12. AVOID SINGLE POINTS OF FAILURE ASSUME EVERYTHING FAILS, AND WORK BACKWARDS
  13. 13. HEALTH CHECKS
  14. 14. # 2 USE MULTIPLE AVAILABILITY ZONES
  15. 15. US-WEST (N. California) EU-WEST (Ireland) GOV CLOUD ASIA PAC (Tokyo) US-EAST (Virginia) ASIA PAC (Sidney) US-WEST (Oregon) ASIA PAC (Singapore) SOUTH AMERICA (Sao Paulo)
  16. 16. AMAZON RDS MULTI-AZ
  17. 17. # 3 BUILD FOR SCALE
  18. 18. AMAZON CLOUDWATCH MONITORING FOR AWS RESOURCES
  19. 19. AUTO SCALING SCALE UP/DOWN EC2 CAPACITY
  20. 20. HEALTH CHECKS + AUTO SCALING
  21. 21. HEALTH CHECKS + AUTO SCALING = SELF-HEALING
  22. 22. WalkMe Architecture for High Availability © Copyright 2013 WalkMe Inc. - Confidential
  23. 23. The WalkMe Platform One of a kind Platform to guide and engage prospects, customers, employees or partners through any Web experience WalkMe Reduces Complexity to Empower Advanced Selling, Support , training and improved user experience Using WalkMe increases conversion rates, reduces support costs, accelerates training and improves customer experience No integration or changes to the underlying website required. © Copyright 2013 WalkMe Inc. - Confidential
  24. 24. Introducing the Holistic Approach to Automated Engagement Announcements Task List all or groups On Board new Users Introduce new version “scheduled maintenance” “sale on shirts “ “happy 4th of July” Launchers & Permalinks Promotion Boost the effectiveness of your existing FAQ, chat and social support Personalized “happy b-day” “top up” “bag for your camera?” Surveys Pinpointed feedback – right on time Analytics & Goals Straight forward measurement and improvement of critical paths Online Support Employee Training Search Segmented Display Right people – Right time Advanced Online Selling Pinpointed to site and any other relevant resource (such as help desk) Improved User Experience Onboarding
  25. 25. Selected Customers And many more…
  26. 26. The Basics i. WalkMe customer creates WalkThrus using the WalkMe Editor. ii. WalkMe customer adds the WalkMe JavaScript code to his website. iii. WalkMe customer publishes the WalkThrus to his users. iv. Our customers’ users gets WalkMe when they surf the website. v. Our customer can access WalkMe dashboards to view usage analytics.
  27. 27. Challenges • Maximum availability for client side experience (100%) • Low latency for fetching the WalkMe files • Very high traffic volume from our customers users (over 1B requests a month) • Analyzing billions of records for WalkMe analytics
  28. 28. Evolution – Phase 1 Problems: • Low availability • High latency • Hard to scale • Database availability
  29. 29. Evolution – Phase 2 Solution: • Using AWS CloudFront to host the static files. Problems: • High volume of analytics causes a scaling issues and availability • Database availability
  30. 30. Evolution – Phase 3 Solution: • Adding AWS RDS Multi AZ • Adding AWS Beanstalk New Challenge: • Collection of billions of records for BigData analytics (RDS is a bottleneck)
  31. 31. Evolution – Phase 4 Solution: • Analytics BigData requests are sent to CloudFront. • Analyzing CloudFront logs using Hadoop.
  32. 32. Solution Thank You
  33. 33. 1. DESIGN FOR FAILURE 2. USE MULTIPLE AZs 3. BUILD FOR SCALE 4. DECOUPLE COMPONENTS
  34. 34. # 4 DECOUPLE COMPONENTS
  35. 35. BUILD LOOSELY COUPLED SYSTEMS The looser they are coupled, the bigger they scale, the more fault tolerant they get…
  36. 36. UPLOAD ANALYZE REPORT& NOTIFY
  37. 37. AMAZON SQS SIMPLE QUEUE SERVICE
  38. 38. UPLOAD ANALYZE REPORT& NOTIFY
  39. 39. UPLOAD ANALYZE REPORT& NOTIFY
  40. 40. UPLOAD REPORT& NOTIFY
  41. 41. UPLOAD ANALYZE REPORT& NOTIFY
  42. 42. ARCHITECTURE DESIGN PATTERN
  43. 43. SQS VISIBILITY TIMEOUT
  44. 44. BUFFERING
  45. 45. CLOUDWATCH METRICS FOR AMAZON SQS + AUTO SCALING
  46. 46. 1. DESIGN FOR FAILURE 2. USE MULTIPLE AZs 3. BUILD FOR SCALE 4. DECOUPLE COMPONENTS
  47. 47. YOUR GOAL APPLICATIONS SHOULD CONTINUE TO FUNCTION EVEN IF THE UNDERLYING PHYSICAL HARDWARE FAILS OR IS REMOVED OR REPLACED
  48. 48. AWS ARCHITECTURE CENTER http://aws.amazon.com/architecture AWS TECHNICAL ARTICLES http://aws.amazon.com/articles AWS BLOG http://aws.typepad.com AWS PODCAST http://aws.amazon.com/podcast
  49. 49. THANK YOU!

×