aws webcast - design for availability

© 2011 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.

Design for Availability

Brett Hollman

Manager, Solutions Architecture

April 23rd, 2014


Designing for Availability

ME: Brett Hollman – Solutions Architect and Manager at Amazon Web Services YOU: here to learn more about designing your applications for high availability on AWS TODAY: about best practices and things to think about when building a highly available application on AWS


3 3

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


4 4

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

AWS democratizes High Availability

• Multiple servers, isolated redundant data centers, regions across the globe, Fault

Tolerant services, etc.


AWS GLOBAL

INFRASTRUCTURE


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

AWS CHINA

(Beiijing)

Limited preview


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


Compute Storage

AWS Global Infrastructure

Database

App Services

Deployment & Administration

Networking

Reference Model


AWS BUILDING BLOCKS

Inherently Highly Available and

Fault Tolerant Services

Highly Available

with the 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


1. DESIGN FOR FAILURE

2. MULTIPLE AVAILABILITY ZONES

3. SCALING

4. SELF-HEALING

5. LOOSE COUPLING

Principles of Designing for Availability


LET’S BUILD A

HIGHLY AVAILABLE SYSTEM


Vertical Scaling

From $0.02/hr Elastic Compute Cloud (EC2) Basic unit of compute capacity

Range of CPU, memory & local disk options

22 Instance types available from 6 different families

Feature Details

Flexible Run windows or Linux distributions

Scalable Wide range of instance types from micro to

cluster compute

Machine Images Configurations can be saved as machine

images (AMIs) from which new instances can

be created

Full control Full root or administrator rights

Secure Full firewall control via Security Groups

Monitoring Publishes metrics to Cloud Watch

Inexpensive On-demand, Reserved and Spot instance types

VM Import/Export Import and export VM images to transfer

configurations in and out of EC2

Compute

Compute Storage


Database

App Services


Networking

** MANY NEW INSTANCE TYPES


#1 DESIGN FOR FAILURE

●○○○○


« Everything fails all the time »

Werner Vogels

CTO of Amazon


AVOID SINGLE POINTS OF FAILURE


AVOID SINGLE POINTS OF FAILURE

ASSUME EVERYTHING FAILS,

AND WORK BACKWARDS


YOUR GOAL

Applications should continue to function


AMAZON EBS ELASTIC BLOCK STORE


Elastic Block Store High performance block storage device

1GB to 1TB in size

Mount as drives to instances

Feature Details

High performance

file system

Mount EBS as drives and format as required

Flexible size Volumes from 1GB to 1TB in size

Secure Private to your instances

Performance Use provisioned IOPS to get desired level of IO

performance

Available Replicated within an Availability Zone

Backups Volumes can be snapshotted for point in time

restore

Monitoring Detailed metrics captured via Cloud Watch

Storage

Compute Storage


Database

App Services


Networking


AMAZON ELB ELASTIC LOAD BALANCING


Elastic Load Balancing Create highly scalable applications

Distribute load across EC2 instances in multiple

availability zones

Feature Details

Auto-scaling Automatically scales to handle request volume

Available Load balance across instances in multiple

availability zones

Health checks Automatically checks health of instances and

takes them in or out of service

Session stickiness Route requests to the same instance

Secure sockets layer Supports SSL offload from web and application

servers with flexible cipher support

Monitoring Publishes metrics to Cloud Watch

Compute Storage


Database

App Services


Networking

** NEW CONNECTION DRAINING

AND NEW ACCESS LOGS

Compute


HEALTH CHECKS


#2 MULTIPLE

AVAILABILITY ZONES ●●○○○


AMAZON RDS

MULTI-AZ


Relational Database Service Database-as-a-Service

No need to install or manage database instances

Scalable and fault tolerant configurations

Feature Details

Platform support Create MySQL, SQL Server, Postgres and

Oracle RDBMS

Preconfigured Get started instantly with sensible default

settings

Automated patching Keep your database platform up to date

automatically

Backups Automatic backups and point in time recovery

and full DB backups

Provisioned IOPS Specify IO throughput depending on

requirements

Failover Automated failover to slave hosts in event of a

failure

Replication Easily create read-replicas of your data and

seamlessly replicate data across availability

zones

Database

Compute Storage


Database

App Services


Networking


AMAZON ELB AND

MULTIPLE AZs


#3 SCALING

●●●○○


