PARIS

Préparez-vous à l’imprévu !

(ou comment passer de 1 à 10M d’utilisateurs ?)

Cédric DUPUI, AWS - Solutions Architect

23rd June 2015, AWS Paris Summit

@aws_actus

Pourquoi participer à cette session ?

• Construire une plate-forme technologique

• Anticiper votre succès

• Comprendre les Design Patterns liés à la scalabilité

• Adopter une démarche pragmatique et itérative

Qu’est-ce qu’une architecture scalable ?

• Elle peut supporter une augmentation du nombre

d’utilisateurs, du traffic et des données

• Elle n’a pas de limites

• Elle ne subit pas de dégradation de performances

• Elle est prédictible – en ajoutant des ressources

• Elle est efficace – en terme de coût par utilisateur

Etape 1 – Développement

Une instance

LE serveur

(e.g. Apache,

MySQL)

Elastic IP

www.example.com

Amazon Route 53

DNS service

Server Image

(AMI)

Etape 2 – beta

Il nous faut un plus gros serveur !

• Plus de stockage, plus rapide (EBS)

• Utiliser le bon type d’instance

• Il est facile de changer d’instance…

• … Mais cette stratégie est temporaire !

• Pas de tolérance à la panne

Séparer le web et la BD

• Plus de capacité

• Rendre chaque tiers scalable individuellement

• Optimiser les instances pour chaque tiers– Type d’instance

– Stockage

• Securité– Security groups

– BD dans un subnet privé du VPC

Comment choisir ma BDD en

fonction de mes besoins?

SQL? NoSQL?

Pourquoi commencer avec une BDD Relationelle?

• L’approche SQL est polyvalente

• Un éco-système riche : code, outils, connaissances

• Patterns bien identifiés pour gérer la scalabilité*

• Dans la réalité : Besoin d’une couche de données

“polyglotte”

– Parfois, NoSQL plus adapté

Utiliser le meilleur outil pour chaque cas d’usage

* Pour des applications avec un fort taux de lecture

Les Bases de Données relationnelles sont complexes !

• Expérience Amazon.com Les BDD relationnelles sont

extrèmement délicates à gérer et à opérer en HA

• BDD non / mal opérées = Cause principale de nuits

blanches et de coupures de services

• Est-ce que vous disposez d’équipes dédiées ?

Bases de données relationnelles

MySQL, Aurora, PostgreSQL, Oracle, SQL Server

Totalement managées; pas d’administrationAmazon

RDS

Aurora

Améliorer l’éfficacité

Déporter les contenus statiques

• Amazon S3: Hautement disponible et scalable– Fichiers statiques (JavaScript, CSS, images, …)

– Upload

• URLs S3 – contenu servi directement depuis S3

• Le serveur Web se focalise sur le contenu

dynamique

Amazon CloudFront• Réseau mondial de points de cache (Edge Locations)

• Cache au plus proche de l’utilisateur – Réduire la latence

– Réduire la charge sur les serveurs d’origine

– Contenus statique ET dynamique

– Impact énorme sur l’XP utilisateur

• Optimisation des connections– Optimiser les routes de transfert

– Connections persistantes

– Avantages valables même sur le contenu non cachable

CloudFront pour du contenu statique ET dynamique

Amazon

Route 53

EC2 instance(s)

S3 bucket

Static content

Dynamic content

