aplicaciones a gran escala: cómo servir a millones de usuarios

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Rubén Ruiz, AWS Solutions Architect (@rruizsan)Genís Ureña, VP Engineering, Inbenta

June 2nd , 2016

Aplicaciones a gran escalaCómo servir a millones de usuarios

#AWSSummit@awscloud_es

Growth is good…

Dev & Test

Friends & Family

Live GA

…but can be challenging!!Source: http://peterskastner.wordpress.com/2011/02/23/cisco-the-lion-king-fights-for-data-center-fabric-leadership/Source: http://iwgcr.org/fire-destroys-wisconsin-data-center/

So how do we scale?

One size does not fit all !!

Auto Scaling??...Not Yet..

Let’s start with some basics….

AWS Regions 12 (+ 5)33 (+11)

RegionsAvailability Zones

Example AWS Region

AZ

AZ

AZ AZ AZ

Transit

Transit

Re:Invent 2014 (SPOT301)https://www.youtube.com/watch?v=JIQETrFC_SQ

Example AWS Availability Zone

AZ

AZ

AZ AZ AZ

Transit

Transit

Example AWS Data Center

AWS Edge locations 55 Edge locations

ENTERPRISE APPS

DEVELOPMENT & OPERATIONSMOBILE SERVICESAPP SERVICESANALYTICS

DataWarehousing

Hadoop/Spark

Streaming Data Collection

Machine Learning

Elastic Search

Virtual Desktops

Sharing & Collaboration

Corporate Email

Backup

Queuing & Notifications

Workflow

Search

Email

Transcoding

One-click App Deployment

Identity

Sync

Single Integrated Console

PushNotifications

DevOps Resource Management

Application Lifecycle Management

Containers

Triggers

Resource Templates

TECHNICAL & BUSINESS SUPPORT

Account Management

Support

Professional Services

Training & Certification

Security & Pricing Reports

Partner Ecosystem

Solutions Architects

MARKETPLACE

Business Apps

Business Intelligence

DatabasesDevOps Tools

NetworkingSecurity Storage

Regions Availability Zones

Points of Presence

INFRASTRUCTURE

CORE SERVICES

ComputeVMs, Auto-scaling, & Load Balancing

StorageObject, Blocks, Archival, Import/Export

DatabasesRelational, NoSQL, Caching, Migration

NetworkingVPC, DX, DNS

CDN

Access Control

Identity Management

Key Management & Storage

Monitoring & Logs

Assessment and reporting

Resource & Usage Auditing

SECURITY & COMPLIANCE

Configuration Compliance

Web application firewall

HYBRIDARCHITECTURE

Data Backups

Integrated App Deployments

DirectConnect

IdentityFederation

IntegratedResource Management

Integrated Networking

API Gateway

IoT

Rules Engine

Device Shadows

Device SDKs

Registry

Device Gateway

Streaming Data Analysis

Business Intelligence

MobileAnalytics

So let’s start from…

1 User

• Amazon Route 53 for DNS• A single Elastic IP• A single Amazon EC2

instance• With full stack on this host

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

Amazon EC2

instance

Elastic IP

UserAmazon Route 53

“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

c4.8xlarge

m3.2xlarge

t2.micro

1 User

• We could potentially get to a few hundred to a few thousand depending on application complexity and traffic

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

basket

EC2 Instance

Elastic IP

UserAmazon Route 53

Users > 1

First, let’s separate out our single host into more than one.• Web• Database

§ Make use of a database service?

Web Instance

DatabaseInstance

Elastic IP

UserAmazon Route 53

Database options

Self-managed Fully managed

Database server on Amazon EC2

Your choice of database running on

Amazon EC2

Bring Your Own License (BYOL)

Amazon DynamoDB

Managed NoSQL database service

using SSD storage

Seamless scalability Zero administration

Amazon RDSMicrosoft SQL Server

OracleMySQL

PostgreSQLMariaDB

Amazon Aurora

BYOL or license Included

Amazon Redshift

Massively parallel, petabyte-scale data warehouse service

Fast, powerful, and easy to scale

Users > 100

First, let’s separate out our single host into more than one:• Web• Database

§ Use Amazon RDS to make your life easier

Web instance

Elastic IP

RDS DB instance

UserAmazon Route 53

Users > 1000

Next, let’s address our lack of failover and redundancy issues:

Another web instance• In another Availability Zone

RDS Multi-AZElastic Load Balancing (ELB)

Web Instance

RDS DB InstanceActive (Multi-AZ)Availability Zone Availability Zone

Web Instance

RDS DB Instance Standby (Multi-AZ)

ELB Balancer

UserAmazon Route 53

Elastic Load Balancing

• Highly available• 1 - 65535• Health checks• Session stickiness• Secure sockets layer• Monitoring• Logging

Scaling…

horizontally

vert

ical

ly

Users > 10,000s–100,000s

RDS DB InstanceActive (Multi-AZ)

Availability Zone Availability Zone

RDS DB Instance Standby (Multi-AZ)

ELB Balancer

RDS DB Instance Read Replica




Web Instance

Web Instance

Web Instance

