Le Cloud Computing offre de nombreux avantages, tels que la possibilité de passer vos applications à l'échelle en fonction de vos besoins. Si vous avez une nouvelle application et que vous souhaitez utiliser le Cloud AWS, vous serez amené à vous poser la question suivante : "Par où dois-je commencer ?". Rejoignez-nous sur cette session pour comprendre les bonnes pratiques qui vous permettront de passer de 0 à plusieurs millions d'utilisateurs. Nous vous montrerons comment combiner au mieux les services AWS, prendre les bonnes décisions pour architecturer vos applications et déployer des infrastructure scalables dans le Cloud.

1. PARIS

2. 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

3. 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

4. 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

5. Etape 1 – Développement

6. Une instance
LE serveur
(e.g. Apache,
MySQL)
Elastic IP
www.example.com
Amazon Route 53
DNS service
Server Image
(AMI)

7. Etape 2 – beta

8. 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

9. 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

10. Comment choisir ma BDD en
fonction de mes besoins?
SQL? NoSQL?

11. 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

12. 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 ?

13. Bases de données relationnelles
MySQL, Aurora, PostgreSQL, Oracle, SQL Server
Totalement managées; pas d’administration
Amazon
RDS
Aurora

14. Améliorer l’éfficacité

15. 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

16. 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

17. 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

18. 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 base
RDS database
Amazon ElastiCache
3. L’enregistrer
dans le cache

19. Amazon ElastiCache: cache en mémoire
• Simple à déployer
• Managé
– Remplacement automatique des noeuds en
erreur
– Management des patches
• Elastique
• Compatible MemCached et Redis
ElastiCache

20. Etape 3 – Production

21. Haute Disponibilité
Availability Zone a
RDS DB
instance
Web
server
S3 bucket for
static assets
www.example.com
Amazon Route 53
DNS service
Amazon CloudFront
ElastiCache
node 1

22. Haute Disponibilité
Availability Zone a
RDS DB
instance
Availability Zone b
Web
server
Web
server
S3 bucket for
static assets
www.example.com
Amazon Route 53
DNS service
Amazon CloudFront
ElastiCache
node 1

23. Haute Disponibilité
Availability Zone a
RDS DB
instance
Availability Zone b
www.example.com
Amazon Route 53
DNS service
Elastic Load
Balancing
Web
server
Web
server
S3 bucket for
static assets
Amazon CloudFront
ElastiCache
node 1

24. 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

25. Haute Disponibilité
Availability Zone a
RDS DB
instance
Availability Zone b
www.example.com
Amazon Route 53
DNS service
Elastic Load
Balancing
Web
server
Web
server
S3 bucket for
static assets
ElastiCache
node 1
Amazon CloudFront

26. Haute Disponibilité
Availability Zone a
RDS DB
instance
Availability Zone b
www.example.com
Amazon Route 53
DNS service
Elastic Load
Balancing
Web
server
Web
server
RDS DB
standby
S3 bucket for
static assets
ElastiCache
node 1
Amazon CloudFront

27. 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
server
Web
server
RDS DB
standby

28. 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
server
Web
server
RDS DB
standby
ElastiCache
node 2

29. 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
server
Web
server
Logged in Logged out

30. 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

31. Etape 4 – Anticiper le succès

32. Remplacer les prévisions par une IT élastique
Avant AWS
Demand
Unhappy
Customers
Waste $$$
Traditional
Capacity
Capacity
Demand
AWS Cloud

33. 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
server
Web
server
RDS DB
standby
ElastiCache
node 2

34. 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
server
Web
server
RDS DB
standby
ElastiCache
node 2
Web
server
Web
server

35. 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
server
Web
server
RDS DB
standby
ElastiCache
node 2
Web
server
Web
server

36. 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

37. Décomposer les couches applicatives en
blocs de taille réduite , faiblement couplé,
et surtout sans état
Pré-requis

38. 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

39. 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…

40. 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

41. Etape 5 – Ajouter des fonctionnalités

42. Mobile
Push
Notifications
Mobile
Analytics
Cognito
Cognito
Sync
Analytics
Kinesis
Data
Pipeline
RedShift EMR
Vos Applications
AWS Global Infrastructure
Network
VPC
Direct
Connect
Route 53
Storage
EBS S3 Glacier CloudFront
Database
DynamoDBRDS ElastiCache
Deployment & Management
Elastic
Beanstalk
OpsWorks
Cloud
Formation
Code
Deploy
Code
Pipeline
Code
Commit
Security & Administration
CloudWatch Config
Cloud
Trail
IAM Directory KMS
Application
SQS SWF
App
Stream
Elastic
Transcoder
SES
Cloud
Search
SNS
Enterprise Applications
WorkSpaces WorkMail WorkDocs
Compute
EC2 ELB
Auto
Scaling
LambdaECS

43. 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

44. Restez focalisés sur votre Business
Infrastructure
Cloud AWS
Votre
Business
Plus de temps pour vous focaliser
sur votre Business
Configurer vos
ressources Cloud
70%
30%70%
Infrastructure
On-Premise
30%
Gérer des tâches
sans valeur ajoutée

45. Etape 6 – Une expansion rapide

46. 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

47. 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

48. 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

49. 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
RDS read
replica
Passer la BD à l’échelle

50. 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)

51. 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

52. 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

53. 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

54. Résumé

55. 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
replica
RDS read
replica
DynamoDB
RDS read
replica
ElastiCache
node 4
RDS read
replica
ElastiCache
node 1
CloudSearchLambdaSES SQS

56. 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

57. 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