AUTO SCALING SCALE UP/DOWN EC2 CAPACITY


Auto Scaling Automatic re-sizing of compute clusters based upon demand

Trigger auto-scaling policy

Feature Details

Control Define minimum and maximum instance pool

sizes and when scaling and cool down occurs

Integrated to

CloudWatch

Use metrics gathered by CloudWatch to drive

scaling

Instance types Run auto scaling for on-demand instances and

spot. Compatible with VPC

as-create-auto-scaling-group MyGroup

--launch-configuration MyConfig

--availability-zones eu-west-1a

--min-size 4

--max-size 200

Compute

Compute Storage


Database

App Services


Networking

** NEW CONSOLE


Scaling Data Tier


RDS - Push-Button Scaling

scale up or down to the desired instance class

scale up to an 8-core server with 244 GB of RAM

with the cr1.8xlarge


Use Cases Reporting and ETL

Discrete read/write transactions (browsers vs buyers)

Scale-out with one or more read servers master-slave

architecture

scaling READS


• Optimize master for OLTP and read slaves for table scans

• Resize slaves as needed to boost reporting performance

• Use short-term slaves to save cost during monthly reporting

• Promote to standalone server.

• NEW - Cross Region Read Replicas with MySQL

scaling READS Tech tips


Scaling for Writes on the Data Tier

At large scale, you may start to run into issues with your database around contention on writes to the master.

How can you solve it?

• Federation ( splitting into multiple DBs based on function)

• Sharding ( splitting one data set up across multiple hosts)

• Moving some functionality to other types of DBs ( NoSQL )


Database Federation • Split up Databases by

function/purpose

• Harder to do cross function queries

• Essentially delaying the need for

something like sharding/NoSQL until

much further down the line

• Won’t help with single huge

functions/tables

ForumsDB

UsersDB

ProductsDB


Sharded Horizontal Scaling

• More complex at the application

layer

• ORM support can help

• No practical limit on scalability

• Operation complexity/sophistication

• Shard by function or key space

• RDBMS or NoSQL

User ShardID

002345 A

002346 B

002347 C

002348 B

002349 A

A

B

C


#4 SELF-HEALING

●●●●○


HEALTH CHECKS

+ AUTO SCALING


HEALTH CHECKS

+ AUTO SCALING

=

SELF-HEALING


DEGRADED MODE


AMAZON S3 STATIC WEBSITE

+ AMAZON ROUTE 53

DNS Failover


#5 LOOSE

COUPLING ●●●●●


BUILD LOOSELY COUPLED SYSTEMS

The looser they are coupled, the bigger they scale,

the more fault tolerant they get…


SOA

Move services into their own tiers/modules. Treat each of these as 100% whole-y separate pieces of your infrastructure and scale them independently.

Amazon.com and AWS do this extensively! It offers flexibility and greater understanding of each component.


Loose coupling sets you free!

The looser they're coupled, the bigger they scale

Independent components

Design everything as a black box

Decouple interactions

Favor services with built in redundancy and scalability than building your own


AMAZON SQS SIMPLE QUEUE SERVICE


Amazon SQS

Processing

task/processing trigger

Processing results

Amazon SQS Reliable, highly scalable, queue service

for storing messages as they travel

between instances

Feature Details

Reliable Messages stored redundantly across

multiple availability zones

Simple Simple APIs to send and receive messages

Scalable Unlimited number of messages

Secure Authentication of queues to ensure

controlled access

Application Services

Compute Storage


Database

App Services


Networking


PUBLISH&

NOTIFY RECEIVE TRANSCODE


VISIBILITY TIMEOUT


CLOUDWATCH METRICS FOR AMAZON SQS

+ AUTO SCALING


1. DESIGN FOR FAILURE

2. MULTIPLE AVAILABILITY ZONES

3. SCALING

4. SELF-HEALING

5. LOOSE COUPLING


YOUR GOAL

Applications should continue to function


IT’S ALL ABOUT

CHOICE BALANCE COST & AVAILABILITY REQUIREMENTS


AWS Architecture Center http://aws.amazon.com/architecture

AWS Whitepapers http://aws.amazon.com/whitepapers

AWS Blog http://aws.typepad.com

Thanks for coming!

- Brett Hollman

aws webcast - design for availability

Technology

avoid single

publishamp

sao paulo

south america

express consent

asia pac

aws govcloud

administration