AWS Paris Summit 2014 - T3 - Architecturer avec AWS pour des millions d'utilisateurs

2,193 views

Published on

Track 3 - Session 1 - Architecturer avec AWS pour des millions d'utilisateurs

Published in: Technology

AWS Paris Summit 2014 - T3 - Architecturer avec AWS pour des millions d'utilisateurs

  1. 1. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.© 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Architecturer avec AWS pour des millions d’utilisateurs Michaël Garcia, Solutions Architect AWS @aws_actus #AWSSummit 13 Mai 2014
  2. 2. Agenda • Notions de base • D’un utilisateur à des millions • Témoignage: “A Little Market” – Loic Duvernay
  3. 3. #1 Notions de base
  4. 4. Regions US-WEST (Oregon) EU-WEST (Ireland) ASIA PAC (Tokyo) US-WEST (N. California) SOUTH AMERICA (Sao Paulo) US-EAST (Virginia) AWS GovCloud (US) ASIA PAC (Sydney) ASIA PAC (Singapore) CHINA (Beijing)
  5. 5. Zones de disponibilités US-WEST (Oregon) EU-WEST (Ireland) ASIA PAC (Tokyo) US-WEST (N. California) SOUTH AMERICA (Sao Paulo) US-EAST (Virginia) AWS GovCloud (US) ASIA PAC (Sydney) ASIA PAC (Singapore) CHINA (Beijing)
  6. 6. Amazon CloudFront – 51 Point de présence
  7. 7. Compute Storage AWS Global Infrastructure Database App Services Deployment & Administration Networking
  8. 8. Compute Storage AWS Global Infrastructure Database App Services Deployment & Administration Networking Amazon CloudWatch AWS IAM AWS CloudFormation Amazon Elastic Beanstalk AWS Data Pipeline AWS OpsWorks AWS CloudTrail Amazon EC2 Amazon EMR Amazon VPC Amazon Route 53 AWS Direct Connect Amazon Kinesis AWS Storage Gateway Amazon S3 Amazon Glacier Amazon CloudFront Amazon DynamoDB Amazon RDS Amazon ElastiCache Amazon RedShift Amazon CloudSearch Amazon SQS Amazon SNS Amazon Elastic Transcoder Amazon SWF Amazon SES
  9. 9. #2 D’un utilisateur à des millions
  10. 10. Jour 1, 1 utilisateur: • Une seule instance EC2 – Contient toute la stack • Appli web • Base de données • Administration • etc. • Une Elastic IP • Amazon Route 53 pour le DNS Instance EC2 Adresse Elastic IP Amazon Route 53 Utilisateur
  11. 11. “On a besoin d’une plus grosse instance” • Approche la plus simple • PIOPs • Instances High I/O • Instances High memory • Instances High CPU • Instances High storage • Changement de taille d’instance facile
  12. 12. “On a besoin d’une plus grosse instance” • Approche la plus simple • PIOPs • Instances High I/O • Instances High memory • Instances High CPU • Instances High storage • Changement de taille d’instance facile • Possède une limite définie
  13. 13. Jour 1, 1 utilisateur: • Pas de redondance • Pas de fail-over • Pas d’élasticité • Trop ‘d’oeufs dans le même panier’ EC2 instance Elastic IP address Amazon Route 53 User
  14. 14. Jour 2, >1 utilisateur: Séparation selon les fonctions: • Webservers • Base de données – Existe-t-il un service managé ? Instance Web Instance DB Adresse Elastic IP Amazon Route 53 Utilisateur
  15. 15. Amazon RDS Amazon Relational Database Service Rentable et évolutif en terme de capacité Supporte plusieurs base de données SQL connues. Oracle / SQL Server / PostgreSQL / MySQL Gère les tâches d’administration de la base de données
  16. 16. >100 utilisateurs: Séparation selon les fonctions: • Webservers • Base de données – Utilisation de RDS pour gagner du temps Instance Web Adresse Elastic IP Amazon Route 53 Utilisateur Instance RDS Master
  17. 17. Pourquoi SQL au démarrage ? • Technologies établies et matures • Beaucoup de codes, documents, communautés, livres, outils existants • Vous n’allez pas atteindre les limites des bases SQL pour le million d’utilisateur. Vraiment, c’est sûr*. • Pattern de scalabilité établis * Sauf si vous manipulez des données à une échelle massive (To); même à ce moment là votre application aura toujours besoin d’une base SQL
  18. 18. >1000 utilisateurs: Adressons le fail-over et la redondance: • Passage en mode RDS multi- AZ • Une autre instance Web – Dans une autre zone de disponibilité • Elastic Load Balancing Instance Web Amazon RDS DB instance Active (Multi-AZ) Availability Zone Availability Zone Instance Web Amazon RDS DB instance Standby (Multi-AZ) Elastic Load Balancing Amazon Route 53 Utilisateur
  19. 19. Elastic Load Balancing Elastic Load BalancerMet automatiquement à l’échelle sa capacité afin de répondre au pics de trafic Supporte des “Health Check” applicatif pour router le trafic vers les instances en bonne santé Route le trafic vers des instances EC2 au niveau HTTP/HTTPS ou TCP
  20. 20. Le scaling horizontal permettra d’atteindre 10k/100k utilisateurs
  21. 21. >10ks/100ks RDS DB Instance Active (Multi-AZ) Availability Zone Availability Zone RDS DB Instance Standby (Multi-AZ) Elastic Load Balancing RDS DB Instance Read Replica RDS DB Instance Read Replica RDS DB Instance Read Replica RDS DB Instance Read Replica Web instance Web instance Web instance Web instance Web instance Web instance Web instance Web instance Amazon Route 53 User
  22. 22. Trafic du mois de Novembre Amazon.com capacité provisionnée novembre
  23. 23. Trafic du mois de Novembre Amazon.com 76% 24% capacité provisionnée novembre
  24. 24. Trafic du mois de Novembre Amazon.com novembre
  25. 25. Auto Scaling Auto Scaling Dimensionnement automatique de vos instances Amazon EC2 Pas de coût supplémentaire Remplacement des instances défaillantes afin d'assurer la disponibilité continue de vos applications
  26. 26. >10ks/100ks RDS DB Instance Active (Multi-AZ) Availability Zone Availability Zone RDS DB Instance Standby (Multi-AZ) Elastic Load Balancing RDS DB Instance Read Replica RDS DB Instance Read Replica RDS DB Instance Read Replica RDS DB Instance Read Replica Web instance Web instance Web instance Web instance Web instance Web instance Web instance Web instance Amazon Route 53 User Auto Scaling
  27. 27. Comment optimiser cette infrastructure ?
  28. 28. Optimisation: • Utiliser du CDN pour cacher • Mettre le contenu statique sur Amazon S3 • Cacher des informations avec Amazon ElastiCache • Déplacer des tables sur Amazon DynamoDB Web instance RDS DB Instance Active (Multi-AZ) Availability Zone Elastic Load Balancing Amazon S3 Amazon CloudFront Amazon Route 53 User ElastiCache Amazon DynamoDB
  29. 29. Amazon S3 Amazon Simple Storage Service Stockage pour Internet. En ligne nativement, accès HTTPS Stocker et récupérer n’importe quel volume de données, n’importe quand, depuis n’importe où Hautement scalable, rapide, fiable et durable
  30. 30. Amazon CloudFront Amazon CloudFront Cacher du contenu depuis Amazon S3 Ou depuis n’importe quel serveur web Accélérer le contenu statique et dynamique 51 Edge locations US / Europe /South America / Asia
  31. 31. Amazon DynamoDB Pas de limitation sur la quantité de données Facile à provisionner, changement de la capacité d’une table avec une simple requête Rapide, Performances élevées et prévisibles Amazon DynamoDB
  32. 32. Pourquoi NoSQL? • Besoin de latence très faible • Données fortement non relationnelles • Pas de schéma • Volume de données important (Echelle du To) • Nombre d’écritures massifs ( k requêtes/sec )
  33. 33. Amazon ElastiCache Amazon ElastiCache Elastique, découverte automatique de nœuds Manage les corrections, détecte et remplace automatiquement les nœuds défaillants Supporte les solutions Memcached et Redis
  34. 34. >500k+ Availability Zone Amazon Route 53 Utilisateur Amazon S3 Amazon CloudFront Availability Zone Elastic Load Balancing Amazon 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) RDS DB Instance Active (Multi-AZ) Auto Scaling
  35. 35. >500k+ Vous allez rencontrer certaines limites de performances sur vos composants logiciels: • Monitoring/Métriques/Logging – Solutions tierces (3rd party solutions) • Ecoutez les retours d’expérience • Maximiser la performance de chaque service/composant logiciel
  36. 36. Métriques instances Agrégation de métriques Analyse de logs Performances externes
  37. 37. 1million+ • ”Loose coupling” & “SOA” – Architecturer sous forme de service • Utiliser des services AWS – Accélérer le développement, peu d’administration, redondance et scalabilité – Email, recherche, file de message, etc… Amazon CloudSearch Amazon SQS Amazon SNS Amazon Elastic Transcoder Amazon SWF Amazon SES
  38. 38. 1million+ RDS DB Instance Active (Multi-AZ) Availability Zone Elastic Load Balancing RDS DB Instance Read Replica RDS DB Instance Read Replica Web instance Web instance Web instance Web instance Amazon Route 53 User Amazon S3 Amazon CloudFront Amazon DynamoDB Amazon SQS ElastiCache Worker instance Worker instance Amazon CloudWatch Internal app instance Internal app instance Amazon SES Auto Scaling
  39. 39. +10 Millions ???
  40. 40. Ce qu’il faut retenir • Multi-AZ • Aidez-vous des différents services – Elastic Load Balancing, Amazon S3, Amazon SNS, Amazon SQS, Amazon SWF, Amazon SES, etc. • Redondance à chaque niveau, SOA • Mettre en cache les données à l’intérieur et à l’extérieur • Automatiser la gestion et le monitoring
  41. 41. #3 Témoignage: Loic Duvernay
  42. 42. Qui est A little Market ? • Première place de marché française sur le fait-main – 2 Millions de produits, 80 000 créateurs – Equipe de 40 personnes – 4 Millions de visiteurs par mois – 5000 transactions par jour • 3 verticaux, 2 zones (France, Italie) – AlittleMarket.com: première place de marché française dédiée à l'artisanat et au fait main. – AlittleMercerie.com: première place de marché française dédiée aux loisirs créatifs. – AlittleEpicerie.com: place de marché dédiée aux produits du terroir.
  43. 43. Gestion du cache des images • Image sur NetApp – 6 To d’images – 65 millions d’éléments – 700 Go / jour (20 To / mois) – Cache Varnish de 30 Go * 4 (assets) + Cache Nginx persistant / SlowFS (2 frontaux dédiés)
  44. 44. Ce que vous ne voulez pas voir • Sur une période de 6 mois – 2 ralentissements (NetApp) – Varnish vidé de multiples fois, à chaque problème sur le front-end • Solution : CDN !
  45. 45. Avantages d’Amazon Cloudfront • Mise en place rapide – Création d’un alias au ndd: galerie-cloudfront.alittlemarket.com => galerie.alittlemarket.com • Configuration simple – Création d’une règle simple
  46. 46. Avantages d’Amazon Cloudfront Satisfaction utilisateur Gain de temps de chargement Moins de charge sur le Back-End Gain sur le coût de la bande passante et des ressources serveurs
  47. 47. • Plusieurs astuces à partager – Versioning de noms (invalidation) – Centralisation des fichiers (Amazon S3) – Utiliser un partenaire pour les statistiques avancées (CloudFront) – Toujours un ndd à part pour les assets Tips !
  48. 48. Et plus si affinité
  49. 49. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.© 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Questions ?
  50. 50. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.© 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Architecturer avec AWS pour des millions d’utilisateurs Michaël Garcia, Solutions Architect AWS @aws_actus #AWSSummit 13 Mai 2014 Merci !

×