Using AWS Services to Go “All In” on AWS

AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015


Using AWS Services to Go “All In” on AWS

Q. Wade Billings, Sr. Director Global IT Shared Services, Instructure

Chad Schmutzer, Solutions Architect, Amazon Web Services

©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved.


Going “all in” on AWS

During this session, we will walk through an all-in example architecture and learn how Instructure is using AWS in true all-in fashion.

http://www.instructure.com/


INSTRUCTURE


0

100

200

300

400

500

600

700

800

900

1,000

1,100

1,200

1,300

1,400

1,500


Built for scale

Vector-scaling engine

Peak concurrent user count: 216,100

Number of production clusters: 47

Number of servers online at peak: 1,700

Amazon EC2 Amazon VPCAmazon S3 Amazon RDSAmazon SES

Amazon EMRAmazon Redshift


So you’ve decided to go all in on AWS


This is an excellent decision, but what does it really mean to go “all in?”


Technically, this web app is “all in”

• A single EC2 instance– with full stack on this host

• web app• database• management• and so on…

• A single Elastic IP address

EC2 instance

Elastic IP

User


Technically “all in,” but…• Will scale up to a certain

point• No failover• No redundancy• Too many eggs in one

basketEC2 instance

Elastic IP

User


Single instance = simple approach• Simplest approach• Can now leverage PIOPs • High I/O instances• High memory instances• High CPU instances• High storage instances• Easy to change instance sizes• Will hit an endpoint eventually

c3.8xlarge

m3.2xlarge

t2.micro


“We’re gonna need a bigger box”• Simplest approach• Can now leverage PIOPs • High I/O instances• High memory instances• High CPU instances• High storage instances• Easy to change instance sizes• Will hit an endpoint eventually,

and doesn’t take advantage of what AWS has to offer

c3.8xlarge

m3.2xlarge

t2.micro


This is how the “very bad day” started

• A single EC2 instance– With full stack on this host

• Web app• Database• Management• And so on…

• A single Elastic IPEC2 instance

Elastic IP

User

http://blog.canvaslms.com/blog/bid/210688/A-Bad-Day-for-Canvas


We can rebuild. We have the technology. We can make it better, faster, stronger.


First things first: the networkLet’s lay the groundwork for going “all in” by using Amazon VPC

virtual private cloud


What is Amazon VPC?


What is Amazon VPC?

• A private, isolated section of the AWS cloud• A virtual network topology you can deploy and

customize• Complete control of your networking


Put simply, it is a virtual data center you can build and control on AWS!


• VPC • Your virtual data center on

AWS• Block of IP addresses that

define your network (typically, RFC 1918)

• Can span multiple Availability Zones

• Default VPCs

VPC

Availability Zone A Availability Zone B

VPC CIDR: 10.1.0.0 /16


• Range of IP addresses in your VPC IP range

• Lives inside an Availability Zone

• Can provide security at the subnet or network level with ACLs

• Can route at the subnet level

• Default VPC subnets

VPC subnet

Subnet

Availability Zone A

Subnet

Availability Zone B

10.1.1.0/24 10.1.10.0/24

VPC CIDR: 10.1.0.0 /16


Instructure’s “cluster” architecture• SSD-backed EBS volumes• Multi-AZ VPCs


Slowly taking eggs out of the basket…

Next, let’s separate our single host into more than one:• web• database

– Use Amazon RDS to make your life easier

Web instance

Elastic IP address

RDS DB instance

User


Amazon RDS: Managed SQL in the cloud

• simple and fast to deploy

• handles repetitive

management tasks

• compatible with your

applications

• fast, predictable performance

• simple and fast to scale

• secure

• cost-effective

- And introducing Amazon Aurora


Choose Multi-AZ for greater availability, durability

• With Multi-AZ operation, your database is synchronously replicated to another Availability Zone in the same AWS region

• Failover occurs automatically in response to the most important failure scenarios

• Planned maintenance is applied first to backup


Instructure’s “cluster” architecture• SSD-backed EBS volumes• Multi-AZ VPCs• Sharded PostgeSQL databases• Intelligent routing of SQL calls


Now in preview: Amazon RDS for Aurora

• Amazon Aurora: the relational database reinvented for the cloud– Up to five times better performance than MySQL – At a price point 1/10 of a commercial database – Designed for drop-in compatibility with MySQL 5.6

• Pay only for the storage you use

• Runs in Amazon VPC; offers encryption at rest and in transit

• Amazon RDS handles administrative tasks for Aurora


Amazon Aurora: High availability by default

• Your data is replicated 6 ways across 3 Availability Zones

• Storage grows up to 64 TB seamlessly

• Up to 15 Aurora replicas with instant crash recovery

AZ 1 AZ 2 AZ 3

Virtualized, cross-AZ storage layer


Head to the next levelNext, let’s address our lack of failover and redundancy issues:• Load balancer• Another web instance

– In another Availability Zone

• RDS Multi-AZ

web instance

RDS DB Instanceactive (Multi-AZ)

Availability Zone Availability Zone

web instance

RDS DB instance standby (Multi-AZ)

Elastic LoadBalancing

user


• Create highly scalable applications

• Distribute load across EC2 instances

in multiple Availability Zones Feature Details

Available Load balances across instances in multiple Availability Zones

Health checks Automatically checks health of instances and takes them in or out of service

Session stickiness Routes 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 and can get logs of requests processed


Elastic Load Balancing


Instructure’s “cluster” architecture• SSD-backed EBS volumes• Multi-AZ VPCs• Sharded PostgeSQL databases• Intelligent routing of SQL calls• No single points of failure• Tight integration with ELB


This will take us pretty far, but we care about performance

and efficiency, so let’s improve further


web instance

