1. AWS Summit 2013 Tel Aviv
Oct 16 – Tel Aviv, Israel
ARCHITECTING FOR HIGH
AVAILABILITY
Alex Sinner
Solutions Architect, Amazon Web Services

2. “LET’S BUILD
A ________ WEB
APPLICATION”

3. “LET’S BUILD
A HIGHLY AVAILABLE
________ WEB
APPLICATION”

4. “LET’S BUILD
A HIGHLY AVAILABLE
AND SCALABLE
________ WEB
APPLICATION”

5. “LET’S BUILD
A HIGHLY AVAILABLE,
SCALABLE, AND
RESILIENT
________ WEB
APPLICATION”

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

11. 1.
DESIGN FOR FAILURE
2.
USE MULTIPLE AZs
3.
BUILD FOR SCALE
4.
DECOUPLE COMPONENTS

12. « Everything fails
all the time »
Werner Vogels
CTO of Amazon

13. YOUR GOAL
APPLICATIONS SHOULD CONTINUE TO FUNCTION
EVEN IF THE UNDERLYING PHYSICAL HARDWARE
FAILS OR IS REMOVED OR REPLACED

14. #
1
DESIGN FOR FAILURE

15. AVOID SINGLE POINTS OF
FAILURE
ASSUME EVERYTHING FAILS,
AND WORK BACKWARDS

16. AVOID SINGLE POINTS OF
FAILURE
ASSUME EVERYTHING FAILS,
AND WORK BACKWARDS

22. HEALTH CHECKS

28. #
2
USE MULTIPLE
AVAILABILITY ZONES

29. 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)

31. AMAZON RDS
MULTI-AZ

39. #
3
BUILD FOR SCALE

40. AMAZON
CLOUDWATCH
MONITORING FOR AWS RESOURCES

43. AUTO SCALING
SCALE UP/DOWN EC2 CAPACITY

53. HEALTH CHECKS
+
AUTO SCALING

58. HEALTH CHECKS
+
AUTO SCALING
=
SELF-HEALING

60. WalkMe
Architecture for High Availability
© Copyright 2013 WalkMe Inc. - Confidential

61. 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

62. 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

63. Selected Customers
And many more…

64. 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.

65. 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

66. Evolution – Phase 1
Problems:
• Low availability
• High latency
• Hard to scale
• Database availability

67. 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

68. 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)

69. Evolution – Phase 4
Solution:
• Analytics BigData requests
are sent to CloudFront.
• Analyzing CloudFront logs
using Hadoop.

70. Solution
Thank You

71. 1.
DESIGN FOR FAILURE
2.
USE MULTIPLE AZs
3.
BUILD FOR SCALE
4.
DECOUPLE COMPONENTS

72. #
4
DECOUPLE COMPONENTS

73. BUILD LOOSELY
COUPLED SYSTEMS
The looser they are coupled,
the bigger they scale,
the more fault tolerant they get…

76. UPLOAD
ANALYZE
REPORT&
NOTIFY

77. AMAZON SQS
SIMPLE QUEUE SERVICE

78. UPLOAD
ANALYZE
REPORT&
NOTIFY

79. UPLOAD
ANALYZE
REPORT&
NOTIFY

80. UPLOAD
REPORT&
NOTIFY

81. UPLOAD
ANALYZE
REPORT&
NOTIFY

89. ARCHITECTURE
DESIGN PATTERN

94. SQS VISIBILITY TIMEOUT

99. BUFFERING

105. CLOUDWATCH METRICS
FOR AMAZON SQS
+
AUTO SCALING

110. 1.
DESIGN FOR FAILURE
2.
USE MULTIPLE AZs
3.
BUILD FOR SCALE
4.
DECOUPLE COMPONENTS

111. YOUR GOAL
APPLICATIONS SHOULD CONTINUE TO FUNCTION
EVEN IF THE UNDERLYING PHYSICAL HARDWARE
FAILS OR IS REMOVED OR REPLACED

112. 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

114. THANK YOU!