css/*

js/*

Images/*

Default(*)

CloudFront

distribution

Cache de base de données• Meilleur temps de réponse (RAM)

• Réduit le traffic sur la base de données

Serveur

d’application

1. Si le résultat est en

cache, retourner ce

résultat

2. S’il n’est pas

dans le cache,

interroger la baseRDS database

Amazon ElastiCache

3. L’enregistrer

dans le cache

Amazon ElastiCache: cache en mémoire

• Simple à déployer

• Managé– Remplacement automatique des noeuds en

erreur

– Management des patches

• Elastique

• Compatible MemCached et RedisElastiCache

Etape 3 – Production

Haute Disponibilité

Availability Zone a

RDS DB

instance

Web

serverS3 bucket for

static assets

www.example.com

Amazon Route 53

DNS service

Amazon CloudFront

ElastiCache

node 1

Haute Disponibilité

Availability Zone a

RDS DB

instance

Availability Zone b

Web

serverWeb

serverS3 bucket for

static assets

www.example.com

Amazon Route 53

DNS service

Amazon CloudFront

ElastiCache

node 1

Haute Disponibilité

Availability Zone a

RDS DB

instance

Availability Zone b

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

Web

serverWeb

serverS3 bucket for

static assets

Amazon CloudFront

ElastiCache

node 1

Elastic Load Balancing (ELB)

• Service de répartition de charge managé

• Tolérant à la panne

• Vérification de l’état (Health Check)

• Distribue le traffic entre les Azs d’une région

• Elastique – s’adapte automatiquement au traffic

Haute Disponibilité

Availability Zone a

RDS DB

instance

Availability Zone b

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

Web

serverWeb

serverS3 bucket for

static assets

ElastiCache

node 1

Amazon CloudFront

Haute Disponibilité

Availability Zone a

RDS DB

instance

Availability Zone b

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

Web

serverWeb

server

RDS DB

standby

S3 bucket for

static assets

ElastiCache

node 1

Amazon CloudFront

Haute Disponibilité de la

couche de données

Availability Zone a

RDS DB

instance

ElastiCache

node 1

Availability Zone b

S3 bucket for

static assets

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

Web

serverWeb

server

RDS DB

standby

Haute Disponibilité de la

couche de données

Availability Zone a

RDS DB

instance

ElastiCache

node 1

Availability Zone b

S3 bucket for

static assets

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

Web

serverWeb

server

RDS DB

standby

ElastiCache

node 2

Sessions utilisateur• Problème: Souvent stockées sur un

disque local (non partagé)

• Contournement : ELB + Affinité de

sessions

Solution: Stockage dans DynamoDB !

Elastic Load

Balancing

Web

serverWeb

server

Logged in Logged out

Amazon DynamoDB

• Base Document et Clé-valeur managée

• Facile à prendre en main et à faire évoluer

• Jusqu’à des millions d’IOPS

• Capacité en lecture ET en écriture

• Consistente et rapide

• Durable: parfait pour le stockage des données de

session

https://github.com/aws/aws-dynamodb-session-tomcat

http://docs.aws.amazon.com/aws-sdk-php/guide/latest/feature-dynamodb-session-handler.html

Etape 4 – Anticiper le succès

Remplacer les prévisions par une IT élastique

Avant AWS

Demand

Unhappy Customers

Waste $$$

Traditional

Capacity

Capacity

Demand

AWS Cloud

Une couche Web scalable

Availability Zone a

RDS DB

instance

ElastiCache

node 1

Availability Zone b

S3 bucket for

static assets

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

Web

serverWeb

server

RDS DB

standby

ElastiCache

node 2

Une couche Web scalable

Availability Zone a

RDS DB

instance

ElastiCache

node 1

Availability Zone b

S3 bucket for

static assets

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

Web

serverWeb

server

RDS DB

standby

ElastiCache

node 2

Web

server

Web

server

Une couche Web scalable

Availability Zone a

RDS DB

instance

ElastiCache

node 1

Availability Zone b

S3 bucket for

static assets

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

Web

serverWeb

server

RDS DB

standby

ElastiCache

node 2

Web

server

Web

server

Redimensionnement

automatique des flottes de

serveurs

Fonctionnalités Détails

Contrôle Définir une taille minimum et un maximum pour les flottes de serveurs.

Intégré à Amazon CloudWatch

Utiliser les métriques CloudWatch pour contrôler la scalabilité.

Types d’instances Lancer l’Auto-Scaling pour vos instances Spot ou à la demande, compatible avec VPC.

aws autoscaling create-auto-scaling-group

--auto-scaling-group-name MyGroup

--launch-configuration-name MyConfig

--min-size 4

--max-size 200--availability-zones us-west-2c, us-west-2b

Auto Scaling Trigger auto-scaling policy

Amazon

CloudWatch

Décomposer les couches applicatives en

blocs de taille réduite , faiblement couplé,

et surtout sans état

Pré-requis

Qu’est ce cela signifie en pratique ?

• Seules les données “transientes“ sont stockées sur le

disque local

• Besoin de persister une données au dela de la requête

HTTP ?

– Enregistez-la ailleurs !Fichiers Utilisateur

Sessions Utilisateur

Amazon S3

AWS DynamoDB

Données Applicatives

Amazon RDS

Après voir tout décomposé en blocs de taille

réduite, faiblement couplés et sans état

Vous pouvez maintenant augmenter l’échelle facilement

Et ensuite…

Et ensuite…

Vous pouvez maintenant diminuer l’échelle facilement

Après voir tout décomposé en blocs de taille

réduite, faiblement couplés et sans état

Etape 5 – Ajouter des fonctionnalités

Mobile

Push

NotificationsMobile

AnalyticsCognito

Cognito

Sync

Analytics

KinesisData

PipelineRedShift EMR

Vos Applications

AWS Global Infrastructure

Network

VPCDirect

ConnectRoute 53

Storage

EBS S3 Glacier CloudFront

Database

DynamoDBRDS ElastiCache

Deployment & Management

Elastic

BeanstalkOpsWorks

Cloud

Formation

Code

Deploy

Code

Pipeline

Code

Commit

Security & Administration

CloudWatch ConfigCloud

TrailIAM Directory KMS

Application

SQS SWFApp

Stream

Elastic

TranscoderSES

Cloud

Search

SNS

Enterprise Applications

WorkSpaces WorkMail WorkDocs

Compute

EC2 ELBAuto

ScalingLambdaECS

AWS building blocks

Nativement Scalable & Hautement disponible Scalable & Hautement disponible

Elastic Load Balancing

Amazon CloudFront

Amazon Route53

Amazon S3

Amazon SQS

Amazon SES

Amazon CloudSearch

AWS Lambda

…

Amazon DynamoDB

Amazon Redshift

Amazon RDS

Amazon Elasticache

…

Amazon EC2

Amazon VPC

Automatisés Configurables Avec la bonne architecture

Restez focalisés sur votre Business

InfrastructureCloud AWS

VotreBusiness

Plus de temps pour vous focaliser sur votre Business

Configurer vos ressources Cloud

70%

30%70%

InfrastructureOn-Premise

30%

Gérer des tâches sans valeur ajoutée

Etape 6 – Une expansion rapide

Passer les BDs relationnelles à l’échelle

• Améliorer les spécifications des instances RDS– Type d’instance plus performant

– Plus de stockage / Plus de performance (PIOPS)

• Read Replicas (Master – Slave)– Passer à l’échelle au delà des capacité d’une instance de BD

– Disponible sur Amazon RDS pour MySQL, PostgreSQL et Aurora

– Ecriture => master

– Latence en réplication

– Lectures tolérantes avec la consistence des données => read replica

(slave)

– Lectures avec de forts besoins de consistence => master

Passer la BD à l’échelle

Web

server

Web

server

Web

server

Web

server

Availability Zone a

RDS DB

instance

ElastiCache

node 1

Availability Zone b

S3 bucket for

static assets

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

RDS DB

standby

ElastiCache

node 2

Web

server

Web

server

Web

server

Web

server

Availability Zone a

RDS DB

instance

ElastiCache

node 1

Availability Zone b

S3 bucket for

static assets

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

RDS DB

standby

ElastiCache

node 2 RDS read

replica

Passer la BD à l’échelle

Web

server

Web

server

Web

server

Web

server

Availability Zone a

RDS DB

instance

ElastiCache

node 1

Availability Zone b

S3 bucket for

static assets

www.example.com

Amazon Route 53

DNS service

Elastic Load

Balancing

RDS DB

standby

ElastiCache

node 2 RDS read

replicaRDS read

replica

Passer la BD à l’échelle

Et si votre application est orientée écriture ?

Challenge: Vous allez finalement rencontrer les limites de

la BD en terme de bande passante et d’IOPS

Solutions:

• Federation (diviser en plusieurs BDs selon leur fonction)

• Sharding (répartir les données d’une BD sur plusieurs

instances)

Fédération

• Diviser les tables / fonctions en BD

plus petites et autonomes

(--) Requêtes multi-fonctions

(forum+user+products)

(--) Fonctions / tables très

volumineuses

Forums DB

Users DB

Products

DB

Sharding horizontal

• Enregister une portion de

chaque table sur un shard

(--) Plus complexe au niveau

applicatif

(--) Plus complexe à opérer

User ShardID

002345 A

002346 B

002347 C

002348 B

002349 A

Shard C

Shard B

Shard A

NoSQL

• Principales différences par rapport aux BDs relationnelles :

– Modèle de données plus flexible

– Scalabilité horizontale & performances prédictibles

DynamoDB

Performances en Lecture / Ecriture

configurables pour chaque table

Résumé

Amazon Route 53

DNS servicePas de limites

Availability Zone a

RDS DB

instance

ElastiCache

node 2

Availability Zone b

S3 bucket for

static assets

www.example.com

Elastic Load

Balancing

RDS DB

standby ElastiCache

node 3

RDS read

replicaRDS read

replica

DynamoDB

RDS read

replicaElastiCache

node 4

RDS read

replicaElastiCache

node 1

CloudSearchLambdaSES SQS

Quelques rappels• KISS (Keep it simple and … stateless)

• Utilisez des services managés et nativement scalables

• Utilisez des ressources Multi AZ et Auto Scalables

• Utilisez la bonne BD pour chaque cas d’usage

• Utilisez un système de cache à plusieurs niveaux

• Simplifiez les opérations avec des outils de

déploiement

Prochaines étapes ?Documentez-vous !

• https://aws.amazon.com/documentation

• https://aws.amazon.com/architecture

• https://aws.amazon.com/blogs/aws/

Faites-vous aider !

• Forum : http://forums.aws.amazon.com

• Support : http://aws.amazon.com/support

• Equipes locales AWS en France