Web Instance

Web Instance

Web Instance

Web Instance

Web Instance

Amazon Route 53User


Availability Zone

ELB Balancer

Amazon S3

Amazon CloudFront

Amazon Route 53

User

Shift some load around

Web Instances

• static content to Amazon S3 and Amazon CloudFront

Move…

Amazon Simple Storage Service (S3)

• Object-based storage • Highly durable• Great for static assets• “Infinitely scalable”• Objects up to 5 TB in size• Optional encryption

Amazon CloudFront

• Cache content for faster delivery• Lower load on origin• Dynamic and static content• Streaming video• Custom SSL certificates• Low TTLs (as short as 0 seconds)• Free origin fetches?• Optimized for AWS

Shift some load around


Move…

• session/state to Amazon DynamoDB

• DB caching to Amazon ElastiCache


Availability Zone

ELB Balancer

Amazon S3

Amazon CloudFront

Amazon Route 53

User

ElastiCache DynamoDB

Web Instances

Amazon DynamoDB

• Managed NoSQL database• Provisioned throughput• Fast, predictable performance• Fully distributed, fault tolerant• JSON support• Items up to 400 KB

Amazon Elasticache

• Managed Memcached or Redis• Scale from one to many nodes• Self-healing (replaces dead instance)• Single digit ms speeds (usually)• Local to a single AZ for Memcache• Multi-AZ possible with Redis

Shift some load aroundMove…


• session/state to Amazon DynamoDB

• DB caching to Amazon ElastiCache

• dynamic content to Amazon CloudFront


Availability Zone

ELB Balancer

Amazon S3

Amazon CloudFrontUser

ElastiCache DynamoDB

Web Instances

Amazon Route 53

Auto Scaling!

Auto ScalingAutomatic resizing of compute clusters Define min/max pool sizesCloudWatch metrics drive scalingOn-demand or Spot instances

aws autoscaling create-auto-scaling-group--auto-scaling-group-name MyGroup--launch-configuration-name MyConfig--min-size 4--max-size 200--availability-zones eu-west-1a, eu-west-1b

Sunday Monday Tuesday Wednesday Thursday Friday Saturday

Typical weekly traffic to Amazon.com

Sunday Monday Tuesday Wednesday Thursday Friday Saturday

Typical weekly traffic to Amazon.com

Provisioned capacity

November

November traffic to Amazon.com


November


November traffic to Amazon.com76%

24%November



November

= one user

= 100,000 users= 1,000,000 users

Users > 500.000+

Availability Zone

Amazon Route 53

User

Amazon S3

Amazon CloudFront

Availability Zone

ELB Balancer

DynamoDBRDS 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)


Use automation

AWS application management solutions

Convenience Control

Higher-level services Do it yourself

AWSElastic Beanstalk

AWSOpsWorks

AWSCloudFormation Amazon EC2

SOAing

Move services into their own tiers.• Treat them separately and scale them

independently.

Amazon and AWS do this extensively!

It offers flexibility and greater understanding of each component

Microservices approach w/ Containers

Leverage API Gateway & Lambda + Load Balancing

Loose coupling + SOA = winning

DON’T REINVENT THE WHEEL

• Email• Queuing• Transcoding• Search• Monitoring• Metrics• Logging• Compute

Amazon CloudSearch

Amazon SQSAmazon SNS

Amazon Elastic Transcoder

Amazon SWFAmazon SES

AWS Lambda

Users >1 million+


Availability Zone

ELB Balancer



Web Instance

Web Instance

Web Instance

Web Instance

Amazon Route 53

User

Amazon S3

Amazon CloudFront

DynamoDB

Amazon SQS

ElastiCache

WorkerInstance

WorkerInstance

Amazon CloudWatch

Internal AppInstance

Internal AppInstance Amazon SES

Lambda

Users > 5 million - 10 million

You’ll potentially start to run into issues with your database around contention on the write master.

How can you solve it?• Federation—splitting into multiple DBs based on function• Sharding—splitting one dataset up across multiple hosts• Moving some functionality to other types of DBs (NoSQL, Graph)

Database federation• Split up databases by function/purpose

• Harder to do cross-function queries

• Essentially delays sharding/NoSQL

• Won’t help with single huge functions/tables

Forums DB

Users DB

Products DB

Sharded horizontal scaling• More complex at the application layer

• 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

CBA

Shifting functionality to NoSQL• Similar in a sense to federation

• Again, think about the earlier points for when you need NoSQL vs. SQL

• Leverage managed services like DynamoDB

Some use cases:• Leaderboards/scoring• Rapid ingest of clickstream/log data• Temporary data needs (cart data)• “Hot” tables• Metadata/lookup tablesDynamoDB

Congratulations!!

You’ve become acloud ninja!!

Next steps?

READ! aws.amazon.com/documentationaws.amazon.com/architecture

START USING AWS: aws.amazon.com/free/

Ask for Help!

forums.aws.amazon.comaws.amazon.com/premiumsupport/

Your Account Manager

A Solutions Architect

Thank you!

aplicaciones a gran escala: cómo servir a millones de usuarios

Technology