RDS DB instanceactive (Multi-AZ)

Availability Zone


user

Let’s lighten the load on our web and database instances:• Move static content from

the web instance to Amazon S3 and Amazon CloudFront

Shift some load around


web instance


Availability Zone


Amazon S3

Amazon CloudFrontuser

Let’s lighten the load on our web and database instances:• Move static content from


Shift some load around


Amazon S3Amazon S3 is cloud storage for the Internet: • Object-based storage • 11 9s of durability• Good for things like the following:

– Static assets ( css, js, images, videos )

– Backups– Logs– Ingest of files for processing

• “Infinitely scalable”• Objects up to 5 TB in size

• Can host static websites• Supports fine-grained permission control• Ties in well with CloudFront• Acts as a logging endpoint for S3,

CloudFront, Billing and Cost Management, ELB, CloudTrail, and more

• Supports encryption at transit and at rest• Reduced redundancy is 1/3 cheaper• Amazon Glacier for super long-term

storage at 1/3 the cost of S3

Amazon S3


Instructure’s “cluster” architecture• SSD-backed EBS volumes• Multi-AZ VPCs• Sharded PostgeSQL databases• Intelligent routing of SQL calls• No single points of failure• Tight integration with ELB• Heavy use of S3


Amazon S3

Instructure uses S3 to store:- course data- student submissions- logs- database backups- performance metric data- application elements

- CSS

Amazon S3


CloudFrontCloudFront is a web service for scalable content delivery: • Cache static content at the edge for faster delivery• Helps lower load on origin infrastructure• Dynamic and static content• Streaming video• Zone apex support• Custom SSL certificates• Low TTLs (as short as 0 seconds)• Lower costs for origin fetches (between

S3, EC2, and CloudFront)• Optimized to work with EC2, S3, Elastic Load

Balancing, and Route 53

Resp

onse

Tim

e

Serv

er L

oad

Resp

onse

Ti

me

Serv

er

Load

Resp

onse

Ti

me

Serv

er L

oad

No CDN CDN for static

content

CDN for static

and dynamic

content

08:00:00 AM09:40:00 AM11:20:00 AM01:00:00 PM 02:40:00 PM 04:20:00 PM 06:00:00 PM 07:40:00 PM0

10

20

30

40

50

60

70

80

Volu

me

of d

ata

de-

liver

ed (G

bps)


Shift some load aroundLet’s lighten the load on our web and database instances:• Move static content from


• Move session/state and DB caching to Amazon ElastiCache

web instance


Availability Zone


Amazon S3



Shift some load aroundLet’s lighten the load on our web and database instances:• Move static content from


• Move session/state and database caching to Amazon ElastiCache

web instance


Availability Zone


Amazon S3

Amazon CloudFront

user

ElastiCache


Amazon ElastiCache• Hosted Memcached and Redis

– Speaks same API as traditional open source Memcached and Redis

• Scale from one to many nodes• Self healing (replaces dead instance)• Very fast (single-digit millisecond speeds usually (or less))• Local to a single Availability Zone for Memcache, with no

persistence or replication• With Redis, can put a replica in a different Availability Zone

with persistence• Use Auto Discovery to simplify growing and shrinking

clusters without affecting your application


Instructure’s “cluster” architecture• SSD-backed EBS volumes• Multi-AZ VPCs• Sharded PostgeSQL databases• Intelligent routing of SQL calls• No single points of failure• Tight integration with ELB• Heavy use of S3• Redis caching layer


Shift some load aroundLet’s lighten the load on our web and database instances:• Move static content from the

web instance to Amazon S3 and Amazon CloudFront

• Move session/state and database caching to ElastiCache

• Move dynamic content from the load balancer to Amazon CloudFront

web instance


Availability Zone


Amazon S3


ElastiCache


Shift some load around:Let’s lighten the load on our web and database instances:• Move static content from


• Move session/state and DB caching to ElastiCache

• Move dynamic content from the ELB to Amazon CloudFront

web instance


Availability Zone


Amazon S3

Amazon CloudFront

user

ElastiCache


Now let’s add Route 53


Add Route 53

Availability Zone

Amazon Route 53

user

Amazon S3

Amazon CloudFront

Availability Zone


RDS DB instance read replica

web instance

web instance

web instance

ElastiCache RDS DB instance read replica

web instance

web instance

web instance

ElastiCacheRDS DB instance standby (Multi-AZ)



Route 53 is a highly available and scalable

cloud-baseddomain name service


What is highly available?

The Route 53 SLA is 100% availability per month

SLA details: https://aws.amazon.com/route53/sla/

https://aws.amazon.com/route53/sla/




Route 53 features

• Latency-based routing– Route end users to the AWS region that

provides the lowest possible latency• Geo DNS

– Route end users to an endpoint you specify based on the end users’ geographic location


Route 53 features (continued)

• Weighted round robin– Specify the frequency (“weights”) with which

different DNS responses are returned to end users

• DNS failover– Route your website visitors to an alternate

location to avoid site outages


Route 53 features (continued)

• Health checks– Monitor the health and performance of your

web resources• Private DNS for Amazon VPC

– Manage custom domain names for your internal, non-public AWS resources

• Domain registration


Instructure’s “cluster” architecture• SSD-backed EBS volumes• Multi-AZ VPCs• Sharded PostgeSQL databases• Intelligent routing of SQL calls• No single points of failure• Tight integration with ELB• Heavy use of S3• Redis caching layer• Asynchronous job service layer• Managed with enterprise CM


Thank You.This presentation will be loaded to SlideShare the week following the Symposium.

http://www.slideshare.net/AmazonWebServices


Using AWS Services to Go “All In” on AWS

Technology

Transcript of Using AWS Services to Go “All In” on AWS