Building Web Scale Applications with AWS

Preview:

DESCRIPTION

AWS provides a platform that is ideally suited for deploying highly available and reliable systems that can scale with a minimal amount of human interaction.  This talk describes a set of architectural patterns that support highly available services that are also scalable, low cost, low latency and allow for agile  development practices.   We walk through the various architectural decisions taken for each tier and explain our choices for appropriate AWS services and building blocks to ensure the security, scale, availability and reliability of the application.

Citation preview

Dan Cuddeford and Matthew Trescot

Building Web-Scale Applications with AWS

Enterprise Solutions Architect and Solutions Architect

I am Barack Obama, Ask me anything

Reddit Needed to Scale for a special guest

• 2,987,307 pageviews on the day of the IAmA • President Obama’s user page received 428,004

pageviews on the day of the IAMA • Added 60 dedicated instance to handle the increased

load • At peek transfering 48 MB/s to the internet

While You Scale

• Architect for Failure

– Failures do happen

• Architect with Security

– Security must happen

Why Is Scale Important?

Self

Hosting Waste

Customer

Dissatisfaction

Actual demand

Predicted Demand

Rigid Elastic

Actual demand

AWS

Regions and Storage

Where and What

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

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

Storage Types

Ephemeral Storage

• (Almost) every instance has them

• Fast

• Cheap

• Volatile

Elastic Block Storage

• 1GB to 1TB

• Snapshot-able

• You choose the IOPS

• Good for random IO

Storage Types

S3

• (Almost) infinitely durable

• Infinitely scalable

• CloudFront integration

Glacier

• (Almost) infinitely durable

• Infinitely scalable

• Cheapest

Storage Types

Database

• Readily queryable

• Consistency/performance options

SQS

• Logic built-in

• Infinitely scalable

• Good for small blobs and write/read

once

Application Scaling

Wide and Proud

Loose coupling sets you free!

• The looser they're coupled, the bigger they scale

– Independent components

– Design everything as a black box

– Decouple interactions

– Load-balance clusters

Controller A Controller B Controller C

Controller A Controller B Controller C

Q Q Q

Tight Coupling

Use Amazon SQS as Buffers

Loose Coupling

Allows for Parallel Processing and Failure

• Fan out

• Use varied instance types

• Use varied billing models

Allows for Parallel Processing and Failure

Lets you Auto Scale

Auto Scaling Automatic resizing of compute clusters based on demand

Trigger auto-

scaling policy

Feature Details

Control Define minimum and maximum instance pool sizes and when scaling and cool down occurs.

Integrated to Amazon CloudWatch

Use metrics gathered by CloudWatch to drive scaling.

Instance types Run Auto Scaling for On-Demand and Spot Instances. Compatible with VPC.

as-create-auto-scaling-group MyGroup

--launch-configuration MyConfig

--availability-zones eu-west-1a

--min-size 4

--max-size 200

…and Spread the Load

Elastic Load Balancing • Create highly scalable applications

• Distribute load across EC2 instances

in multiple availability zones Feature Details

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 CloudWatch

But usually some state has to reside somewhere

Cookies in browser

Memory-resident session manager

Session database

Framework-provided session handler

So this store of state needs to be…

Performant

Scalable

Reliable

Where should session state reside?

Trigger auto-

scaling policy

Session State Service

Not Here

Here State must reside OUTSIDE

the scope of the elements you wish to scale

And what do I build it on?

The state service itself must be well architected

IAM Temporary Security Credentials

• Use Cases

Identity Federation to AWS APIs

Mobile and browser-based applications

Consumer applications with unlimited users

• Scales to millions of users

– No need to create an IAM identity for every user

AWS Account Credentials

IAM User

Temporary Security

Credentials

The IAM Hierarchy of Permissions

Permissions Example

Unrestricted access to all enabled services and resources

Action: * Effect: Allow Resource: * (implicit)

Access restricted by Group and User policies

Action: [‘s3:*’, ‘sts:Get*’] Effect: Allow Resource: *

Access restricted by generating identity and further by policies used to generate token

Action: [ ‘s3:Get*’ ] Effect: Allow Resource: ‘arn:aws:s3:::userbucket/*’

AWS Application Management Solutions

Elastic Beanstalk OpsWorks CloudFormation EC2

Convenience Control

Higher-level Services Do it yourself

Data Tier Scaling

The bane of the Architect’s existence

Vertical Scaling

“We’re gonna need a bigger box”

• Simplest approach

• Can now leverage PIOPs

• High I/O instances

• Easy to change instance sizes

• Will hit an endpoint eventually

hi1.4xlarge

m2.4xlarge

m1.small

Master/Slave Horizontal Scaling

• Reasonably simple to adapt to

• Can now leverage PIOPs

• Easy to change instances sizes

• Will hit an endpoint eventually

Sharded Horizontal Scaling

Hash Ring

A

B C

D

• 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

Horizontal Scaling – Fully Managed

DynamoDB • Provisioned throughput NoSQL database

• Fast, predictable performance

• Fully distributed, fault tolerant architecture

• Considerations for non-uniform data

Feature Details

Provisioned throughput

Dial up or down provisioned read/write capacity.

Predictable performance

Average single digit millisecond latencies from SSD-backed infrastructure.

Strong consistency Be sure you are reading the most up to date values.

Fault tolerant Data replicated across Availability Zones.

Monitoring Integrated to CloudWatch.

Secure Integrates with AWS Identity and Access Management (IAM).

Elastic MapReduce

Integrates with Elastic MapReduce for complex analytics on large datasets.

Petabyte-Scale Data Warehousing Feature Details

Optimized for Data

Warehousing

Redshift uses a variety of innovations to obtain very high query performance on datasets ranging in size from hundreds of gigabytes to a petabyte or more.

Scalable Easily scale the number of nodes in your data warehouse up or down as your performance or capacity needs change

Fault tolerant Data replicated across Availability Zones.

Monitoring Integrated to CloudWatch.

Secure Encrypt data in transit and at rest. Can also be run in VPC to isolate your data warehouse cluster.

S3 intergration Loads data in parallel to each node from S3.

Elastic MapReduce

Integrates with ERM via Data Pipeline.

Summary

• Use these techniques (and many, many others) situationally

• Awareness of the options is the first step to good design

• Scaling is the ability to move the bottlenecks around to the

least expensive part of the architecture

• AWS makes this easier – so your application is not a victim of

its own success

Recommended